Commit Graph

1378 Commits

Author SHA1 Message Date
Adrian Chadd
b8f355bf50 Work around some rather unfortunate race conditions inside net80211.
Right now, ic_curchan seems to be updated rather quickly (ie, during
the ioctl) and before the driver gets notified of what's going on.
So what I was seeing was:

* NIC was in channel X;
* It generates PHY errors for channel X;
* an ioctl comes along from userland and changes things to channel Y;
* .. this updates ic_curchan, but hasn't yet reset the hardware;
* in parallel, RX is occuring and it looks at ic_curchan;
* .. which is channel Y, so events get stamped with that now.

Sigh.
2013-01-31 00:14:25 +00:00
Pedro F. Giffuni
646a7fea0c Clean some 'svn:executable' properties in the tree.
Submitted by:	Christoph Mallon
MFC after:	3 days
2013-01-26 22:08:21 +00:00
Adrian Chadd
f28a552089 Migrate the TX sending code out from under the ath0 taskq and into
the separate ath0 TX taskq.

Whilst here, make sure that the TX software scheduler is also
running out of the TX task, rather than the ath0 taskqueue.

Make sure that the tx taskqueue is blocked/unblocked as necessary.

This allows for a little more parallelism on multi-core machines,
as well as (eventually) supporting a higher task priority for TX
tasks, allowing said TX task to preempt an already running RX or
TX completion task.

Tested:

* AR5416, AR9280 hostap and STA modes
2013-01-26 00:14:34 +00:00
Adrian Chadd
f74d878fda Fix this routine to acutally break out and not set clrdmask if any
of the TIDs are currently marked as "filtered."
2013-01-21 07:50:38 +00:00
Adrian Chadd
4f25ddbbe6 Migrate CLRDMASK to be a per-node flag, rather than a per-TID flag.
This is easily possible now that the TX is protected by a single
lock, rather than a per-TXQ (and thus per-TID) lock.

Only set CLRDMASK if none of the destinations are filtered.
This likely will need some tuning when it comes time to do UASPD/PS-POLL
TX, however at that point it should be manually set anyway.

Tested:

* AR9280, STA mode

TODO:

* More thorough testing in AP mode
* test other chipsets, just to be safe/sure.
2013-01-21 04:06:04 +00:00
Adrian Chadd
a74ebfe59e Fix hangs (exposed by spectral scan activity) in STA mode when the
chip hangs.

* Always do a reset in ath_bmiss_proc(), regardless of whether the
  hardware is "hung" or not.  Specifically, for spectral scan, there's
  likely a whole bunch of potential hangs that we don't (yet) recognise
  in the HAL.  So to avoid staying RX deaf persisting until the station
  disassociates, just do a no-loss reset.

* Set sc_beacons=1 in STA mode.  During a reset, the beacon programming
  isn't done.  (It's likely I need to set sc_syncbeacons during a hang
  reset, but I digress.)  Thus after a reset, there's no beacon timer
  programming to send a BMISS interrupt if beacons aren't heard ..
  thus if the AP disappears, you won't get notified and you'll have to
  reset your interface.

This hasn't yet fixed all of the hangs that I've seen when debugging
spectral scan, but it's certainly reduced the hang frequency and it
should improve general STA stability in very noisy environments.

Tested:

* AR9280, STA mode, spectral scan off/on

PR:		kern/175227
2013-01-17 16:43:59 +00:00
Adrian Chadd
61cd9692bb Add a quick work-around if ath_beacon_config() to not die if it's called
when an interface is going down.

Right now it's quite possible (but very unlikely!) that ath_reset()
or similar is called, leading to a beacon config call, in parallel with
the last VAP being destroyed.

This likely should be fixed by making sure the bmiss/bstuck/watchdog
taskqueues are canceled whenever the last VAP is destroyed.
2013-01-17 16:26:40 +00:00
Adrian Chadd
c5239edb98 Implement frame (data) transmission using if_transmit(), rather than
if_start().

This removes the overlapping data path TX from occuring, which
solves quite a number of the potential TX queue races in ath(4).
It doesn't fix the net80211 layer TX queue races and it doesn't
fix the raw TX path yet, but it's an important step towards this.

This hasn't dropped the TX performance in my testing; primarily
because now the TX path can quickly queue frames and continue
along processing.

This involves a few rather deep changes:

* Use the ath_buf as a queue placeholder for now, as we need to be
  able to support queuing a list of mbufs (ie, when transmitting
  fragments) and m_nextpkt can't be used here (because it's what is
  joining the fragments together)

* if_transmit() now simply allocates the ath_buf and queues it to
  a driver TX staging queue.

* TX is now moved into a taskqueue function.

* The TX taskqueue function now dequeues and transmits frames.

* Fragments are handled correctly here - as the current API passes
  the fragment list as one mbuf list (joined with m_nextpkt) through
  to the driver if_transmit().

* For the couple of places where ath_start() may be called (mostly
  from net80211 when starting the VAP up again), just reimplement
  it using the new enqueue and taskqueue methods.

What I don't like (about this work and the TX code in general):

* I'm using the same lock for the staging TX queue management and the
  actual TX.  This isn't required; I'm just being slack.

* I haven't yet moved TX to a separate taskqueue (but the taskqueue is
  created); it's easy enough to do this later if necessary.  I just need
  to make sure it's a higher priority queue, so TX has the same
  behaviour as it used to (where it would preempt existing RX..)

* I need to re-review the TX path a little more and make sure that
  ieee80211_node_*() functions aren't called within the TX lock.
  When queueing, I should just push failed frames into a queue and
  when I'm wrapping up the TX code, unlock the TX lock and
  call ieee80211_node_free() on each.

* It would be nice if I could hold the TX lock for the entire
  TX and TX completion, rather than this release/re-acquire behaviour.
  But that requires that I shuffle around the TX completion code
  to handle actual ath_buf free and net80211 callback/free outside
  of the TX lock.  That's one of my next projects.

* the ic_raw_xmit() path doesn't use this yet - so it still has
  sequencing problems with parallel, overlapping calls to the
  data path.  I'll fix this later.

Tested:

* Hostap - AR9280, AR9220
* STA - AR5212, AR9280, AR5416
2013-01-15 18:01:23 +00:00
Adrian Chadd
233af52df2 If we're doing a kickpcu, make sure we flush the whole RX list rather than
stopping after 128 frames.

Whilst here, add in some code that lets me optionally flip back to the
original behaviour of calling ath_startrecv().
2013-01-13 22:41:58 +00:00
Adrian Chadd
4c2f84b119 Place-holders for enable/active parameter flags. 2013-01-11 02:25:39 +00:00
Adrian Chadd
3aa1b9569d Fix format size. 2013-01-08 22:42:15 +00:00
Adrian Chadd
e1c562d83a Add support for triggering spectral scan upon a channel reset/change.
This is intended to support reporting FFT results during active channel
scans, for users who would like to fiddle around with writing applications
that do both FFT visualisation _and_ AP scanning.

* add a new ioctl to enable/trigger spectral scan at channel change/reset;
* set do_spectral consistently if it's enabled, so a channel set/reset
  will carry forth the correct PHY error configuration so frames
  are actually received;
* for NICs that don't do spectral scan, don't bother checking the
  spectral scan state on channel change/reset.

Tested:

* AR9280 - STA and scanning;
* AR5416 - STA, ensured that the SS code doesn't panic
2013-01-08 22:15:13 +00:00
Adrian Chadd
f29c6bdec5 If spectral scan is enabled, ensure radar report PHY errors are also
enabled.
2013-01-08 22:12:45 +00:00
Adrian Chadd
55caa1df93 For PHY error frames, populate the configured channel flags rather than
based on the received frame.

PHY errors don't have the relevant HT or 40MHz MCS flag set.
2013-01-04 06:28:34 +00:00
Adrian Chadd
5da4cc48ba Don't call the spectral methods for NICS that don't implement them. 2013-01-03 19:03:03 +00:00
Adrian Chadd
9af351f9e8 Add a new (skeleton) spectral mode manager module. 2013-01-02 03:59:02 +00:00
Adrian Chadd
bcd2a42f0b Fix the short repeat option code to not flip the option to 0 when
we call this w/ NOVAL set.
2013-01-02 03:56:20 +00:00
Adrian Chadd
1535a81e5e Add spectral HAL accessor methods. 2013-01-02 01:40:23 +00:00
Adrian Chadd
c9b690d37a Add a method to explicitly disable radar reporting if required. 2013-01-02 01:36:10 +00:00
Adrian Chadd
973d40776c Bring over the basic spectral scan framework code from Qualcomm Atheros.
This includes the HAL routines to setup, enable/activate/disable spectral
scan and configure the relevant registers.

This still requires driver interaction to enable spectral scan reporting.
Specifically:

* call ah_spectralConfigure() to configure and enable spectral scan;
* .. there's currently no way to disable spectral scan... that will have
  to follow.
* call ah_spectralStart() to force start a spectral report;
* call ah_spectralStop() to force stop an active spectral report.

The spectral scan results appear as PHY errors (type 0x5 on the AR9280,
same as radar) but with the spectral scan bit set (0x10 in the last byte
of the frame) identifying it as a spectral report rather than a radar
FFT report.

Caveats:

* It's likely quite difficult to run spectral _and_ radar at the same
  time.  Enabling spectral scan disables the radar thresholds but
  leaves radar enabled.  Thus, the driver (for now) needs to ensure
  that only one or the other is enabled.

* .. it needs testing on HT40 mode.

Tested:

* AR9280 in STA mode, HT/20 only

TODO:

* Test on AR9285, AR9287;
* Test in both HT20 and HT40 modes;
* .. all the driver glue.

Obtained from:	Qualcomm Atheros
2013-01-02 00:38:01 +00:00
Adrian Chadd
29dbc48349 Add the initial HAL glue for the spectral analysis support.
* Finish adding the HAL capability to announce whether a NIC supports
  spectral scan or not;
* Add spectral scan methods to the HAL structure;
* Add HAL_SPECTRAL_PARAM for configuration of the spectral scan logic.

The capability ID and HAL_SPECTRAL_PARAM struct are from Qualcomm
Atheros.
2012-12-30 06:48:12 +00:00
Adrian Chadd
9cbc6f1595 Add spectral scan capability. 2012-12-30 06:46:11 +00:00
Baptiste Daroussin
661c81c3d6 Fix typo in comment.
Submitted by:	Christoph Mallon <christoph.mallon@gmx.de>
2012-12-28 21:59:47 +00:00
Adrian Chadd
2720a0cbd9 Add the AR9280 and later spectral scan register definitions.
Obtained from:	Linux ath9k, Qualcomm Atheros (datasheet)
2012-12-28 08:00:31 +00:00
Adrian Chadd
00ba39c988 Add radar_bin_thresh_sel (bit 24:26), which defines when
to consider the radar FFT report bins as "strong".
2012-12-28 07:49:45 +00:00
Adrian Chadd
a5e67727fb Note why fast frames is disabled for 802.11n NICs now.
It actually works, but net80211 handles A-MPDU and Fast frames
incorrectly; it tries enabling both in some instances, with tragic
results.
2012-12-21 04:28:05 +00:00
Adrian Chadd
fc56c9c5e2 There's no need to use a TXQ pointer here; we specifically need the
hardware queue ID when queuing to EDMA descriptors.

This is a small part of trying to reduce the size of ath_buf entries.
2012-12-11 04:19:51 +00:00
Adrian Chadd
2992cd2231 Add XC900 SKU mapping. 2012-12-07 06:38:30 +00:00
Gleb Smirnoff
c6499eccad Mechanically substitute flags from historic mbuf allocator with
malloc(9) flags in sys/dev.
2012-12-04 09:32:43 +00:00
Adrian Chadd
e89812c379 Methodise the BT diversity configuration function; so the AR9285
can correctly override it.

This was missed in the previous commit.
2012-12-04 00:02:46 +00:00
Adrian Chadd
96b59d60c8 Override the BT coex parameter function for the AR9285. 2012-12-04 00:01:42 +00:00
Adrian Chadd
87a85d8a49 Reformat/reindent. 2012-12-04 00:01:24 +00:00
Adrian Chadd
24a8406b99 Add and tie in the AR5416 bluetooth coexistence methods into the HAL. 2012-12-03 23:45:06 +00:00
Adrian Chadd
974185bb13 Don't grab the PCU lock inside the TX lock. 2012-12-02 06:50:27 +00:00
Adrian Chadd
375307d411 Delete the per-TXQ locks and replace them with a single TX lock.
I couldn't think of a way to maintain the hardware TXQ locks _and_ layer
on top of that per-TXQ software queuing and any other kind of fine-grained
locks (eg per-TID, or per-node locks.)

So for now, to facilitate some further code refactoring and development
as part of the final push to get software queue ps-poll and u-apsd handling
into this driver, just do away with them entirely.

I may eventually bring them back at some point, when it looks slightly more
architectually cleaner to do so.  But as it stands at the present, it's
not really buying us much:

* in order to properly serialise things and not get bitten by scheduling
  and locking interactions with things higher up in the stack, we need to
  wrap the whole TX path in a long held lock.  Otherwise we can end up
  being pre-empted during frame handling, resulting in some out of order
  frame handling between sequence number allocation and encryption handling
  (ie, the seqno and the CCMP IV get out of sequence);

* .. so whilst that's the case, holding the lock for that long means that
  we're acquiring and releasing the TXQ lock _inside_ that context;

* And we also acquire it per-frame during frame completion, but we currently
  can't hold the lock for the duration of the TX completion as we need
  to call net80211 layer things with the locks _unheld_ to avoid LOR.

* .. the other places were grab that lock are reset/flush, which don't happen
  often.

My eventual aim is to change the TX path so all rejected frame transmissions
and all frame completions result in any ieee80211_free_node() calls to occur
outside of the TX lock; then I can cut back on the amount of locking that
goes on here.

There may be some LORs that occur when ieee80211_free_node() is called when
the TX queue path fails; I'll begin to address these in follow-up commits.
2012-12-02 06:24:08 +00:00
Adrian Chadd
e5d63a99bc Add a new HAL capability - check and enforce whether the NIC supports
enforcing the TXOP and TBTT limits:

* Frames which will overlap with TBTT will not TX;
* Frames which will exceed TXOP will be filtered.

This is not enabled by default; it's intended to be enabled by the
TDMA code on 802.11n capable chipsets.
2012-12-01 03:48:11 +00:00
Adrian Chadd
8bf4020830 Call if_free() with the correct vnet context if and only if ifp_vnet
isn't NULL.

If the attach fails prematurely and there's no if_vnet context, calling
CURVNET_SET(ifp->if_vnet) is going to dereference a NULL pointer.
2012-11-28 07:12:08 +00:00
Adrian Chadd
491e124856 Until I figure out what to do here, remind myself that this needs some
rate control 'adjustment' when NOACK is set.
2012-11-28 06:55:34 +00:00
Adrian Chadd
7c783791c8 Pull out the debugging code from the critical path and make sure it
happens _after_ all of the time delta calculations.
2012-11-28 01:55:22 +00:00
Adrian Chadd
821311ea59 * Fix another culprit of my "committed from the wrong directory" nonsense;
now this works for non-debug and debug builds.

* Add a comment reminding me (or someone) to audit all of the relevant
  math to ensure there's no weird wrapping issues still lurking about.

But yes, this does seem to be mostly working.

Pointy-hat-to:	adrian, yet again
2012-11-27 11:30:39 +00:00
Adrian Chadd
4fd97455a3 Correct some debugging output. 2012-11-27 08:40:48 +00:00
Adrian Chadd
584295fca4 Fix build 2012-11-27 05:52:08 +00:00
Adrian Chadd
4bda23f95b Improve the TDMA debugging:
* add some further debugging prints, which are quite nice to have
* add in ALQ hooks (optional!) to allow for the TDMA information to be
  logged in-line with the TX and RX descriptor information.
2012-11-27 02:27:30 +00:00
Adrian Chadd
11f07b7b52 Add in specific TDMA logging types. 2012-11-27 02:24:05 +00:00
Adrian Chadd
e6f1a34af4 Fix the TDMA nexttbtt programming for 802.11n chips.
The existing logic wrapped programming nexttbtt at 65535 TU.
This is not good enough for the 11n chips, whose nexttbtt register
(GENERIC_TIMER_0) has an initial value from 0..2^31-1 TSF.
So converting the TU to TSF had the counter wrap at (65535 << 10) TSF.

Once this wrap occured, the nexttbtt value was very very low, much
lower than the current TSF value.  At this point, the nexttbtt timer
would constantly fire, leading to the TX queue being constantly gated
open.. and when this occured, the sender was not correctly transmitting
in its slot but just able to continuously transmit.  The master would
then delay transmitting its beacon until after the air became free
(which I guess would be after the burst interval, before the next burst
interval would quickly follow) and that big delta in master beacon TX
would start causing big swings in the slot timing adjustment.

With this change, the nexttbtt value is allowed to go all the way up
to the maximum value permissable by the 32 bit representation.
I haven't yet tested it to that point; I really should.  The AR5212
HAL now filters out values above 65535 TU for the beacon configuration
(and the relevant legal values for SWBA, DBA and NEXTATIM) and the
AR5416 HAL just dutifully programs in what it should.

With this, TDMA is now useful on the 802.11n chips.

Tested:

* AR5416, AR9280 TDMA slave
* AR5413 TDMA slave
2012-11-27 02:23:45 +00:00
Adrian Chadd
a52b6c396b Add a note about the magic values here; don't change them. 2012-11-27 02:19:35 +00:00
Adrian Chadd
2cb6e9834f When programming the beacon timer configuration, be very explicit about
what the maximum legal values are.

The current beacon timer configuration from TDMA wraps things at
HAL_BEACON_PERIOD-1 TU.  For the 11a chips this is fine, but for
the 11n chips it's not enough resolution.  Since the 11a chips have a
limit on what's "valid", just enforce this so when I do write larger
values in, they get suitably wrapped before programming.

Tested:

* AR5413, TDMA slave

Todo:

* Run it for a (lot) longer on a clear channel, ensure that no strange
  slippages occur.
* Re-validate this on STA configurations, just to be sure.
2012-11-27 02:18:41 +00:00
Adrian Chadd
6dd853a77a Add a comment which covers what's going on with the 64 bit TSF write.
After chatting with the MAC team, the TSF writes (at least on the 11n
MACs, I don't know about pre-11n MACs) are done as 64 bit writes that
can take some time.  So, doing a 32 bit TSF write is definitely not
supported.  Leave a comment here which explains that.

Whilst here, add a comment which outlines that after a reset or TSF
write, the TSF write may take a while (up to 50uS) to update.
A write or reset shouldn't be done whilst the previous one is in
flight.  Also (and this isn't currently done) a read shouldn't
occur until the SLEEP32_TSF_WRITE_STAT is clear.  Right now we're
not doing that, mostly because we haven't been doing lots of TSF
resets/writes until recently.
2012-11-24 02:41:18 +00:00
Adrian Chadd
84dd5933b5 Use a 64 bit TSF write to update the TSF adjust, rather than a 32 bit
TSF write.

The TSF_L32 update is fine for the AR5413 (and later, I guess) 11abg NICs
however on the 11n NICs this didn't work.  The TSF writes were causing
a much larger time to be skipped, leading to the timing to never
converge.

I've tested this 64 bit TSF read, adjust and write on both the
11n NICs and the AR5413 NIC I've been using for testing.  It works
fine on each.

This patch allows the AR5416/AR9280 to be used as a TDMA member.
I don't yet know why the AR9280 is ~7uS accurate rather than ~3uS;
I'll look into it soon.

Tested:

* AR5413, TDMA slave (~ 3us accuracy)
* AR5416, TDMA slave (~ 3us accuracy)
* AR9280, TDMA slave (~ 7us accuracy)
2012-11-23 05:52:22 +00:00
Adrian Chadd
ddee921170 Fix up the nexttbtt -> TSF delta calculation to not wrap ridiculously
on the 802.11n NICs.

The 802.11n NICs return a TBTT value that continues far past the 16 bit
HAL_BEACON_PERIOD time (in TU.)  The code would constrain nextslot to
HAL_BEACON_PERIOD, but it wasn't constraining nexttbtt - the pre-11n
NICs would only return TU values from 0 -> HAL_BEACON_PERIOD.  Thus,
when nexttbtt exceeded 64 milliseconds, it would not wrap (but nextslot
did) which lead to a huge tsfdelta.

So until the slot calculation is converted to work in TSF rather than
a mix of TSF and TU, "make" the nexttbtt values match the TU assumptions
for pre-11n NICs.

This fixes the crazy deltatsf calculations but it doesn't fix the
non-convergent tsfdelta issue.  That'll be fixed in a subsequent commit.
2012-11-23 05:38:38 +00:00