K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2011-09-16T04:42:05.176474Z
K 7
svn:log
V 1652
Fix the default cabq configuration time to not be "too long".

The -HEAD code would configure a cabq time of 100 TU minus the
various beacon setup intervals. When doing staggered beacons,
this would result in CABQ readytime being 4 * the beacon interval
timer, which is 1/ATH_BCBUF (4) the default beacon interval (100 TU.)

This didn't seem to annoy the AR9160 MAC but it definitely annoys
the AR9220/AR9280 MAC.

I then fixed it to use the beacon time configured through a (hopefully
earlier!) call to the HAL beacon timer setup code. This reduced the
stuck beacon and cabq stall occurances quite a bit, but it didn't
eliminate them.

Having a CABQ time that's almost the same as the beacon interval seems
to annoy AR9280 (Merlin) and later MACs. So, I decided to twiddle
things a bit and make it 70% of the beacon interval. Both linux ath9k
and the Atheros reference code default to 80% of the beacon interval.

This hasn't stopped miss beacons (which could be because the air is
"busy", which it tends to be in my apartment..) or eliminated the
cabq TX issues (which should still be addressed, as there's no way
a few broadcast frames here and there shouldn't make it out
when the air is completely free for TX) but it does seem to have
(initially) eliminated the stuck beacon conditions on my AR9220 NIC.
I'll have to run this for a few hours to see what the story is and
I likely should investigate why cabq traffic can't be TXed, but
I'm happy to report these last few commits have had a positive effect.

TODO: fix this in AR5212 too, just to be correct.
TODO: actually set a non-0 readytime value when setting up the
  CABQ in the ath driver.

END