Hi Jerry, 2012/11/2 Huang Changming-R66093 <r66093@xxxxxxxxxxxxx>: > Hi, Johan, > When quicks SDHCI_QUIRK_BROKEN_CARD_DETECTION is set, the driver will poll the card status with the command CMD13 periodically, then many interrupts will be generated, which affect the performance. Ok, just to see if I understand the scenario correctly: SDHCI_QUIRK_BROKEN_CARD_DETECTION causes the MMC_CAP_NEEDS_POLL cap to be set, which will cause mmc_rescan to be run at a one second interval. mmc_rescan calls bus_ops->detect (mmc_sd_detect) and this in turn calls _mmc_detect_card_removed, which will do the bus_ops->alive and send CMD13. So in this case, one CMD13 is sent per second, right? Is this the cause of the performance issue? A thought: if the host hardware does have a GPIO card detect pin hooked up, would it not be possible to make this pin generate an IRQ whenever a card is inserted or removed? This is what we do in the MMCI driver, for instance (mmci_cd_irq). > Yes, some cases to detect GPIO can't be trusted, so I only just implement this callback in eSDHC-of driver. that is to say, just when the platform support it, this callback can be implement, if not, continue to send the command CMD13. I'm just wondering how this will affect our system, where we use the cd GPIO to generate detect jobs on card insert/remove, but where the cd pin is not 100% synchronized with the electrical connection of the power and cmd line of the SD-card. So if I remember correctly, the cd pin may report that the card has been removed, but there is still an electric connection and the card is alive... Kind regards, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
