Hi all,

Here's another hacking update. The TL;DR version - please update to
-HEAD if you're testing 802.11n on ath(4).

* I've finished re-engineering the TX aggregation path in preparation
for the AR9380 support. Rui reported a rather subtle bug and after a
few days of narrowing it down, we nailed it this evening. I've been
using an AR9380, AR9390 and AR9485 in 11n (STA) mode and verified that
things are behaving quite nicely.

* I've disabled the software queue pause/resume stuff for now, at
least until I finish implementing a ps-poll implementation. Garrett
Cooper donated a HP Touchpad to me (thanks Garrett!) that includes a
dual-band atheros 600x wifi module. This does some pretty aggressive
ps-poll behaviour for power saving, so it quickly showed the bugs that
I had introduced.

* I've added a (somewhat temporary) ALQ logging method to if_ath so I
can start logging driver events. Until KTR lets me store arbitrary
binary data and index it per driver, I plan on using this to debug TX
and RX descriptors as well as some general events such as channel
change/scan, reset, calibration and such. I'll also likely make the
KTR debugging in ath(4) also log to the ath ALQ code. Why? Because I
have a need to verify the device behaviour against both the rest of
the scheduler framework (hence KTR) as well as against packet TX/RX
(hence ALQ.) Right now the ALQ code logs the EDMA descriptors to ALQ
(which I've been using to debug the TX aggregation support for AR9380)
and I'll add this soon to the legacy descriptors.

What I'm going to do next:

* I'd like to extend the net80211 alq code I wrote to be per-device
and per-vap. Right now it's global (but with a per-wlan marker.) Then
I can remove if_ath_alq.[ch] and have the device log to the net80211
ALQ. That way I can combine driver events, descriptor events _and_
net80211 stack events in one ordered queue. That'll make debugging
easier - imagine debugging powersave behvaiour or background scan by
having this kind of light weight logging. Woo! No more printf
debugging!

* I'm going to finish off the ps-poll implementation for ath(4), so it
first serves out frames from the driver software TX queue, before it
goes to the net80211 power save queue. That requires a little more
thought and planning.

Once the ps-poll support is in the tree, I'll flip that back on and
request people test things out. That should conclude the very basic
support needed for saying "our 802.11n AP mode is ready!"

* I'll teach ath(4) about the LDPC support in AR9380;

* I'll teach the ath(4) rate control code to use LDPC and STBC on
single-stream rates, but only where appropriate (ie, if the device
supports it, if the device is TXing on two streams and whether the
remote end has negotiated it.) It's a little more complicated - the
HAL may have decided to only select one TX chain rather than the 2 or
3 that the device knows about. I'll have to fix that up, but STBC/LDPC
are nice things to have.

I'll also verify that the net80211 and ath driver code support 3
stream TX and RX, at least in STA mode

Yes, yes I know, the AR9380 HAL code isn't yet public. I'm still
working (slowly!) on that. These things take time!




Adrian
_______________________________________________
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to