Hi, Anton and Chris Have you any comment about this serial patches[patch 2/3/4, except 1]? Best Regards Jerry Huang > -----Original Message----- > From: linux-mmc-owner@xxxxxxxxxxxxxxx [mailto:linux-mmc- > owner@xxxxxxxxxxxxxxx] On Behalf Of Huang Changming-R66093 > Sent: Tuesday, November 06, 2012 9:56 AM > To: Anton Vorontsov; Chris Ball > Cc: linux-mmc@xxxxxxxxxxxxxxx; Johan Rudholm > Subject: RE: [PATCH 2/4 v4] MMC/SD: Add callback function to detect card > > Hi, Anton and Chris > Have you any comment about the serial patch [patch 2/3/4, please ignore > patch1]? > Reviewed-By: Johan Rudholm <johan.rudholm@xxxxxxxxxxxxxx> > > Best Regards > Jerry Huang > > > > -----Original Message----- > > From: Johan Rudholm [mailto:jrudholm@xxxxxxxxx] > > Sent: Monday, November 05, 2012 10:08 PM > > To: Huang Changming-R66093 > > Cc: linux-mmc@xxxxxxxxxxxxxxx; Anton Vorontsov; Chris Ball > > Subject: Re: [PATCH 2/4 v4] MMC/SD: Add callback function to detect > > card > > > > Hi, > > > > 2012/11/5 Huang Changming-R66093 <r66093@xxxxxxxxxxxxx>: > > >> > > >> 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? > > > > > > Yes, You are right. > > > > Ok, it's a bit hard to understand how this can lead to a noticeable > > performance impact, but OK. :) > > > > >> 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). > > > > > > Our silicones has this pin to do card detect, but some boards don't > > generate the interrupt when card is inserted or removed. So I have to > > use the poll mode. > > > > > >> > 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... > > >> > > > I don't see this on our board, when card is inserted or removed, the > > register field can reflect this state correctly. > > > > We see a difference on our boards with this patch, but no functional > > change (actually a removed card is detected earlier now), so from my > > perspective: > > > > Reviewed-By: Johan Rudholm <johan.rudholm@xxxxxxxxxxxxxx> > > > > //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 -- 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
