[rt2x00-users] [RFC/RFT 00/15] Beaconing updates and tasklet conversion

[Helmut Schaa]

Hi Johannes,

Am Donnerstag, 6. Januar 2011 schrieb Johannes Stezenbach:
> Hi Helmut,
> 
> On Tue, Dec 28, 2010 at 05:03:55PM +0100, Helmut Schaa wrote:
> > Am Dienstag, 28. Dezember 2010 schrieb Johannes Stezenbach:
> > > 
> > > - PRE_TBTT irq
> > > - call ieee80211_beacon_get() to get updated TIM for next beacon
> > > - write updated beacon to hw in time before TBTT
> > >
> > > Can someone confirm my understanding is correct?
> > 
> > It is.
> > 
> > > If it is correct, how does it work on USB where we
> > > don't get a PRE_TBTT irq?
> > 
> > On USB we will never be able to generate correct beacons. We only push a new
> > beacon to the hw when
> > a) the beacon template changes
> > b) a tim bit gets set (==STA wake/sleep transition)
> > 
> > > And what would be the consequence of sending
> > > a beacon with wrong TIM?
> > 
> > The TIM should be correct on USB through the usage of set_tim but the DTIM
> > count won't be correct (for DTIM periods > 1). And we don't have a chance to
> > send out buffered mc and bc traffic out just after the DTIM beacon as
> > described in 802.11.
> 
> Thank you for the info, and apologies for the slow reply.

np

> I've read a bit more of the 802.11 spec and now I know a bit
> more but I've also got some new questions.
> (I looked at current rt2x00/experimental git)
> 
> For rt2800pci, on TBTT irq rt2x00lib_beacondone() is called
> which eventually calls ieee80211_get_buffered_bc() to get the
> bc and mc frames and queues them with rt2x00mac_tx().

Correct, that's done right after the beacon sendout.

> Q1: IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING is set for rt2800pci,
>     which means mac80211 will not queue the frame but send it
>     to the driver immediately.  Thus ieee80211_get_buffered_bc()
>     will not return any frames.  Right?

It's exactly the other way round. If IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING
is set mac80211 will buffer mc and bc frames for us and we can retrieve them
via ieee80211_get_buffered_bc.

> Q2: DRIVER_REQUIRE_ATIM_QUEUE is not set for rt2800pci, which means
>     bc + mc frames will be put on normal queue together with uc frames
>     by rt2x00mac_tx()

Correct.

> Q3: Even if IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING were not set,
>     without ATIM queue frames are queued behind other uc frames
>     and won't be sent immediately after DTIM as required by 802.11, right?

Correct. This can happen. I already proposed a possible solution for that but
had no time yet to investigate. We could use the MGMT queue for that as it
has precedence over the "normal" tx queues.

> So I guess a seperate ATIM queue is a requirement to get it right?

Not an ATIM queue but a queue with higher priority then the default
tx queues.

> Q4: For rt2800usb, IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING is not set,
>     thus bc/mc frames are queued seperately by mac80211; but since
>     ieee80211_get_buffered_bc() is not called for rt2800usb,
>     these frames are never sent.  Right?

As above it's exactly the other way round. mac80211 will send out
mc and bc traffic immediately on rt2800usb. Hence, sleeping stations
won't have a chance to receive bc and mc traffic (or only occasionally).

> I guess a possible way out for rt2800usb would be to read
> the TBTT_TIMER register and then set a hrtimer to fire
> at the time when PRE_TBTT irq would fire for rt2800pci.
> Any opinions on this?

Hmm, interessting approach. You won't get 100% accuracy but sounds
feasible.

An other way I thought of would be to enable PBF_LOOP_EN in MAC_SYS_CTRL. I
never tried that but it would mean that the rx path will trigger when we tx
frames. And when we "receive" a beacon we've just sent out we could trigger
the bc buffer flush. Just an idea ...

Helmut