Re: [PATCH] mmc/sdio: don't allow interface to runtime-suspenduntil probe is finished.

[NeilBrown]

On Thu, 15 Dec 2011 20:39:28 -0800 Bing Zhao <bzhao@xxxxxxxxxxx> wrote:

> Hi Neil,
> 
> > In the other case where I do let it suspend early (And it never recovers
> > without the reset line being toggled) I see:
> > 
> > [ 2170.100982] mmc_wait_for_cmd 52 -> -110
> > [ 2170.105407] mmc_wait_for_cmd 52 -> -110
> > [ 2170.110260] mmc_wait_for_cmd 0 -> 0
> > [ 2170.115509] mmc_wait_for_cmd 8 -> -110
> > [ 2170.119842] mmc_wait_for_cmd 5 -> 0
> > [ 2170.123901] mmc_wait_for_cmd 5 -> 0
> > [ 2170.127929] mmc_wait_for_cmd 3 -> 0
> > [ 2170.131958] mmc_wait_for_cmd 7 -> 0
> 
> This works when reset line toggling was applied.

Yep.

> 
> > [ 2170.135986] mmc_wait_for_cmd 52 -> 0
> > [ 2170.140136] mmc_wait_for_cmd 52 -> 0
> > [ 2170.144226] mmc_wait_for_cmd 52 -> 0
> > [ 2170.148376] mmc_wait_for_cmd 52 -> 0
> > [ 2170.152465] mmc_wait_for_cmd 52 -> 0
> > 
> > 
> > which is much the same but then one second later:
> > 
> > [ 2171.166656] mmc_wait_for_cmd 52 -> 0
> > [ 2171.170806] mmc_wait_for_cmd 52 -> 0
> > [ 2171.175384] mmc_wait_for_cmd 0 -> 0
> > [ 2171.180603] mmc_wait_for_cmd 8 -> -110
> > [ 2171.185943] mmc_wait_for_cmd 5 -> -110
> 
> Here the CMD5 timeout is expected because SD8686 has already been initialized with CMD5,5,3,7.
> If you are able to skip re-initialization at this point, like what "powered_resume" does, you will probably get SD8686 continue to run.
> 

OK... I think we are nearly there.

If I configure the regulator to turn off on suspend and back on for resume, I
don't need to toggle the reset line.  I just works.
Previously I had the regulator permanently on.
So it seems we need one of:
  - remove/restore power
  - toggle reset
  - don't sent the CMD5,5,3,7 sequence again

I can neither guarantee that the regulator will be powered off or
that it will stay on.  That regulator is shared with bluetooth (on the same
package and wired together) so if the bluetooth is inactive the regulator
will drop-out when the wifi is suspended, but if bluetooth is active it won't.

What I could do is create a 'gpio-regulator' which is feed by the real
regulator and give it the reset line as its gpio.
Then when the wifi enters pm_suspend it will reset the wifi chip and release
the regulator which will power down if bluetooth is inactive.  When it
pm_resumes the regulator will be powered up and the reset line released.
(at least, that is the  theory).

So that will work for me, but I suspect more people will fall into this trap.
Is there some way would could detect this particular situation from the
libertas driver and print a message about needing a hard reset or a power off,
and pointing to documentation.

Or maybe the mmc layer could somehow ask if a reset is needed and not bother
if the device doesn't seem to have been powered down.
Just guessing here.


Thanks,
NeilBrown

Attachment: signature.asc
Description: PGP signature