On 04/12/12 06:05, Johannes Berg wrote:
On Wed, 2012-04-11 at 13:00 +0200, Marco Porsch wrote:
Thus, I think we will need an additional/extended interface
mac80211<->driver here.
I see two possibilities:
a) request the next wakeup time from mac80211 each time the hardware is
put to sleep (e.g. from ath9k_ps_restore).
b) give a whole list of periodic wakeup events of all vif to the driver.
Then the driver is supposed to sort out the closest event.
What would be the better approach for such an interface? Or maybe a
completely different idea?
What time units would that be in, and how could you correlate them?
I did not take an exhaustive overview over all possible drivers.
But as the current mac80211<->driver interface carries only beacon
interval (in TU) and DTIM period, that should be a good starting point.
ath9k additionally relies on the neighbors address to check whether it
can resume sleep after receiving an expected beacon (see setting of
'is_mybeacon' in ath_rx_tasklet).
Concerning correlation, in mesh mode we recently have t_offset (in TSF
increments) stored in sta_info and in client mode the drivers'
synchronised TSF should be the reference (but I am not quite sure what
happens when one client is associated to multiple AP).
Regards,
Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
