WLAN vs. suspend/resume (stable-tracking)

Andy Green andy at openmoko.com
Wed Nov 19 10:34:04 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
| Let's put this into a new thread.
| With the recent fixes, s3cmci survives suspend/resume or module
| removal and re-insertion.
| However, the AR6k module is not detected on resume or insertion.
| This happens whether I load the ar6k WLAN stack (ar6000.ko) or
| not, so it's a problem between the AR6k module and the SDIO stack.
| A work-around to bring WLAN back to life after resume is to build
| s3cmci as a module and to do the following:
| # rmmod s3cmci.ko
| # echo 0 >/sys/bus/platform/drivers/gta02-pm-wlan/gta02-pm-wlan.0/power_on
| # echo 1 >/sys/bus/platform/drivers/gta02-pm-wlan/gta02-pm-wlan.0/power_on
| # insmod s3cmci.ko

This is obviously good we have any kind of workaround but...

| The SDIO stack isn't sending anything nasty to the module on suspend
| or removal. On resume/insertion without a prior reset, the command
| sequence is as follows:
| CMD0 (reset) -> OK
| CMD8 (check voltage MMC-style) -> timeout
| CMD5 (check voltage SDIO-style) -> timeout
| CMD5 is where we depart from the normal initialization sequence.
| The normal response would be an acknowledgement.
| So it seems that CMD0 doesn't return the card to Idle. Time to
| look at what's going on on the wire ...

It might be worth dumping the suspend and resume packets from (working
suspend) Atheros stack for comparison, annoying as that is to have to go
back to.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list