Atheros HAL: Network Sleep support
| Driver | HAL | Supported Hardware | 802.11n support | Debugging |
Network Sleep is the Atheros term for allowing the MAC to drive whether to put itself and the PHY/radio to sleep for certain amounts of time. It forms part of the overall power saving strategy.
Overview
The Atheros MAC supports three power modes:
- full-sleep
- network-sleep
- force-awake
"Full-sleep" is where the MAC, radio and PHY are forced asleep. In this mode only registers in the host interface (eg SYNC interrupts and power control registers) can be modified.
"Force-awake" is where the MAC, radio and PHY are constantly on.
"Network-sleep" is where the MAC controls whether itself, radio and PHY are required to be on.
Network Sleep
The network sleep functionality requires a handful of pieces in order to allow the hardware to determine whether it needs to be awake or not.
- If the NIC is awake and not actively transmitting or receiving anything, it can decide to go back to sleep.
- If the NIC has any frames queued in the transmit queue(s), then it will stay awake until they are transmitted (and ACKed if appropriate) - after which the NIC may enter sleep.
- The NIC will wake up in order to receive beacon frames from the access point (in station mode) or, in later hardware, when beacons are expected from other IBSS devices in adhoc mode.
- If the NIC sees a beacon frame and it has the multicast bit set in the TIM, the NIC stays awake to receive CAB traffic and will go to sleep once CAB is complete (TODO: does all the hardware support this? AR5210/AR5211?)
- If the NIC sees a beacon frame and it has its own TIM bit set, the NIC may stay awake (TODO: does it? I haven't seen it stay awake after the beacon; but it may somehow send the beacon frame up to us. Right now all beacon frames are received up by net80211.)
In order for the MAC to wake up for each beacon interval, the MAC beacon interval timers must be configured correctly in order for the NIC to wake up around the time the access point or IBSS will be broadcasting a beacon. The MAC will then listen for the beacon from the BSS and synchronize its own TSF timer value against the beacon TSF. If the beacon interval isn't configured correctly then the NIC will not wake up in time to hear the beacon and will simply go back to sleep.
Since some frames are generated by the MAC itself, a separate bit in AR_STA_ID1 is used to determine whether self-generated frames have the power management bit in the 802.11 header set or not. If this isn't set correctly then the MAC may respond with a frame with pwrmgt=0, which hints to the AP or IBSS node that it's awake when it may not be.
Programming
The HAL method "ah_setPowerMode(powerMode, setChip) controls both whether the MAC is considered awake or asleep and whether to configure the hardware for a sleep state.
- powerMode is the power mode - HAL_PM_FULLSLEEP, HAL_PM_FORCEAWAKE, HAL_PM_NETWORK_SLEEP
- setChip is whether to program the chip with the power mode, or just send self-generated frames with the power management bit set/cleared.
The NIC must be forced awake before most registers are touched. The NIC can be put back to sleep afterwards. For example, to transmit a frame:
- force the NIC awake;
- update TxDP or the link pointer in the transmit queue;
- call ath_hal_txstart() to start transmission if it isn't already running;
- put the NIC back into network-sleep.
The NIC will then transmit the frame(s) and go to sleep when completed.
In order for the NIC to wakeup for each beacon, one of the HAL beacon setup routines must be used to configure the beacon interval, the initial TSF and how long to stay awake during each beacon interval.
TODO
- More examples
- Chip specific behaviours
- Chip specific bugs
- How does it work for IBSS
- Can we set it up to not pass up all the beacons and instead only if the beacon indicates TIM=1 for us, or the multicast bit in the DTIM is set.
- Figure out whether when the NIC is forced awake, we can keep the self-generated frame bit set to 1 so it always sets pwrmgt=1. That way we can leak out frames (eg in response to ps-poll) whilst keeping the NIC in network sleep.