High power consumption after suspending

[Dan Williams]

On Tue, 2009-12-22 at 15:00 +0100, Norbert Roos wrote:
> Hello,
> 
> We are developing a mobile device here, using a 88W8686. We discovered a 
> rather high power consumption during sleep with about 100mA more than 
> when the driver is not loaded and the chip is powered down with pin PDn. 
> We are using a 2.6.27.3 kernel and if_spi.

So the 2.6.27 kernel, and the 2.6.27 *driver*?  The SDIO bits were only
merged in 2.6.27 so they are a bit old at that point.  SDIO deep sleep
support has recently been added to 2.6.31 or 2.6.32 and that's probably
what you're looking for.  Deep sleep actually puts the chip to sleep,
where previous sleep support was limited to USB bus suspends and
OLPC-style suspend/resume.

Any chance you can try to backport the 2.6.32 driver to your kernel (it
shouldn't be that hard actually, usually just backing out a few cleanup
patches and such as kernel interfaces change) and see if the deep sleep
support there will work for you?

> I would like to reduce this current now, but so far i didn't find any 
> information about what has to be actually done for putting the chip into 
> a low power mode. From the source code i see that the suspend function 
> sends a CMD_802_11_HOST_SLEEP_ACTIVATE, which is obviously succesful 
> (didn't return an error, and the callback function has also been called) 
> but does not power down the chip.

What firmware version?

HOST_SLEEP is used to tell the 8686 that the /host/ is going to sleep,
not to put the chip to sleep.  You really do want DEEP_SLEEP.  So it's
no wonder that HOST_SLEEP wasn't doing anything.  You use HOST_SLEEP_CFG
to set the conditions that the 8686 will use to wake up the host,
basically it's Wake-on-WLAN.

> So my overall question is, what should be done to power down the chip? 
> Should the HOST_SLEEP_ACTIVATE command be sufficient and we have a 
> different problem here with our device?

DEEP_SLEEP.

> Or should do it the deep sleep command? I have already looked at the 
> deep sleep patch from september, but i don't understand why there has to 
> be a timer and an interface to user space; in my understanding the 
> driver gets somewhen told "And now suspend yourself!" and that should be 
> all... Anyway, i tried also to send the CMD_802_11_DEEP_SLEEP following 
> the HOST_SLEEP_ACTIVATE, resulting in a completely dead device.
> 
> Or is setting the PDn pin the only way to power down the chip? Or is 
> there another way applicable?

DEEP_SLEEP should put the chip to sleep, but each bus type has a
different method of waking the chip up because the bus itself is
presumably in low-power mode or even off completely.  This is usually a
GPIO on your specific hardware device that is toggled by your CPU after
the CPU is awake to wake the SD8686 back up.  Not exactly sure how that
works on a SPI bus but I'd assume it's not much different than SDIO.

> And another question: Will an established WLAN connection survive the 
> power-down and power-up, or does it have to be reconnected (which will 
> probably terminate a TCP connection running over the WLAN connection)?

It's helpful to understand a bit how WiFi works here; the AP and STA (ie
the 8686) need to periodically ping each other, otherwise the AP will
disassociate the STA because the STA may have simply gone away.  The STA
also needs to keep track of the AP's beacons otherwise the STA will
assume that it has moved out of range of the AP and terminate the WLAN
connection itself.  So no, don't expect a connection to survive a deep
sleep unless the deep sleep lasts less than say 100 or 200ms.  But deep
sleep isn't really meant for that short of an interval.

There are really two power-saving mechanisms.  The first is 802.11 PS
which is probably what you want.  This allows the chip to go into a
low-power mode for about 50% - 75% of the time *between AP beacons* (so
for about 75ms or more assuming a standard beacon interval of 100ms) if
there is no traffic to send or receive.  This is configured in the
driver by CMD_802_11_PS_MODE.  IP connections will survive in this mode
because the chip is never completely powered down, and it wakes up often
enough so that it stays associated to the AP.

Then there's deep sleep mode where the chip really is mostly powered
off.  It takes a bit of time to wake up from deep sleep so you simply
can't keep the association with the AP.  That's also why there are
timers; it physically takes time for the chip's function blocks to power
up and stabilize, and for the firmware to come back from sleep.  But
this mode also provides the most power savings.  Of course you want to
use it when the device itself goes to sleep for longer periods of time.

Dan