RE: [PATCH v2] sdio: skip initialization on powered resume

[Sahitya Tummala <stummala@codeaurora.org>]

Hi Bing, Chris,

On Tue, 2010-09-07 at 19:10 -0700, Bing Zhao wrote:
> Hi Nicolas,
> 
> > -----Original Message-----
> > From: Nicolas Pitre [mailto:nico@fluxnic.net]
> > Sent: Tuesday, September 07, 2010 6:29 PM
> > To: Bing Zhao
> > Cc: linux-mmc@vger.kernel.org; Michal Miroslaw; Chris Ball; Andrew Morton
> > Subject: RE: [PATCH v2] sdio: skip initialization on powered resume
> > 
> > On Tue, 7 Sep 2010, Bing Zhao wrote:
> > 
> > > Thanks for the hint.
> > >
> > > The new patch skips reading CCCR, common CIS, and validation of
> > > vendor/device IDs inside mmc_sdio_init_card() when powered_resume is
> > > not zero.
> > 
> > Why do you skip the reading of the CIS and IDs validation?  That's
> > basically the main reason for still calling mmc_sdio_init_card().  And
> > that only requires CMD 52 so that should be fine.
> 
> While the system is suspended, the SDIO card could be in sleep mode (deep sleep or IEEE Power Save) as well. Reading CIS or any other CMD52 will fail if the card happens to be in sleep at this moment. If we skip re-initialization (including CCCR/CIS and IDs validation), mmc_sdio_init_card() returns success. Then the client driver's resume() handler will be called and the card can be woken up by client driver.

In one of your previous patches, "sdio: don't use CMD[357] as part of a
powered SDIO resume", its mentioned that there is an issue with CMD7 in
mmc_sdio_init_card() that is called during SDIO resume on Marvell 8686.

But in mmc_resume_host(), there is still a call to mmc_detect_change()
which in turn calls mmc_sdio_detect(), thus sending CMD7 to the card.
Does CMD7 to your card succeed after your client driver resume is
called?

Thanks,
Sahitya.

--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.