[ath9k-devel] ar9330 autosleep

[ath9k-devel] ar9330 autosleep

[Bob Copeland]

Hi Adrian, et al.,

I can't seem to find documentation on how the 'autosleep' feature on
AR9300+ works.  I'm familiar with the power-saving mechanisms of the
previous generation, which is essentially to use timers for beacons and
use ath9k_hw_setrxabort() to enable/disable RX.  But on newer chips
ath9k apparently doesn't do any of that thanks to the autosleep feature.

[ath9k-devel] ar9330 autosleep

[Adrian Chadd]

Hi,

IIRC, the autosleep stuff only started getting used by the AR9285 and
later, and it should be using the normal beacon interval timers to
work.

The normal way is:

* program normal beacon interval timers, and a "how long to stay awake
at each beacon interval to try and get a delayed beacon" value
somewhere;
* you put the chip into network sleep;
* the chip will send you an interrupt to say there's some stuff there;
* then in /theory/ you just push the chip into full-awake, check if
you have tx/rx, do your rx/tx, and then put the chip back to
network-sleep when you're doing fiddling with registers.

With autosleep, you can bypass doing the "force the chip awake" and
"force the chip back to network sleep" parts at each beacon, and only
force the chip awake when you want to do something (like rx/tx);
otherwise you don't have to go from force-awake to network sleep. Ie,
the chip stays in network sleep and will go back to sleep when it's
ready.

It's actually all in the ar9300 HAL that's in FreeBSD now:

https://svnweb.freebsd.org/base/head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_beacon.c?revision=278807&view=markup

look at set_sta_beacon_timers().

I'm still debugging some of the sleep stuff with the AR9380 on
FreeBSD. The later chips do the right thing, but the AR9380 beacon
programming for /some/ reason is not hearing beacons in network sleep
mode and eventually the BMISS interrupts cause a rescan/reassociation.
IT doesn't happen on the later chips (AR9485, AR9462, .etc.) sigh.




-adrian

[ath9k-devel] ar9330 autosleep

[Sujith Manoharan]

Adrian Chadd wrote:
> I'm still debugging some of the sleep stuff with the AR9380 on
> FreeBSD. The later chips do the right thing, but the AR9380 beacon
> programming for /some/ reason is not hearing beacons in network sleep
> mode and eventually the BMISS interrupts cause a rescan/reassociation.
> IT doesn't happen on the later chips (AR9485, AR9462, .etc.) sigh.

Relying on the HW TIM interrupt wasn't reliable, IIRC. Instead of
using ATH9K_INT_TIM to process a beacon which has the TIM bit set
for our station, ath9k uses ATH9K_INT_TIM_TIMER. AR_TIM_TIMER_EN
is always enabled in station mode, so power-saving has lots of
room for improvement, since we completely ignore DTIM and always
wake up to receive every beacon.

Beacon/TIM processing is done in mac80211, for drivers that set
IEEE80211_HW_PS_NULLFUNC_STACK.

I am not sure why parsing beacons in the HW for the TIM IE
is unreliable.

Sujith

[ath9k-devel] ar9330 autosleep

[Bob Copeland]

On Fri, Apr 03, 2015 at 07:47:18AM +0530, Sujith Manoharan wrote:
> Adrian Chadd wrote:
> > I'm still debugging some of the sleep stuff with the AR9380 on
> > FreeBSD. The later chips do the right thing, but the AR9380 beacon
> > programming for /some/ reason is not hearing beacons in network sleep
> > mode and eventually the BMISS interrupts cause a rescan/reassociation.
> > IT doesn't happen on the later chips (AR9485, AR9462, .etc.) sigh.
> 
> Relying on the HW TIM interrupt wasn't reliable, IIRC. Instead of
> using ATH9K_INT_TIM to process a beacon which has the TIM bit set
> for our station, ath9k uses ATH9K_INT_TIM_TIMER. AR_TIM_TIMER_EN
> is always enabled in station mode, so power-saving has lots of
> room for improvement, since we completely ignore DTIM and always
> wake up to receive every beacon.

AR_TIM_TIMER_EN is set, but the ATH9K_INT_TIM_TIMER bit seems to be
masked off[1], and the autosleep check in this code in ath_isr would
prevent it doing anything anyway:

    if (!(ah->caps.hw_caps & ATH9K_HW_CAP_AUTOSLEEP))
            if (status & ATH9K_INT_TIM_TIMER) {
                    if (ATH_DBG_WARN_ON_ONCE(sc->ps_idle))
                            goto chip_reset;
                    /* Clear RxAbort bit so that we can
                     * receive frames */
                    ath9k_setpower(sc, ATH9K_PM_AWAKE);
                    spin_lock(&sc->sc_pm_lock);
                    ath9k_hw_setrxabort(sc->sc_ah, 0);
                    sc->ps_flags |= PS_WAIT_FOR_BEACON;
                    spin_unlock(&sc->sc_pm_lock);
            }

So I'm still missing the part where we wake hardware up on this version.
It seemed to work for me though.

[1] code that sets it in ath9k_enable_ps() is surrounded by !AUTOSLEEP
capability check, also ar9003_mac.c is missing the part where we set
TIM_TIMER bit in ISR status based on a generic timer interrupt.

-- 
Bob Copeland %% http://bobcopeland.com/

[ath9k-devel] ar9330 autosleep

[Sujith Manoharan]

Bob Copeland wrote:
> So I'm still missing the part where we wake hardware up on this version.
> It seemed to work for me though.

Sorry, I was referring to the PS mechanism on chips which don't
support autosleep.

For autosleep, no special handling in the driver is required
except the initial duration programming done in
ath9k_hw_set_sta_beacon_timers(). The HW wakes up to receive
every beacon and automatically goes back to network sleep.

Sujith

[ath9k-devel] ar9330 autosleep

[Adrian Chadd]

On 3 April 2015 at 19:51, Sujith Manoharan <sujith@msujith.org> wrote:
> Bob Copeland wrote:
>> So I'm still missing the part where we wake hardware up on this version.
>> It seemed to work for me though.
>
> Sorry, I was referring to the PS mechanism on chips which don't
> support autosleep.
>
> For autosleep, no special handling in the driver is required
> except the initial duration programming done in
> ath9k_hw_set_sta_beacon_timers(). The HW wakes up to receive
> every beacon and automatically goes back to network sleep.

So this is what I'm doing in FreeBSD as an experiment. It's .. mostly
working out okay.

The trick (!) is to nail the thing up to full-awake before you do
anything, as there's no way to guarantee the chip is awake when you're
handling things. I bet I could write a receive path that didn't touch
anything except the descriptors, but I don't know if the refill path
would work without waking things up.



-adrian

[ath9k-devel] ar9330 autosleep

[Bob Copeland]

On Sat, Apr 04, 2015 at 08:21:59AM +0530, Sujith Manoharan wrote:
> Bob Copeland wrote:
> > So I'm still missing the part where we wake hardware up on this version.
> > It seemed to work for me though.
> 
> Sorry, I was referring to the PS mechanism on chips which don't
> support autosleep.
> 
> For autosleep, no special handling in the driver is required
> except the initial duration programming done in
> ath9k_hw_set_sta_beacon_timers(). The HW wakes up to receive
> every beacon and automatically goes back to network sleep.

Ok, got it, so if I have a need to wake up for beacons from multiple
APs with different TSFs, then autosleep probably wouldn't work for me?
(I already implemented what I need with the TIM_TIMER on these chips,
just asking to confirm my understanding.)

-- 
Bob Copeland %% http://bobcopeland.com/

[ath9k-devel] ar9330 autosleep

[Sujith Manoharan]

Bob Copeland wrote:
> Ok, got it, so if I have a need to wake up for beacons from multiple
> APs with different TSFs, then autosleep probably wouldn't work for me?
> (I already implemented what I need with the TIM_TIMER on these chips,
> just asking to confirm my understanding.)

I think so, I haven't checked. :-)
It might be possible using the secondary TSF/BSSID that is allowed
in some chips, which was added to support Mesh/P2P.

https://github.com/qca/qcamain_open_hal_public/blob/master/hal/ar9300/osprey_reg_map.h#L847

Sujith