[PATCH 0/4] Extend sdhci-esdhc-imx card_detect and write_protect support for mx5

Shawn Guo shawn.guo at freescale.com
Mon Jun 20 06:41:04 EDT 2011


Hi Arnaud,

Sorry for the late replying.  Somehow I missed the message.

On Thu, Jun 16, 2011 at 08:32:33PM +0200, Arnaud Patard wrote:
> Shawn Guo <shawn.guo at freescale.com> writes:
> 
> Hi,
> 
> > On Fri, Jun 10, 2011 at 06:42:48PM +0800, Shawn Guo wrote:
> >> The card-present polling within sdhci based driver is very expensive
> >> in terms of the impact to system performance.  We observe a few
> >> system performance issues from Freescale and Linaro on mx5 platforms,
> >> which have been proved card polling related.
> >> 
> >> The patch set extends the current sdhci-esdhc-imx card_detect and
> >> write_protect support to cover mx5 platforms, and solves above
> >> performance issues.
> >> 
> >> Shawn Guo (4):
> >>       mmc: sdhci: fix interrupt storm from card detection
> >>       mmc: sdhci-esdhc-imx: SDHCI_CARD_PRESENT does not get cleared
> >>       mmc: sdhci-esdhc-imx: remove "WP" from flag ESDHC_FLAG_GPIO_FOR_CD_WP
> >>       mmc: sdhci-esdhc-imx: extend card_detect and write_protect support
> >> 
> > Hi Arnaud,
> >
> > Any chance to play with it yet?
> 
> Finally managed to build a kernel with this version of the
> patchset. While I'm not polling anymore, I'm getting a lot of interrupts
> if the card is not inserted. Theses interrupts are not happening if the
> card is inserted. I can see things like this in the logs :
> sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000080
> 
> [ of course, the bit of the present state register indicating card
> presence is equal to 0 ]
> 
> I've tested the SIGNAL case only. Don't know if switch to GPIO may help.
> Do you have same kind of issue on your side ?
> 
I reproduced the issue on my side with turn on debug switch (I should
do so from the beginning).

GPIO mode does not have this issue.  But you do not have to switch to
GPIO, as I have got it fixed in the v3 of the patch set (posted out
a few minutes ago).  It can apply on linux-next cleanly.  You need
to note that naming 'SIGNAL' has been changed to 'CONTROLLER' per
Wolfram's comment.

Thanks for testing.

-- 
Regards,
Shawn




More information about the linux-arm-kernel mailing list