[rt2x00-users] [RFC/RFT 00/15] Beaconing updates and tasklet conversion
helmut.schaa at googlemail.com
Fri Jan 7 04:02:23 EST 2011
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.
> 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
> 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()
> 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
> 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
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 ...
More information about the users