On Mon, Nov 05, 2012 at 11:34:49AM +0800, yongd wrote:From the code logic, without SDHCI_QUIRK_BROKEN_CARD_DETECTION for ESDHC_CD_GPIO, when your card (usingYes, that's the existing implementation, which does not require retry
GPIO detection) is removed, we can know the card's absence through the fake CARD_PRESENT flag in esdhc_readl_le().
As a result, we can quickly return ENOMEDIUM error without command sending. Finally mmc_rescan can know the card
is removed.
sending MMC_SEND_STATUS to know if card is removed.
On the other hand, with SDHCI_QUIRK_BROKEN_CARD_DETECTION for ESDHC_CD_GPIO, we will just send MMC_SEND_STATUSI just tracked it down a little bit. Interesting enough, it depends on
command (cd_irq->sdhci_tasklet_card->mmc_recan->mmc_sd_detect->mmc_sd_alive), and we will find error since the card
is already gone. Finally, we shall also know the card is removed.
This is really strange why the removal message shows up together with the next card inserting message.
Could u pls tell us more about what actually happened when the card is removed with my patches? Did the GPIO interrupt
happen? Was mmc_rescan() called? Did mmc_sd_detect() finally find error when it sent MMC_SEND_STATUS? What step did
the card removing procedure arrive at? Really really thanks a lot:-)
how I remove the card. If I do it slowly, when the gpio interrupt
triggers the MMC_SEND_STATUS query, the command can still retrieve
the card status successfully. Thus driver does not detect the card
removal. If I remove the card from slot quickly, I can see the removal
message.
With your patch series, in ESDHC_CD_GPIO case the driver will have
to send MMC_SEND_STATUS (with retry) to card for knowing its presence.
This is also an unpleasant behavior comparing to the existing code.
I think we should query gpio state to know card presence for this case.
Shawn