rt2x00: Add autowakeup timer for receiving beacons while in powersave mode

Add a delayed work structure which can be used to wakeup the device just before a beacon from the AP is expected. This then allows the device to receive the beacon, check if there are pending broadcast or multicast frames.

TODO: Split out mac80211 changes into a separate patch. We also need
to know if we need this check in mac80211 or in the driver. Personally I think the check belongs in mac80211, but at this time that work has been deferred to the drivers. However this means that a lot of logic is needed in the driver to check if the correct IE is available, and then check the value, while mac80211 will obtains that exact IE anyway during RX processing anyway...

Quoted 10 lines

Add a delayed work structure which can be used to wakeup the device just before a beacon from the AP is expected. This then allows the device to receive the beacon, check if there are pending broadcast or multicast frames.

TODO: Split out mac80211 changes into a separate patch. We also need
to know if we need this check in mac80211 or in the driver. Personally I think the check belongs in mac80211, but at this time that work has been deferred to the drivers. However this means that a lot of logic is needed in the driver to check if the correct IE is available, and then check the value, while mac80211 will obtains that exact IE anyway during RX processing anyway...

Hmm. I've always said that there's no efficient way to do this in mac80211. If you do it close to the beacon, unexpected latency means that we miss -- this can be severe if something else is happening in the system, especially with USB devices. If you do it early before the beacon, then you don't save much power. As a consequence, I don't really like this in mac80211.

However, it seems you only added "stay awake after beacon" code to mac80211 that checks the TIM. Assuming the device actually stays awake for multicast traffic by itself that seems like an option, though I wouldn't wait for the next beacon before going to sleep again -- wouldn't that happen with the timer anyway?

Quoted 15 lines

Quoted 7 lines

TODO: Split out mac80211 changes into a separate patch. We also need
to know if we need this check in mac80211 or in the driver. Personally I think the check belongs in mac80211, but at this time that work has been deferred to the drivers. However this means that a lot of logic is needed in the driver to check if the correct IE is available, and then check the value, while mac80211 will obtains that exact IE anyway during RX processing anyway...

Hmm. I've always said that there's no efficient way to do this in mac80211. If you do it close to the beacon, unexpected latency means that we miss -- this can be severe if something else is happening in the system, especially with USB devices. If you do it early before the beacon, then you don't save much power. As a consequence, I don't really like this in mac80211.

Quoted 5 lines

However, it seems you only added "stay awake after beacon" code to mac80211 that checks the TIM. Assuming the device actually stays awake for multicast traffic by itself that seems like an option, though I wouldn't wait for the next beacon before going to sleep again -- wouldn't that happen with the timer anyway?

The timer is needed to automatically wake the device up in time to receive the beacon. When the beacon is received all the driver needs to know if the device should go back to sleep again for the next beacon period.

This is a similar behavior as carl9170 driver, which currently checks for pending Mcast/Bcast frames in the RX path just before the frame is send to mac80211.

drivers/net/wireless/rt2x00/rt2x00config.c +5 -0

@@ -192,6 +192,11 @@ void rt2x00lib_config(struct rt2x00_dev *rt2x00dev,
 		       sizeof(libconf.channel));
 	}
 
+	if (test_bit(DRIVER_REQUIRE_PS_AUTOWAKE, &rt2x00dev->flags) &&
+	    (ieee80211_flags & IEEE80211_CONF_CHANGE_PS) &&
+	    !(conf->flags & IEEE80211_CONF_PS))
+		cancel_delayed_work_sync(&rt2x00dev->autowakeup_work);	
+
 	/*
 	 * Start configuration.
 	 */

Quoted 7 lines

+     if (test_bit(DRIVER_REQUIRE_PS_AUTOWAKE, &rt2x00dev->flags) &&
+         (ieee80211_flags & IEEE80211_CONF_CHANGE_PS) &&
+         (conf->flags & IEEE80211_CONF_PS))
+             queue_delayed_work(rt2x00dev->workqueue,
+                                &rt2x00dev->autowakeup_work,
+                                msecs_to_jiffies(rt2x00dev->beacon_int) - 1); +

I have doubts about this part.  Doesn't this just catch one beacon?  I'm not sure how often mac80211 calls the .config op, I thought it is called once when going to sleep, and then the hw/fw/driver is responsible to wakeup every n'th beacon (according to the configured listen interval).

Also, I think rt2x00dev->beacon_int is in TUs, not msecs.

Quoted 2 lines

Also, I think rt2x00dev->beacon_int is in TUs, not msecs.

Nope, it is in msecs :)

Add a delayed work structure which can be used to wakeup the device just before a beacon from the AP is expected. This then allows the device to receive the beacon, check if there are pending broadcast or multicast frames.

TODO: Split out mac80211 changes into a separate patch. We also need to know if we need this check in mac80211 or in the driver. Personally I think the check belongs in mac80211, but at this time that work has been deferred to the drivers. However this means that a lot of logic is needed in the driver to check if the correct IE is available, and then check the value, while mac80211 will obtains that exact IE anyway during RX processing anyway...

Quoted 4 lines

Add a delayed work structure which can be used to wakeup the device just before a beacon from the AP is expected. This then allows the device to receive the beacon, check if there are pending broadcast or multicast frames.

So the firmware/hardware doesn't have support for tracking and waking up for beacons? I didn't even know that such hardware exists :) Waking up for beacons from host sounds very inefficient and unrealiable. All the devices I have seen either do this in firmware or hardware due to time constraints. Even at76c50x-usb, which is ancient, does all this in firmware.

Are you sure there's no way to do this with hardware?

Quoted 7 lines

TODO: Split out mac80211 changes into a separate patch. We also need to know if we need this check in mac80211 or in the driver. Personally I think the check belongs in mac80211, but at this time that work has been deferred to the drivers. However this means that a lot of logic is needed in the driver to check if the correct IE is available, and then check the value, while mac80211 will obtains that exact IE anyway during RX processing anyway...

I'm worried that client power save support in mac80211 is getting quite complex already. How many drivers need this feature?

Well the official Ralink driver also uses a timer to wakeup the hardware, there are however registers which suggest support for autowake functionality.

Jay, Dennis, Eddy, can you explain a but how the autowake functionality is implemented in the rt2800usb firmware?

Quoted 5 lines

Well the official Ralink driver also uses a timer to wakeup the hardware, there are however registers which suggest support for autowake functionality.

Jay, Dennis, Eddy, can you explain a but how the autowake functionality is implemented in the rt2800usb firmware?

Current power saving and wake up procedure as below.

PCI:
1. Driver sends power-save command to firmware to turn off RF/BBP and configure mac register (AUTO_WAKEUP_CFG) to set a hardware timer counter.
2. When hardware timer timeout, issue an interrupt and notify the driver.
3. Driver send wake up command to firmware to turn on RF/BBP and ready to process packets

USB:
1. Driver sends power-save command to firmware to turn off RF/BBP and set a software timer to emulate the purpose of hardware timer.
2. When software timer timeout, driver sends wake up command to firmware to turn on RF/BBP and ready to process packets.

Note: for future projects, hw or firmware will take more psm mechanism to reduce some latency between firmware and host to save more power.

Thanks. So I'll add this routine to the rt2800usb driver then. :)

Johannes, if you don't want to add the complexity for checking the "pending MC/BC frames" in
a received frame. Would you mind if I add some utility functions to mac80211 then? That way the
logic is still shared for the drivers that need it, but it doesn't impact the code paths in mac80211 itself...

So the firmware/hardware doesn't have support for tracking and waking up for beacons? I didn't even know that such hardware exists :) Waking up for beacons from host sounds very inefficient and unrealiable. All the devices I have seen either do this in firmware or hardware due to time constraints. Even at76c50x-usb, which is ancient, does all this in firmware.

Quoted 6 lines · Kalle Valo

So the firmware/hardware doesn't have support for tracking and waking up for beacons? I didn't even know that such hardware exists :) Waking up for beacons from host sounds very inefficient and unrealiable. All the devices I have seen either do this in firmware or hardware due to time constraints. Even at76c50x-usb, which is ancient, does all this in firmware.

IMHO this is a bit exaggerated.  Given that the beacon interval is typically ~100 msecs, and typical worst cast irq latencies on Linux 2.6 are a few 100 usecs, we can sleep e.g. 90msecs and wake up in time to catch the beacon with high probability, thus saving 90% on PHY power.  Not perfect, but good enough, isn't it?

Half-related to above, and purely from user perspective. Is there a way to disable power saving for WiFi cards globally by default (for example, by passing an option to device driver)? Having power saving turned on by default makes sense for laptops, but doesn't make much sense for desktops. And in my case (due to problem with at least some rt2xxx chips that Ivo described) it causes relatively frequent disconnects/reconnects from/to AP due to lost beacons.

For my desktop system, I'd rather pass an option to device driver to have power saving default to off, and have a smoother network experience.

Quoted 8 lines · Aleksandar Milivojevic

Half-related to above, and purely from user perspective.  Is there a way to disable power saving for WiFi cards globally by default (for example, by passing an option to device driver)?  Having power saving turned on by default makes sense for laptops, but doesn't make much sense for desktops.  And in my case (due to problem with at least some rt2xxx chips that Ivo described) it causes relatively frequent disconnects/reconnects from/to AP due to lost beacons.

Quoted 3 lines

For my desktop system, I'd rather pass an option to device driver to have power saving default to off, and have a smoother network experience.

There is CONFIG_CFG80211_DEFAULT_PS kconfig option, but I'm not aware of any other way to globally do this. I can only think of using iw or iwconfig to disable power save per device.

Quoted 5 lines · Kalle Valo

Aleksandar Milivojevic <[email protected]> writes:

There is CONFIG_CFG80211_DEFAULT_PS kconfig option, but I'm not aware of any other way to globally do this. I can only think of using iw or iwconfig to disable power save per device.

I'm using iwconfig currently to disable power saving for wireless card on my desktop after it boots up. However, from user perspective of things, it would be awesome if default was not hard coded in the kernel.

Though, I must admit that if it wasn't for the problem discussed earlier in this thread, I probably wouldn't even notice power saving was set to on. I'm not sure if there are any other more subtle downsides of having power saving enabled.

Quoted 4 lines · Kalle Valo

There is CONFIG_CFG80211_DEFAULT_PS kconfig option, but I'm not aware of any other way to globally do this. I can only think of using iw or iwconfig to disable power save per device.

I'm using iwconfig currently to disable power saving for wireless card on my desktop after it boots up. However, from user perspective of things, it would be awesome if default was not hard coded in the kernel.

Quoted 6 lines · Kalle Valo

So the firmware/hardware doesn't have support for tracking and waking up for beacons? I didn't even know that such hardware exists :) Waking up for beacons from host sounds very inefficient and unrealiable. All the devices I have seen either do this in firmware or hardware due to time constraints. Even at76c50x-usb, which is ancient, does all this in firmware.

IMHO this is a bit exaggerated.

Given that the beacon interval is typically ~100 msecs, and typical
worst cast irq latencies on Linux 2.6 are a few 100 usecs, we can sleep e.g. 90msecs and wake up in time to catch the beacon with high probability, thus saving 90% on PHY power. Not perfect, but good enough, isn't it?

So I have my concerns if it really makes sense to implement this in mac80211. Extra complexity (and extra maintenance) for two sub-optimal (from power save point of view) hardware.