Commit Graph

1755 Commits

Author SHA1 Message Date
Adrian Chadd
706bb44485 Make sure bf_next is NULL'ed out when we're completing up an aggregate
frame through the cleanup path.

Whilst here, fix the indenting for something I messed up.

Tested:

* AR5416, STA mode
2014-04-21 02:05:51 +00:00
Adrian Chadd
59fbb5304d Fix a cleanup hang if cleanup gets called _during_ an active cleanup.
During power save testing I noticed that the cleanup code is being
called during a RUN->RUN state transition.  It's because the net80211
stack is treating that (for reasons I don't quitey know yet) as a
reassociation and this calls the node cleanup code.  The reason it's
seeing a RUN->RUN transition is because during active power save
stuff it's possible that the RUN->SLEEP and SLEEP->RUN transitions
happen so quickly that the deferred net80211 vap state code
"loses" a transition, namely the intermediary SLEEP transition.

So, this was causing the node reassociation code to sometimes be called
twice in quick succession and this would result in ath_tx_tid_cleanup()
to be called again.  The code calling it would always call pause, and
then only call resume if the TID didn't have "cleanup_inprogress" set.
Unfortunately it didn't check if it was already set on entry, so it
would pause but not call resume.  Thus, paused would be called more
than once (once before each entry into ath-tx_tid_cleanup()) but resume
would only be called once when the cleanup state was finished.

This doesn't entirely fix all of the issues seen in the cleanup path
but it's a necessary first step.

Since this is a stability fix, it should be merged to stable/10 at some
point.

Tested:

* AR5416, STA mode

MFC after:	7 days
2014-04-21 01:02:49 +00:00
Adrian Chadd
6ed22fae0a Add a function to check whether the given register can be accessed whilst
the chip is asleep.

It's AR5416 and later specific; I'll add a HAL method to generalise it
later.

Tested:

* AR5416, STA mode
2014-04-09 03:51:05 +00:00
Adrian Chadd
42fdd8e726 Add some debugging and forcing of the BAW to match what the current
tracked BAW actually is.

The net80211 code that completes a BAR will set tid->txa_start (the
BAW start) to whatever value was called when sending the BAR.
Now, in case there's bugs in my driver code that cause the BAW
to slip along, we should make sure that the new BAW we start
at is actually what we currently have it at, not what we've sent.

This totally breaks the specification and so this stays a printf().
If it happens then I need to know and fix it.

Whilst here, add some debugging updates:

* add TID logging to places where it's useful;
* use SEQNO().
2014-04-08 07:14:14 +00:00
Adrian Chadd
8ec9220e81 Don't do continue inside the scheduler loop; we really need to check
if we've hit the end of the list and cycled around to the first
node again.

Obtained from:	DragonflyBSD
2014-04-08 07:10:52 +00:00
Adrian Chadd
1f7373066f Correct the actual definition of ath_tx_tid_filt_comp_single() to
match how it's used.

This is another bug that led to aggregate traffic hanging because
the BAW tracking stopped being accurate.  In this instance, a filtered
frame that exceeded retries would return a non-error, which would
mean the caller would never remove it from the BAW.  But it wouldn't
be added to the filtered list, so it would be lost forever.  There'd
thus be a hole in the BAW that would never get transmitted and
this leads to a traffic hang.

Tested:

* Routerstation Pro, AR9220 AP
2014-04-08 07:08:59 +00:00
Adrian Chadd
c5d230ab42 Add a comment explaining the obvious. 2014-04-08 07:01:27 +00:00
Adrian Chadd
a3fd3b1429 Don't resume a TID on each filtered frame completion - only do it if
we did suspend it.

The whole suspend/resume TID queue thing is supposed to be a matched
reference count - a subsystem (eg addba negotiation, BAR transmission,
filtered frames, etc) is supposed to call pause() once and then resume()
once.

ath_tx_tid_filt_comp_complete() is called upon the completion of any
filtered frame, regardless of whether the driver had aleady seen
a filtered frame and called pause().

So only call resume() if tid->isfiltered = 1, which indicates that
we had called pause() once.

This fixes a seemingly whacked and different problem - traffic hangs.

What was actually going on:

* There'd be some marginal link with crappy behaviour, causing filtered
  frames and BAR TXing to occur;
* A BAR TX would occur, setting the new BAW (block-ack window) to seqno n;
* .. and pause() would be called, blocking further transmission;
* A filtered frame completion would occur from the hardware, but with
  tid->isfiltered = 0 which indiciates we haven't actually marked
  the queue yet as filtered;
* ath_tx_tid_filt_comp_complete() would call resume(), continuing
  transmission;
* Some frames would be queued to the hardware, since the TID is now no
  longer paused;
* .. and if some make it out and ACked successfully, the new BAW
  may be seqno n+1 or more;
* .. then the BAR TX completes and sets the new seqno back to n.

At this point the BAW tracking would be loopy because the BAW
start was modified but the BAW ring buffer wasn't updated in lock
step.

Tested:

* Routerstation Pro + AR9220 AP
2014-04-08 07:00:43 +00:00
Adrian Chadd
f857fb4fa3 Also set the AR5212 HAL power mode tracking in the right spot.
Tested:

* D-Link DWL-G650 NIC (AR2413), STA mode
2014-03-22 03:36:07 +00:00
Adrian Chadd
6fc621c22c Throw the flush messages behind ATH_DEBUG_RESET as well.
These are needed to diagnose TX hangs that I and hiren are seeing.
Without it, the only way we'll see debugging is by having ATH_DEBUG_SW_TX
enabled and that is going to be very, very spammy.

ATH_DEBUG_RESET is fine; it's only going to be done during stuck beacon
situations in AP mode.

Whilst I'm here, and now that it's behind debugging, let's just disable
the "print only one" conditional.  I'll eventually make it more tunable.

Tested:

* AR9220, hostap mode.
2014-03-20 23:16:58 +00:00
Adrian Chadd
517dfcb126 Add some debugging code to print out if registers are touched whilst the
device is asleep.

This doesn't avoid logging errors for things that are actually OK to
access whilst the chip is asleep (eg, the RTC registers (0x7000->0x70ff
on the AR5416 and later.)

But, this is a pretty good indicator if things are accessed incorrectly.

Tested:

* AR5416, STA
2014-03-20 05:10:17 +00:00
Adrian Chadd
bd369abaac Shuffle ah_powerMode to be in a sane spot for the given power operation.
This way the state changes from sleep->awake before the registers are poked
and from awake->sleep after the registers are poked.

This way spurious warnings aren't printed by my (to be committed)
debugging code.

Tested:

* AR5416, STA
2014-03-20 05:08:31 +00:00
Adrian Chadd
410302eb58 Don't call ath_init() inside the lock.
Yes, this means that sc_invalid is slightly racy, but there are other
issues here which need fixing.

This fixes a source of eventual LORs - ath_init() grabs ATH_LOCK to do
work and releases it before it calls ieee80211_start_all().
ieee80211_start_all() will grab the net80211 comlock to iterate over
the VAPs.

TODO:

* .. I should just migrate the ieee80211_start_all() work to a
  deferred task so it can be done later; it doesn't have to be
  immediately done.

Tested:

* AR5416, STA mode
2014-03-20 04:47:34 +00:00
Adrian Chadd
8a67b42a74 Migrate the chip power mode status to public ath_hal, rather than the
private per-chip HAL.

This allows the ah_osdep.[ch] code to check whether the power state is
valid for doing chip programming.

It should be a no-op for normal driver work but it does require a
clean kernel/module rebuild, as the size of HAL structures have changed.

Now, this doesn't track whether the hardware is ACTUALLY awake,
as NETWORK_SLEEP wakes the chip up for a short period when traffic
is received.  This doesn't actually set the power mode to AWAKE, so
we have to be careful about how we touch things.

But it's enough to start down the path of implementing station mode
chipset power savings, as a large part of the silliness is making
sure the chip is awake during periodic calibration / ANI and
random places where transmit may be occuring.  I'd rather not a repeat
of debugging power save on ath9k, where races with calibration
and transmit path stuff took a couple years to shake out.

Tested:

* AR5416, STA mode
2014-03-10 06:03:35 +00:00
Rui Paulo
a2be2710b4 Call ieee80211_dump_pkt() based on IFF_DUMPPKTS().
MFC after:	3 days
2014-03-08 19:35:31 +00:00
Hiren Panchasara
92389b2759 PicoStation M2HP presents reg domain 0x2a which is not found in atheros or linux
reference code. Add this workaround for now.

Reviewed by:	adrian
2014-02-23 18:07:17 +00:00
Kevin Lo
5945b5f5ab Rename definition of IEEE80211_FC1_WEP to IEEE80211_FC1_PROTECTED.
The origin of WEP comes from IEEE Std 802.11-1997 where it defines
whether the frame body of MAC frame has been encrypted using WEP
algorithm or not.
IEEE Std. 802.11-2007 changes WEP to Protected Frame, indicates
whether the frame is protected by a cryptographic encapsulation
algorithm.

Reviewed by:	adrian, rpaulo
2014-01-08 08:06:56 +00:00
Adrian Chadd
2aeb1b35eb Correctly remove entries from the relevant receive ath_buf list before
freeing them.

The current code would walk the list and call the buffer free, which
didn't remove it from any lists before pushing it back on the free list.

Tested:		AR9485, STA mode

Noticed by:	dillon@apollo.dragonflybsd.org
2014-01-06 03:48:32 +00:00
Gleb Smirnoff
104dc21415 - Provide necessary includes, that before came via if.h pollution.
- Remove unnecessary ones.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2013-10-28 22:26:03 +00:00
Olivier Houchard
f431664c05 Include <sys/ktr.h>, since we need it if ATH_DEBUG is defined. 2013-10-28 20:26:34 +00:00
Gleb Smirnoff
c3322cb91c Include necessary headers that now are available due to pollution
via if_var.h.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2013-10-28 07:29:16 +00:00
Gleb Smirnoff
76039bc84f The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare
to this event, adding if_var.h to files that do need it. Also, include
all includes that now are included due to implicit pollution via if_var.h

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2013-10-26 17:58:36 +00:00
Rui Paulo
b372f122ab Add a missing comma. 2013-10-17 05:51:54 +00:00
Rui Paulo
83bbd5ebf9 Move a lot of debugging printf's to DPRINTF.
Approved by:	adrian
MFC after:	2 weeks
2013-10-17 01:53:07 +00:00
Adrian Chadd
0a2cefc676 Add channel survey support to the AR5212 HAL.
The AR5212 series of MACs implement the same channel counters as the
later 11n chips - except, of course, the 11n specific counter (extension
channel busy.)

This allows users of these NICs to use 'athsurvey' to see how busy their
current channel is.

Tested:

* AR5212, AR2413 NICs, STA mode

Approved by:	re@ (gleb)
2013-10-08 11:28:59 +00:00
Adrian Chadd
e95f34242c Use the new ieee80211_tx_complete() function. 2013-08-27 14:39:37 +00:00
Adrian Chadd
272a8ab68a Log the MAC address of the node in question rather than the pointer. 2013-08-17 01:14:28 +00:00
Adrian Chadd
2524554832 Don't log anything if npkts == 0.
This occurs at RX DMA start, even though the RX FIFO has plenty of
space. I'll go figure out why, but this shouldn't cause people to
be spammed by these messages.
2013-06-29 19:57:57 +00:00
Adrian Chadd
30be7dd9c9 Extend the AHB code to work on chips besides the AR9130.
The AHB code:

* hard coded the AR9130 device id;
* assumes a 4k flash calibration space.

This code now extends this:

* hint.ath.X.eepromsize now overrides the eeprom range, instead of 4k
* hint.ath.X.device_id and hint.ath.X.vendor_id can now be overridden.

Tested:

* AR9330 board (Carambola 2)
2013-06-26 04:58:25 +00:00
Adrian Chadd
03f2665670 Add a HAL local routine to map the 2GHz channel frequency to an IEEE
channel.

There's some HAL code in the AR9300 HAL that requires a back-mapping
and using the net80211 code isn't appropriate here.
2013-06-26 04:46:03 +00:00
Adrian Chadd
8d6235fb66 Add in an initial WB225 (AR9485 + AR3012 BT) combo profile.
This hasn't yet been tested as unfortunately the AR3012 I have doesn't
have the "real" firmware on it; it shipped with the cut down HCI firmware
that only understands enough to accept a new firmware image.

* Linux ath9k (GPIO constants)
2013-06-14 08:18:17 +00:00
Adrian Chadd
0f0eebe793 Initial AR9485/AR933x 1x1 LNA diversity work.
* Add the LNA configuration table entries for AR933x/AR9485
* Add a chip-dependent LNA signal level delta in the startup path
* Add a TODO list for the stuff I haven't yet ported over but
  I haven't.

Tested:

* AR9462 with LNA diversity enabled
2013-06-14 03:42:10 +00:00
Adrian Chadd
de98311f50 Set the antenna "config group" field.
The reference HAL pushes a config group parameter to the driver layer
to inform it which particular chip behaviour to implement.

This particular value tags it as an AR9285.
2013-06-12 15:18:10 +00:00
Adrian Chadd
216ca2346f Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver.
The AR9485 chip and AR933x SoC both implement LNA diversity.
There are a few extra things that need to happen before this can be
flipped on for those chips (mostly to do with setting up the different
bias values and LNA1/LNA2 RSSI differences) but the first stage is
putting this code into the driver layer so it can be reused.

This has the added benefit of making it easier to expose configuration
options and diagnostic information via the ioctl API.  That's not yet
being done but it sure would be nice to do so.

Tested:

* AR9285, with LNA diversity enabled
* AR9285, with LNA diversity disabled in EEPROM
2013-06-12 14:52:57 +00:00
Adrian Chadd
9ae49f268a Remove the AR9285 specific structure for LNA diversity and use the HAL.
The AR9300 HAL update included the LNA diversity configuration information
so it can be used in the AR9485 configuration code.
2013-06-12 06:01:53 +00:00
Adrian Chadd
b674594527 Add another comment about WB195 (AR9285+AR3011) when using ASPM. 2013-06-10 20:10:34 +00:00
Adrian Chadd
b70f530bc7 Bring over the initial static bluetooth coexistence configuration
for the WB195 combo NIC - an AR9285 w/ an AR3011 USB bluetooth NIC.

The AR3011 is wired up using a 3-wire coexistence scheme to the AR9285.

The code in if_ath_btcoex.c sets up the initial hardware mapping
and coexistence configuration.  There's nothing special about it -
it's static; it doesn't try to configure bluetooth / MAC traffic priorities
or try to figure out what's actually going on.  It's enough to stop basic
bluetooth traffic from causing traffic stalls and diassociation from
the wireless network.

To use this code, you must have the above NIC.  No, it won't work
for the AR9287+AR3012, nor the AR9485, AR9462 or AR955x combo cards.

Then you set a kernel hint before boot or before kldload, where 'X'
is the unit number of your AR9285 NIC:

# kenv hint.ath.X.btcoex_profile=wb195

This will then appear in your boot messages:

[100482] athX: Enabling WB195 BTCOEX

This code is going to evolve pretty quickly (well, depending upon my
spare time) so don't assume the btcoex API is going to stay stable.

In order to use the bluetooth side, you must also load in firmware using
ath3kfw and the binary firmware file (ath3k-1.fw in my case.)

Tested:

* AR9280, no interference
* WB195 - AR9285 + AR3011 combo; STA mode; basic bluetooth inquiries
  were enough to cause traffic stalls and disassociations.  This has
  stopped with the btcoex profile code.

TODO:

* Importantly - the AR9285 needs ASPM disabled if bluetooth coexistence
  is enabled.  No, I don't know why.  It's likely some kind of bug to do
  with the AR3011 sending bluetooth coexistence signals whilst the device
  is asleep.  Since we don't actually sleep the MAC just yet, it shouldn't
  be a problem.  That said, to be totally correct:

  + ASPM should be disabled - upon attach and wakeup
  + The PCIe powersave HAL code should never be called

  Look at what the ath9k driver does for inspiration.

* Add WB197 (AR9287+AR3012) support
* Add support for the AR9485, which is another combo like the AR9285
* The later NICs have a different signaling mechanism between the MAC
  and the bluetooth device; I haven't even begun to experiment with
  making that HAL code work.  But it should be a lot more automatic.

* The hardware can do much more interesting traffic weighting with
  bluetooth and wifi traffic.  None of this is currently used.
  Ideally someone would code up something to watch the bluetooth traffic
  GPIO (via an interrupt) and then watch it go high/low; then figure out
  what the bluetooth traffic is and adjust things appropriately.

* If I get the time I may add in some code to at least track this stuff
  and expose statistics.  But it's up to someone else to experiment with
  the bluetooth coexistence support and add the interesting stuff (like
  "real" detection of bulk, audio, etc bluetooth traffic patterns and
  change wifi parameters appropriately - eg, maximum aggregate length,
  transmit power, using quiet time to control TX duty cycle, etc.)
2013-06-07 09:02:02 +00:00
Adrian Chadd
3a0705aef9 Add accessor macros for the bluetooth coexistence routines. 2013-06-07 05:18:07 +00:00
Adrian Chadd
0c20aadbd9 Add bluetooth fixes to the AR5416/AR92xx HAL:
* Call the bluetooth setup function during the reset path, so the bluetooth
  settings are actually initialised.
* Call the AR9285 diversity functions during bluetooth setup; so the AR9285
  diversity and antenna configuration registers are correctly programmed
* Misc debugging info.

Tested:

* AR9285+AR3011 bluetooth combo; this code itself doesn't enable bluetooth
  coexistence but it's part of what I'm currently using.
2013-06-07 05:17:58 +00:00
Adrian Chadd
5eb07ec729 Enable slow diversity combining for the AR9285.
Now that I understand what's going on - and the RX antenna array maps
to what the receive LNA configuration actually is - I feel comfortable
in enabling this.

If people do have issues with this, there's enough debugging now available
that we have a chance to diagnose it without writing it up as 'weird
crap.'

Tested:

* AR9285 STA w/ diversity combining enabled in EEPROM

TODO:

* (More) testing in hostap mode
2013-06-05 22:23:13 +00:00
Adrian Chadd
094c5f8cb0 As a temporary work-around (read: until there's a nice API for exposing
and controlling this form of antenna diversity) - print out the AR9285
antenna diversity configuration at attach time.

This will help track down and diagose if/when people have connectivity
issues on cards (eg if they connect a single antenna to LNA1, yet the
card has RX configured to only occur on LNA2.)

Tested:

* AR9285 w/ antenna diversity enabled in EEPROM;
* AR9285 w/ antenna diversity disabled in EEPROM; mapping only to a
  single antenna (LNA1.)
2013-06-05 22:21:13 +00:00
Adrian Chadd
3df7a8ab08 Implement a bit of a hack to store the AR9285/AR9485 RX LNA configuration in
the RX antenna field.

The AR9285/AR9485 use an LNA mixer to determine how to combine the signals
from the two antennas.  This is encoded in the RSSI fields (ctl/ext) for
chain 2.  So, let's use that here.

This maps RX antennas 0->3 to the RX mixer configuration used to
receive a frame.  There's more that can be done but this is good enough
to diagnose if the hardware is doing "odd" things like trying to
receive frames on LNA2 (ie, antenna 2 or "alt" antenna) when there's
only one antenna connected.

Tested:

* AR9285, STA mode
2013-06-05 00:45:19 +00:00
Adrian Chadd
d98a3d6936 Add a new capability flag to announce that the chip implements LNA mixing
for the RX path.

This is different to the div comb HAL flag, that says it actually
can use this for RX diversity (the "slow" diversity path implemented
but disabled in the AR9285 HAL code.)

Tested:

* AR9285, STA operation
2013-06-05 00:42:04 +00:00
Adrian Chadd
bd77565e39 Document the AR9285/AR9485 LNA configuration information that's
stored in the ctl/ext RSSI field for chain 2.

Tested:

* AR9285, STA
2013-06-05 00:39:20 +00:00
Adrian Chadd
bc1af55754 Add the combined (mixed) diversity support capability bit for the
AR9285/AR9485.
2013-06-04 02:56:56 +00:00
Adrian Chadd
904e385eba Fix the order of TX shutdown and reset.
* Grab the reset lock first, so any subsequent interrupt, TX, RX work
  will fail

* Then shut down interrupts

* Then wait for TX/RX to finish running

At this point no further work will be running, so it's safe to do the
reset path code.

PR:		kern/179232
2013-06-03 19:39:37 +00:00
Adrian Chadd
cc7b47dd1b Fix receive on the AR9285 (Kite) with only one antenna connected.
The main problem here is that fast and driver RX diversity isn't actually
configured; I need to figure out why that is.  That said, this makes
the single-antenna connected AR9285 and AR2427 (AR9285 w/ no 11n) work
correctly.

PR:		kern/179269
2013-06-03 19:14:29 +00:00
Adrian Chadd
32da86a0f1 Turn the reassociate debug print into a DPRINTF. 2013-05-29 05:10:11 +00:00
Adrian Chadd
5da3fc1048 Shuffle around the cleanup unpause calls a bit. 2013-05-29 01:40:13 +00:00
Adrian Chadd
cd7dffd058 Migrate ath(4) to now use if_transmit instead of the legacy if_start
and if queue mechanism; also fix up (non-11n) TX fragment handling.

This may result in a bit of a performance drop for now but I plan on
debugging and resolving this at a later stage.

Whilst here, fix the transmit path so fragment transmission works.

The TX fragmentation handling is a bit more special.  In order to
correctly transmit TX fragments, there's a bunch of corner cases that
need to be handled:

* They must be transmitted back to back, in the same order..
* .. ie, you need to hold the TX lock whilst transmitting this
  set of fragments rather than interleaving it with other MSDUs
  destined to other nodes;
* The length of the next fragment is required when transmitting, in
  order to correctly set the NAV field in the current frame to the
  length of the next frame; which requires ..
* .. that we know the transmit duration of the next frame, which ..
* .. requires us to set the rate of all fragments to the same length,
  or make the decision up-front, etc.

To facilitate this, I've added a new ath_buf field to describe the
length of the next fragment.  This avoids having to keep the mbuf
chain together.  This used to work before my 11n TX path work because
the ath_tx_start() routine would be handed a single mbuf with m_nextpkt
pointing to the next frame, and that would be maintained all the way
up to when the duration calculation was done.  This doesn't hold
true any longer - the actual queuing may occur at any point in the
future (think ath_node TID software queuing) so this information
needs to be maintained.

Right now this does work for non-11n frames but it doesn't at all
enforce the same rate control decision for all frames in the fragment.
I plan on fixing this in a followup commit.

RTS/CTS has the same issue, I'll look at fixing this in a subsequent
commit.

Finaly, 11n fragment support requires the driver to have fully
decided what the rate scenario setup is - including 20/40MHz,
short/long GI, STBC, LDPC, number of streams, etc.  Right now that
decision is (currently) made _after_ the NAV field value is updated.
I'll fix all of this in subsequent commits.

Tested:

* AR5416, STA, transmitting 11abg fragments
* AR5416, STA, 11n fragments work but the NAV field is incorrect for
  the reasons above.

TODO:

* It would be nice to be able to queue mbufs per-node and per-TID so
  we can only queue ath_buf entries when it's time to assemble frames
  to send to the hardware.

  But honestly, we should just do that level of software queue management
  in net80211 rather than ath(4), so I'm going to leave this alone for now.

* More thorough AP, mesh and adhoc testing.

* Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has
  been negotiated, as we can't do software retransmission of fragments.

* .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
Adrian Chadd
72910f03e5 Implement a separate hardware queue threshold for aggregate and non-aggr
traffic.

When transmitting non-aggregate traffic, we need to keep the hardware
busy whilst transmitting or small bursts in txdone/tx latency will
kill us.

This restores non-aggregate iperf performance, especially when doing
TDMA.

Tested:

* AR5416<->AR5416, TDMA
* AR5416 STA <-> AR9280 AP
2013-05-21 18:13:57 +00:00
Adrian Chadd
dd6a574e09 Enable the use of TDMA on an 802.11n channel (with aggregation disabled,
of course.)

There's a few things that needed to happen:

* In case someone decides to set the beacon transmission rate to be
  at an MCS rate, use the MCS-aware version of the duration calculation
  to figure out how long the received beacon frame was.

* If TxOP enforcing is available on the hardware and we're doing TDMA,
  enable it after a reset and set the TDMA guard interval to zero.
  This seems to behave fine.

TODO:

* Although I haven't yet seen packet loss, the PHY errors that would be
  triggered (specifically Transmit-Override-Receive) aren't enabled
  by the 11n HAL.  I'll have to do some work to enable these PHY errors
  for debugging.

What broke:

* My recent changes to the TX queue handling has resulted in the driver
  not keeping the hardware queue properly filled when doing non-aggregate
  traffic.  I have a patch to commit soon which fixes this situation
  (albeit by reminding me about how my ath driver locking isn't working
  out, sigh.)

  So if you want to test this without updating to the next set of patches
  that I commit, just bump the sysctl dev.ath.X.hwq_limit from 2 to 32.

Tested:

* AR5416 <-> AR5416, with ampdu disabled, HT40, 5GHz, MCS12+Short-GI.
  I saw 30mbit/sec in both directions using a bidirectional UDP test.
2013-05-21 18:02:54 +00:00
Adrian Chadd
6ea069190d Fix build break - the SetCapability calls return HAL_BOOL,
not HAL_STATUS.
2013-05-21 14:28:05 +00:00
Adrian Chadd
38aa9f3688 Extend the TXOP enforce capability to support checking whether it's
supported.
2013-05-21 05:51:49 +00:00
Adrian Chadd
5b66d8a5ad Make the HT rate duration calculation work for MCS rates > 15. 2013-05-20 07:10:43 +00:00
Adrian Chadd
6112d22c3f More non-ATH_DEBUG build fixes. 2013-05-19 01:33:17 +00:00
Adrian Chadd
bd0edcac7c Since we're now using the ah pointer, always declare it.
This fixes non-DEBUG builds.
2013-05-19 00:53:06 +00:00
Adrian Chadd
9be82a4209 Be (very) careful about how to add more TX DMA work.
The list-based DMA engine has the following behaviour:

* When the DMA engine is in the init state, you can write the first
  descriptor address to the QCU TxDP register and it will work.

* Then when it hits the end of the list (ie, it either hits a NULL
  link pointer, OR it hits a descriptor with VEOL set) the QCU
  stops, and the TxDP points to the last descriptor that was transmitted.

* Then when you want to transmit a new frame, you can then either:
  + write the head of the new list into TxDP, or
  + you write the head of the new list into the link pointer of the
    last completed descriptor (ie, where TxDP points), then kick
    TxE to restart transmission on that QCU>

* The hardware then will re-read the descriptor to pick up the link
  pointer and then jump to that.

Now, the quirks:

* If you write a TxDP when there's been no previous TxDP (ie, it's 0),
  it works.

* If you write a TxDP in any other instance, the TxDP write may actually
  fail.  Thus, when you start transmission, it will re-read the last
  transmitted descriptor to get the link pointer, NOT just start a new
  transmission.

So the correct thing to do here is:

* ALWAYS use the holding descriptor (ie, the last transmitted descriptor
  that we've kept safe) and use the link pointer in _THAT_ to transmit
  the next frame.

* NEVER write to the TxDP after you've done the initial write.

* .. also, don't do this whilst you're also resetting the NIC.

With this in mind, the following patch does basically the above.

* Since this encapsulates Sam's issues with the QCU behaviour w/ TDMA,
  kill the TDMA special case and replace it with the above.

* Add a new TXQ flag - PUTRUNNING - which indicates that we've started
  DMA.

* Clear that flag when DMA has been shutdown.

* Ensure that we're not restarting DMA with PUTRUNNING enabled.

* Fix the link pointer logic during TXQ drain - we should always ensure
  the link pointer does point to something if there's a list of frames.
  Having it be NULL as an indication that DMA has finished or during
  a reset causes trouble.

Now, given all of this, i want to nuke axq_link from orbit.  There's now HAL
methods to get and set the link pointer of a descriptor, so what we
should do instead is to update the right link pointer.

* If there's a holding descriptor and an empty TXQ list, set the
  link pointer of said holding descriptor to the new frame.

* If there's a non-empty TXQ list, set the link pointer of the
  last descriptor in the list to the new frame.

* Nuke axq_link from orbit.

Note:

* The AR9380 doesn't need this.  FIFO TX writes are atomic.  As long as
  we don't append to a list of frames that we've already passed to the
  hardware, all of the above doesn't apply.  The holding descriptor stuff
  is still needed to ensure the hardware can re-read a completed
  descriptor to move onto the next one, but we restart DMA by pushing in
  a new FIFO entry into the TX QCU.  That doesn't require any real
  gymnastics.

Tested:

* AR5210, AR5211, AR5212, AR5416, AR9380 - STA mode.
2013-05-18 18:27:53 +00:00
Adrian Chadd
f2f6761490 Re-add some code to exclude transmitting if we're in reset.
This fixes some "transmitting during reset" bugs that crept in after
I messed around with this part of the transmit path.
2013-05-18 13:58:07 +00:00
Adrian Chadd
97c9a8e806 Add some more debugging printf()s to complain if the ath_buf tx queue
doesn't match the actual hardware queue this frame is queued to.

I'm trying to ensure that the holding buffers are actually being queued
to the same TX queue as the holding buffer that they end up on.
I'm pretty sure this is all correct so if this complains, it'll be due
to some kind of subtle broken-ness that needs fixing.

This is only done for legacy hardware, not EDMA hardware.

Tested:

* AR5416 STA mode, very lightly
2013-05-17 05:16:30 +00:00
Adrian Chadd
6d07d3e014 Tidy up the debugging - don't bother printing out TID pointers; now
that we are printing out the MAC address in these fields, just printing
out the TID is enough.
2013-05-16 17:53:12 +00:00
Adrian Chadd
b45a991e92 Limit the number of software queued frames when doing non-aggregation.
This should prevent the TX queue being filled with non-aggregate frames,
causing starvation and non-fair queue behaviour.
2013-05-16 17:46:32 +00:00
Adrian Chadd
dfaf8de927 Dump out the holding buffer descriptor contents and addresses stopping DMA. 2013-05-16 17:45:01 +00:00
Adrian Chadd
22a3aee637 Implement my first cut at "correct" node power-save and
PS-POLL support.

This implements PS-POLL awareness i nthe

* Implement frame "leaking", which allows for a software queue
  to be scheduled even though it's asleep
* Track whether a frame has been leaked or not
* Leak out a single non-AMPDU frame when transmitting aggregates
* Queue BAR frames if the node is asleep
* Direct-dispatch the rest of control and management frames.
  This allows for things like re-association to occur (which involves
  sending probe req/resp as well as assoc request/response) when
  the node is asleep and then tries reassociating.
* Limit how many frames can set in the software node queue whilst
  the node is asleep.  net80211 is already buffering frames for us
  so this is mostly just paranoia.
* Add a PS-POLL method which leaks out a frame if there's something
  in the software queue, else it calls net80211's ps-poll routine.
  Since the ath PS-POLL routine marks the node as having a single frame
  to leak, either a software queued frame would leak, OR the next queued
  frame would leak. The next queued frame could be something from the
  net80211 power save queue, OR it could be a NULL frame from net80211.

TODO:

* Don't transmit further BAR frames (eg via a timeout) if the node is
  currently asleep.  Otherwise we may end up exhausting management frames
  due to the lots of queued BAR frames.

  I may just undo this bit later on and direct-dispatch BAR frames
  even if the node is asleep.

* It would be nice to burst out a single A-MPDU frame if both ends
  support this.  I may end adding a FreeBSD IE soon to negotiate
  this power save behaviour.

* I should make STAs timeout of power save mode if they've been in power
  save for more than a handful of seconds.  This way cards that get
  "stuck" in power save mode don't stay there for the "inactivity" timeout
  in net80211.

* Move the queue depth check into the driver layer (ath_start / ath_transmit)
  rather than doing it in the TX path.

* There could be some naughty corner cases with ps-poll leaking.
  Specifically, if net80211 generates a NULL data frame whilst another
  transmitter sends a normal data frame out net80211 output / transmit,
  we need to ensure that the NULL data frame goes out first.
  This is one of those things that should occur inside the VAP/ic TX lock.
  Grr, more investigations to do..

Tested:

* STA: AR5416, AR9280
* AP: AR5416, AR9280, AR9160
2013-05-15 18:33:05 +00:00
Adrian Chadd
370f81fab6 Add ALQ beacon debugging. 2013-05-13 21:18:00 +00:00
Adrian Chadd
5086df9f1f Support sending ATH_ALQ messages with no payload. 2013-05-13 21:17:27 +00:00
Adrian Chadd
9b48fb4b32 Improve the debugging output - use the MAC address rather than various
pointer values everywhere.
2013-05-13 19:52:35 +00:00
Adrian Chadd
ba83edd45c Since the node state is 100% back under the TX lock, just kill the use
of atomics.

I'll re-think this nonsense later.
2013-05-13 19:03:12 +00:00
Adrian Chadd
22780332ae Oops, commit the other half of r250606. 2013-05-13 19:02:22 +00:00
Adrian Chadd
01a2ad5a4c This lock only protects the rate control state for now, mention this. 2013-05-13 18:57:18 +00:00
Adrian Chadd
4bed2b67ca Begin tidying up the reassociation and node sleep/wakeup paths.
* Move the node sleep/wake state under the TX lock rather than the
  node lock.  Let's leave the node lock protecting rate control only
  for now.

* When reassociating, various state needs to be cleared.  For example,
  the aggregate session needs to be torn down, including any pending
  aggregation negotiation and BAR TX waiting.

* .. and we need to do a "cleanup" pass since frames in the hardware
  TX queue need to be transmitted.

Modify ath_tx_tid_cleanup() to be called with the TX lock held and push
frames into a completion list.  This allows for the cleanup to be
done atomically for all TIDs in a node rather than grabbing and
releasing the TX lock each time.
2013-05-13 18:56:04 +00:00
Adrian Chadd
8328d6e4d4 Make sure the holding descriptor and link pointer are both freed during
a non-loss reset.

When the drain functions are called, the holding descriptor and link pointers
are NULLed out.

But when the processq function is called during a non-loss reset, this
doesn't occur.  So the next time a DMA occurs, it's chained to a descriptor
that no longer exists and the hardware gets angry.

Tested:

* AR5416, STA mode; use sysctl dev.ath.X.forcebstuck=1 to force a non-loss
  reset.

TODO:

* Further AR9380 testing just to check that the behaviour for the EDMA
  chips is sane.

PR:		kern/178477
2013-05-10 10:06:45 +00:00
Adrian Chadd
caedab2c56 Update the holding buffer locking for EDMA. 2013-05-09 15:57:55 +00:00
Adrian Chadd
5e0185081d Fix the holding descriptor logic to actually be "right" (for values
of "right".)

Flip back on the "always continue TX DMA using the holding descriptor"
code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL.

Since the holding descriptor is accessed via txq->axq_link and _that_
is done behind the TXQ lock rather than the TX path lock, the holding
descriptor stuff itself needs to be behind the TXQ lock.

So, do the mental gymnastics needed to do this.

I've not seen any of the hardware failures that I was seeing when
I last tried to do this.

Tested:

* AR5416, STA mode
2013-05-08 21:23:51 +00:00
Adrian Chadd
caa16e6960 This shouldn't have made it into this commit, sorry. 2013-05-08 08:53:55 +00:00
Adrian Chadd
d3731e4b21 Revert a previous commit - this is causing hardware errors.
I'm not sure why this is failing.  The holding descriptor should be being
re-read when starting DMA of the next frame.  Obviously something here
isn't totally correct.

I'll review the TX queue handling and see if I can figure out why this
is failing.  I'll then re-revert this patch out and use the holding
descriptor again.
2013-05-08 07:30:33 +00:00
Adrian Chadd
2c47932c88 Implement STBC receive frame statistics.
The AR9280 and later can receive STBC.  This adds some statistics
tracking to count these frames.

A patch to athstats will be forthcoming.
2013-05-08 01:11:25 +00:00
Adrian Chadd
7dcb2bea01 Re-work how transmit buffer limits are enforced - partly to fix the PR,
but partly to just tidy up things.

The problem here - there are too many TX buffers in the queue! By the
time one needs to transmit an EAPOL frame (for this PR, it's the response
to the group rekey notification from the AP) there are no ath_buf entries
free and the EAPOL frame doesn't go out.

Now, the problem!

* Enforcing the TX buffer limitation _before_ we dequeue the frame?
  Bad idea. Because..
* .. it means I can't check whether the mbuf has M_EAPOL set.

The solution(s):

* De-queue the frame first
* Don't bother doing the TX buffer minimum free check until after
  we know whether it's an EAPOL frame or not.
* If it's an EAPOL frame, allocate the buffer from the mgmt pool
  rather than the default pool.

Whilst I'm here:

* Add a tweak to limit how many buffers a single node can acquire.
* Don't enforce that for EAPOL frames.
* .. set that to default to 1/4 of the available buffers, or 32,
  whichever is more sane.

This doesn't fix issues due to a sleeping node or a very poor performing
node; but this doesn't make it worse.

Tested:

* AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received
  (thus the TX queue fills up.)
* .. with CCMP / WPA2 encryption configured
* .. and the group rekey time set to 10 seconds, just to elicit the
  behaviour very quickly.

PR:		kern/138379
2013-05-07 07:52:18 +00:00
Adrian Chadd
55cf0326a1 Simplify this bit of code! 2013-05-07 07:44:07 +00:00
Adrian Chadd
4136c09143 The holding buffer logic needs to be used for _all_ transmission, not
just "when the queue is busy."

After talking with the MAC team, it turns out that the linked list
implementation sometimes will not accept a TxDP update and will
instead re-read the link pointer.  So even if the hardware has
finished transmitting a chain and has hit EOL/VEOL, it may still
re-read the link pointer to begin transmitting again.

So, always set ATH_BUF_BUSY on the last buffer in the chain (to
mark the last descriptor as the holding descriptor) and never
blank the axq_link pointer.

Tested:

* AR5416, STA mode

TODO:

* much more thorough testing with the pre-11n NICs, just to verify
  that they behave the same way.
* test TDMA on the 11n and non-11n hardware.
2013-05-04 04:03:50 +00:00
Adrian Chadd
2f544eedb3 Add device identification and probe/attach support for the QCA9565.
The QCA9565 is a 1x1 2.4GHz 11n chip with integrated on-chip bluetooth.
The AR9300 HAL already has support for this chip; it just wasn't
included in the probe/attach path.

Tested:

* This commit brought to you over a QCA9565 wifi connection from
  FreeBSD.
* .. ie, basic STA, pings, no iperf or antenna diversity checking just yet.
2013-05-02 00:59:39 +00:00
Adrian Chadd
8d06054291 Debugging changes!
* That lock isn't actually held during reset - just the whole TX/RX path
  is paused.  So, remove the assertion.

* Log the TX queue status - how many hardware frames are active in the
  MAC and whether the queue is active.
2013-04-29 07:28:29 +00:00
Adrian Chadd
07187d1109 Conditionally compile this only if ATH_DEBUG is defined. 2013-04-26 22:22:38 +00:00
Adrian Chadd
ed261a611b Dump the entire TXQ descriptor contents during a reset, rather than only
completed descriptors.
2013-04-26 21:51:17 +00:00
Adrian Chadd
3527f6a9b1 When doing BAW tracking, don't dereference a NULL pointer if the BAW
slot is actually NULL.
2013-04-21 00:41:15 +00:00
Adrian Chadd
dff5bdf48c There's some races (likely in the BAR handling, sigh) which is causing
the pause/resume code to not be called completely symmetrically.

I'll chase down the root cause of that soon; this at least works around
the bug and tells me when it happens.
2013-04-20 22:46:31 +00:00
Adrian Chadd
ff5b563430 Initialise the chainmask fields regardless of whether 11n support
is compiled in or not.

This fixes issues with people running -HEAD but who build modules
without doing a "make buildkernel KERNCONF=XXX", thus picking up
opt_*.h.  The resulting module wouldn't have 11n enabled and the
chainmask configuration would just be plain wrong.
2013-04-19 21:49:11 +00:00
Adrian Chadd
7904f51655 Add a debug statement to log the currently chosen chainmask configuration. 2013-04-19 08:06:45 +00:00
Adrian Chadd
b0bf95ff15 .. don't know how this snuck into this commit. Sorry.
Fix compile build before anyone notices.
2013-04-19 08:01:34 +00:00
Adrian Chadd
b661bd2e52 Print out the chainmask configuration. 2013-04-19 07:56:22 +00:00
Adrian Chadd
6f4fb2d8e6 Use uint32_t for fields that are fetched via ath_hal_getcapability(). 2013-04-19 06:59:10 +00:00
Adrian Chadd
91046e9c5f Setup needed tables for TPC on AR5416->AR9287 chips.
* Add ah_ratesArray[] to the ar5416 HAL state - this stores the maximum
  values permissable per rate.
* Since different chip EEPROM formats store this value in a different place,
  store the HT40 power detector increment value in the ar5416 HAL state.
* Modify the target power setup code to store the maximum values in the
  ar5416 HAL state rather than using a local variable.
* Add ar5416RateToRateTable() - to convert a hardware rate code to the
  ratesArray enum / index.
* Add ar5416GetTxRatePower() - which goes through the gymnastics required
  to correctly calculate the target TX power:
  + Add the power detector increment for ht40;
  + Take the power offset into account for AR9280 and later;
  + Offset the TX power correctly when doing open-loop TX power control;
  + Enforce the per-rate maximum value allowable.

Note - setting a TPC value of 0x0 in the TX descriptor on (at least)
the AR9160 resulted in the TX power being very high indeed.  This didn't
happen on the AR9220.  I'm guessing it's a chip bug that was fixed at
some point.  So for now, just assume the AR5416/AR5418 and AR9130 are
also suspect and clamp the minimum value here at 1.

Tested:

* AR5416, AR9160, AR9220 hostap, verified using (2GHz) spectrum analyser
* Looked at target TX power in TX descriptor (using athalq) as well as TX
  power on the spectrum analyser.

TODO:

* The TX descriptor code sets the target TX power to 0 for AR9285 chips.
  I'm not yet sure why.  Disable this for TPC and ensure that the TPC
  TX power is set.
* AR9280, AR9285, AR9227, AR9287 testing!
* 5GHz testing!

Quirks:

* The per-packet TPC code is only exercised when the tpc sysctl is set
  to 1. (dev.ath.X.tpc=1.) This needs to be done before you bring the
  interface up.
* When TPC is enabled, setting the TX power doesn't end up with a call
  through to the HAL to update the maximum TX power.  So ensure that
  you set the TPC sysctl before you bring the interface up and configure
  a lower TX power or the hardware will be clamped by the lower TX
  power (at least until the next channel change.)

Thanks to Qualcomm Atheros for all the hardware, and Sam Leffler for use
of his spectrum analyser to verify the TX channel power.
2013-04-17 07:31:53 +00:00
Adrian Chadd
8b470f6f71 Use the TPC bank by default for AR9160.
Tested:

* AR9160, hostap, verified TX power using (2GHz) spectrum analyser

TODO:

* 5GHz verification!
2013-04-17 07:22:23 +00:00
Adrian Chadd
de00e5cb54 Update the rate series setup code to use the decisions already made in
ath_tx_rate_fill_rcflags().  Include setting up the TX power cap in the
rate scenario setup code being passed to the HAL.

Other things:

* add a tx power cap field in ath_rc.
* Add a three-stream flag in ath_rc.
* Delete the LDPC flag from ath_rc - it's not a per-rate flag, it's a
  global flag for the transmission.
2013-04-17 07:21:30 +00:00
Adrian Chadd
12087a0769 Use the new net80211 method to fetch the node TX power, rather than
directly referencing ni->ni_txpower.

This provides the hardware with a slightly more accurate idea of
the maximum TX power to be using.

This is part of a series to get per-packet TPC to work (better).

Tested:

* AR5416, hostap mode
2013-04-16 21:26:44 +00:00
Adrian Chadd
5d4dedadb6 Use a per-RX-queue deferred list, rather than a single deferred list for
both queues.

Since ath_rx_pkt() does multi-mbuf frame recombining based on the RX queue,
this needs to occur.

Tested:

* AR9380 (XB112), hostap mode
2013-04-16 20:21:02 +00:00
Adrian Chadd
978c5ce568 Now that the register definitions are in -HEAD, enable this. 2013-04-15 17:59:06 +00:00
Adrian Chadd
a04110a3b6 Bring over some AR9271 register definitions from the QCA HAL.
Obtained from:	Qualcomm Atheros
2013-04-15 17:58:11 +00:00
Adrian Chadd
6961e9eda4 Always enable TXOK interrupts when setting up TX queues for EDMA NICs. 2013-04-11 22:02:35 +00:00
Adrian Chadd
69cbcb210d Fix this to compile when ATH_DEBUG_ALQ is defined but ATH_DEBUG isn't. 2013-04-08 21:15:43 +00:00
Adrian Chadd
7598a108ff Add a new TX power field - it's inteded to be used where low TX power
is configured for higher rates (lower than max) but higher TX power
is configured for the lower rates, above the configured cap, to improve
long distance behaviour.
2013-04-05 09:06:39 +00:00
Adrian Chadd
9580780191 HAL additions to enable MCI Bluetooth coexistence in the AR9300 HAL.
* Add the rest of the missing GPIO output mux types;
* Add in a new debug category;
* And a new MCI btcoex configuration option in ath_hal.ah_config

Obtained from:	Qualcomm Atheros
2013-04-05 07:41:47 +00:00
Adrian Chadd
28f4a39c95 Update comments! 2013-04-04 08:57:29 +00:00
Adrian Chadd
8cc724d9be Fix the busdma logic to work with EDMA chipsets when using bounce
buffers (ie, >4GB on amd64.)

The underlying problem was that PREREAD doesn't sync the mbuf
with the DMA memory (ie, bounce buffer), so the bounce buffer may
have had stale information.  Thus it was always considering the
buffer completed and things just went off the rails.

This change does the following:

* Make ath_rx_pkt() always consume the mbuf somehow; it no longer
  passes error mbufs (eg CRC errors, crypt errors, etc) back up
  to the RX path to recycle.  This means that a new mbuf is always
  allocated each time, but it's cleaner.

* Push the RX buffer map/unmap to occur in the RX path, not
  ath_rx_pkt().  Thus, ath_rx_pkt() now assumes (a) it has to consume
  the mbuf somehow, and (b) that it's already been unmapped and
  synced.

* For the legacy path, the descriptor isn't mapped, it comes out of
  coherent, DMA memory anyway.  So leave it there.

* For the EDMA path, the RX descriptor has to be cleared before
  its passed to the hardware, so that when we check with
  a POSTREAD sync, we actually get either a blank (not finished)
  or a filled out descriptor (finished.)  Otherwise we get stale
  data in the DMA memory.

* .. so, for EDMA RX path, we need PREREAD|PREWRITE to sync the
  data -> DMA memory, then POSTREAD|POSTWRITE to finish syncing
  the DMA memory -> data.

* Whilst we're here, make sure that in EDMA buffer setup (ie,
  bzero'ing the descriptor part) is done before the mbuf is
  map/synched.

NOTE: there's been a lot of commits besides this one with regards to
tidying up the busdma handling in ath(4).  Please check the recent
commit history.

Discussed with and thanks to:	scottl

Tested:

* AR5416 (non-EDMA) on i386, with the DMA tag for the driver
  set to 2^^30, not 2^^32, STA

* AR9580 (EDMA) on i386, as above, STA

* User - tested AR9380 on amd64 with 32GB RAM.

PR:		kern/177530
2013-04-04 08:21:56 +00:00
Adrian Chadd
c23a9d98bf Mark a couple of places where I think the dmamap isn't being unmapped
before the TX path is being aborted.

Right now it's in the TDMA code and I can live with that; but it really
should get fixed.

I'll do a more thorough audit of this code soon.
2013-04-02 06:25:10 +00:00
Adrian Chadd
a91ab3c099 Some TX dmamap cleanups.
* Don't use BUS_DMA_ALLOCNOW for descriptor DMA maps; we never use
  bounce buffers for the descriptors themselves.

* Add some XXX's to mark where the ath_buf has its mbuf ripped from
  underneath it without actually cleaning up the dmamap.  I haven't
  audited those particular code paths to see if the DMA map is guaranteed
  to be setup there; I'll do that later.

* Print out a warning if the descdma tidyup code is given some descriptors
  w/ maps to free.  Ideally the owner will free the mbufs and unmap
  the descriptors before freeing the descriptor/ath_buf pairs, but
  right now that's not guaranteed to be done.

Reviewed by:	scottl (BUS_DMA_ALLOCNOW tag)
2013-04-02 06:24:22 +00:00
Adrian Chadd
18303fd833 Add a missing unmap; if we're freeing this mbuf then we must
really both sync/unmap the dmamap before freeing it.
2013-04-02 06:21:37 +00:00
Adrian Chadd
3f3a5dbd2c Ensure that we only call the busdma unmap/flush routines once, when
the buffer is being freed.

* When buffers are cloned, the original mapping isn't copied but it
  wasn't freeing the mapping until later.  To be safe, free the
  mapping when the buffer is cloned.

* ath_freebuf() now no longer calls the busdma sync/unmap routines.

* ath_tx_freebuf() now calls sync/unmap.

* Call sync first, before calling unmap.

Tested:

* AR5416, STA mode
2013-04-01 20:57:13 +00:00
Adrian Chadd
587feafb5a Remove an un-needed comment. 2013-04-01 20:44:21 +00:00
Adrian Chadd
09067b6e9a Use ATH_MAX_SCATTER rather than ATH_TXDESC.
ATH_MAX_SCATTER is used to size the ath_buf DMA segment array.
We thus should use it when checking sizes of things.
2013-04-01 20:12:21 +00:00
Adrian Chadd
80b87f1814 Only unmap the RX mbuf DMA map if there's a buffer here.
The normal RX path (ath_rx_pkt()) will sync and unmap the
buffer before passing it up the stack.  We only need to do this
if we're flushing the FIFO during reset/shutdown.
2013-04-01 20:11:19 +00:00
Adrian Chadd
b92b5f6e3a * Stop processing after HAL_EIO; this is what the reference driver does.
* If we hit an empty queue condition (which I haven't yet root caused, grr.)
  .. make sure we release the lock before continuing.
2013-03-27 00:35:45 +00:00
Adrian Chadd
92e84e43a6 Implement the replacement EDMA FIFO code.
(Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've
actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was
cleared!)

This code implements a whole bunch of sorely needed EDMA TX improvements
along with CABQ TX support.

The specifics:

* When filling/refilling the FIFO, use the new TXQ staging queue
  for FIFO frames

* Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly.
  For now the non-CABQ transmit path pushes one frame into the TXQ
  staging queue without setting up the intermediary link pointers
  to chain them together, so draining frames from the txq staging
  queue to the FIFO queue occurs AMPDU / MPDU at a time.

* In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and
  ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO
  at once.

* Now that frames are in a FIFO pending queue, we can top up the
  FIFO after completing a single frame.  This means we can keep
  it filled rather than waiting for it drain and _then_ adding
  more frames.

* The EDMA restart routine now walks the FIFO queue in the TXQ
  rather than the pending queue and re-initialises the FIFO with
  that.

* When restarting EDMA, we may have partially completed sending
  a list.  So stamp the first frame that we see in a list with
  ATH_BUF_FIFOPTR and push _that_ into the hardware.

* When completing frames, only check those on the FIFO queue.
  We should never ever queue frames from the pending queue
  direct to the hardware, so there's no point in checking.

* Until I figure out what's going on, make sure if the TXSTATUS
  for an empty queue pops up, complain loudly and continue.
  This will stop the panics that people are seeing.  I'll add
  some code later which will assist in ensuring I'm populating
  each descriptor with the correct queue ID.

* When considering whether to queue frames to the hardware queue
  directly or software queue frames, make sure the depth of
  the FIFO is taken into account now.

* When completing frames, tag them with ATH_BUF_BUSY if they're
  not the final frame in a FIFO list.  The same holding descriptor
  behaviour is required when handling descriptors linked together
  with a link pointer as the hardware will re-read the previous
  descriptor to refresh the link pointer before contiuning.

* .. and if we complete the FIFO list (ie, the buffer has
  ATH_BUF_FIFOEND set), then we don't need the holding buffer
  any longer.  Thus, free it.

Tested:

* AR9380/AR9580, STA and hostap
* AR9280, STA/hostap

TODO:

* I don't yet trust that the EDMA restart routine is totally correct
  in all circumstances.  I'll continue to thrash this out under heavy
  multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
Adrian Chadd
3feffbd796 Add per-TXQ EDMA FIFO staging queue support.
Each set of frames pushed into a FIFO is represented by a list of
ath_bufs - the first ath_buf in the FIFO list is marked with
ATH_BUF_FIFOPTR; the last ath_buf in the FIFO list is marked with
ATH_BUF_FIFOEND.

Multiple lists of frames are just glued together in the TAILQ as per
normal - except that at the end of a FIFO list, the descriptor link
pointer will be NULL and it'll be tagged with ATH_BUF_FIFOEND.

For non-EDMA chipsets this is a no-op - the ath_txq frame list (axq_q)
stays the same and is treated the same.

For EDMA chipsets the frames are pushed into axq_q and then when
the FIFO is to be (re) filled, frames will be moved onto the FIFO
queue and then pushed into the FIFO.

So:

* Add a new queue in each hardware TXQ (ath_txq) for staging FIFO frame
  lists.  It's a TAILQ (like the normal hardware frame queue) rather than
  the ath9k list-of-lists to represent FIFO entries.

* Add new ath_buf flags - ATH_TX_FIFOPTR and ATH_TX_FIFOEND.

* When allocating ath_buf entries, clear out the flag value before
  returning it or it'll end up having stale flags.

* When cloning ath_buf entries, only clone ATH_BUF_MGMT.  Don't clone
  the FIFO related flags.

* Extend ath_tx_draintxq() to first drain the FIFO staging queue, _then_
  drain the normal hardware queue.

Tested:

* AR9280, hostap
* AR9280, STA
* AR9380/AR9580 - hostap

TODO:

* Test on other chipsets, just to be thorough.
2013-03-26 19:46:51 +00:00
Adrian Chadd
35bec3655e Remove the mcast path calls to ath_hal_gettxdesclinkptr() for axq_link -
they're no longer needed for the legacy path and they're not wanted
for the EDMA path.

Tested:

* AR9280, hostap + CABQ
* AR9380/AR9580, hostap + CABQ
2013-03-26 04:56:54 +00:00
Adrian Chadd
b708ea2941 Remove this dead code - it's no longer relevant (as yes, we do actually
support TX on EDMA chips.)
2013-03-26 04:53:40 +00:00
Adrian Chadd
b6ef0f8ac8 Convert the CABQ queue code over to use the HAL link pointer method
instead of axq_link.

This (among a bunch of uncommitted work) is required for EDMA chips
to correctly transmit frames on the CABQ.

Tested:

* AR9280, hostap mode
* AR9380/AR9580, hostap mode (staggered beacons)

TODO:

* This code only really gets called when burst beacons are used;
  it glues multiple CABQ queues together when sending to the hardware.
* More thorough bursted beacon testing! (first requires some work with
  the beacon queue code for bursted beacons, as that currently uses the
  link pointer and will fail on EDMA chips.)
2013-03-26 04:52:16 +00:00
Adrian Chadd
9e7259a2a3 Convert the EDMA multicast queue code over to use the HAL method to set
the descriptor link pointer, rather than directly.

This is needed on AR9380 and later (ie, EDMA) NICs so the multicast queue
has a chance in hell of being put together right.

Tested:

* AR9380, AR9580 in hostap mode, CABQ traffic (but with other patches..)
2013-03-26 04:48:58 +00:00
Adrian Chadd
0891354cd2 Migrate the multicast queue assembly code to not use the axq_link pointer
and instead use the HAL method to set the link pointer.

Tested:

* AR9280, hostap mode, CABQ frames being queued and transmitted
2013-03-26 04:47:40 +00:00
Adrian Chadd
1f6b3ed63c Add new regulatory domain.
Obtained from:	Qualcomm Atheros
2013-03-24 04:42:56 +00:00
Adrian Chadd
56a859789f Move the TXQ lock earlier in this routine - so to correctly protect the
link pointer check.
2013-03-24 04:09:54 +00:00
Adrian Chadd
0acf45ed86 Fix the locking changes due to the TXQ change drive-by.
Tested:

* AR9580, STA mode
2013-03-24 04:09:29 +00:00
Adrian Chadd
b837332d0a Overhaul the TXQ locking (again!) as part of some beacon/cabq timing
related issues.

Moving the TX locking under one lock made things easier to progress on
but it had one important side-effect - it increased the latency when
handling CABQ setup when sending beacons.

This commit introduces a bunch of new changes and a few unrelated changs
that are just easier to lump in here.

The aim is to have the CABQ locking separate from other locking.
The CABQ transmit path in the beacon process thus doesn't have to grab
the general TX lock, reducing lock contention/latency and making it
more likely that we'll make the beacon TX timing.

The second half of this commit is the CABQ related setup changes needed
for sane looking EDMA CABQ support.  Right now the EDMA TX code naively
assumes that only one frame (MPDU or A-MPDU) is being pushed into each
FIFO slot.  For the CABQ this isn't true - a whole list of frames is
being pushed in - and thus CABQ handling breaks very quickly.

The aim here is to setup the CABQ list and then push _that list_ to
the hardware for transmission.  I can then extend the EDMA TX code
to stamp that list as being "one" FIFO entry (likely by tagging the
last buffer in that list as "FIFO END") so the EDMA TX completion code
correctly tracks things.

Major:

* Migrate the per-TXQ add/removal locking back to per-TXQ, rather than
  a single lock.

* Leave the software queue side of things under the ATH_TX_LOCK lock,
  (continuing) to serialise things as they are.

* Add a new function which is called whenever there's a beacon miss,
  to print out some debugging.  This is primarily designed to help
  me figure out if the beacon miss events are due to a noisy environment,
  issues with the PHY/MAC, or other.

* Move the CABQ setup/enable to occur _after_ all the VAPs have been
  looked at.  This means that for multiple VAPS in bursted mode, the
  CABQ gets primed once all VAPs are checked, rather than being primed
  on the first VAP and then having frames appended after this.

Minor:

* Add a (disabled) twiddle to let me enable/disable cabq traffic.
  It's primarily there to let me easily debug what's going on with beacon
  and CABQ setup/traffic; there's some DMA engine hangs which I'm finally
  trying to trace down.

* Clear bf_next when flushing frames; it should quieten some warnings
  that show up when a node goes away.

Tested:

* AR9280, STA/hostap, up to 4 vaps (staggered)
* AR5416, STA/hostap, up to 4 vaps (staggered)

TODO:

* (Lots) more AR9380 and later testing, as I may have missed something here.
* Leverage this to fix CABQ hanling for AR9380 and later chips.
* Force bursted beaconing on the chips that default to staggered beacons and
  ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being
  correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
Adrian Chadd
49ddabc4bd CABQ calculation changes to try and fix some weird corner cases leading
to stuck beacons.

* Set the cabq readytime (ie, how long to burst for) to 50% of the total
  beacon interval time
* fix the cabq adjustment calculation based on how the beacon offset is
  calculated (the SWBA/DBA time offset.)

This is all still a bit magic voodoo but it does seem to have further
quietened issues with missed/stuck beacons under my local testing.
In any case, it better matches what the reference HAL implements.

Obtained from:	Qualcomm Atheros
2013-03-23 23:51:11 +00:00
Adrian Chadd
9cda8c8082 Fix the EDMA CABQ handling - for now, the CABQ takes a descriptor chain
like the legacy chips expect.
2013-03-20 05:44:03 +00:00
Adrian Chadd
f0db652cf6 Break out the RX completion path into "FIFO check / refill" and
"complete RX frames."

The 128 entry RX FIFO is really easy to fill up and miss refilling
when it's done in the ath taskq - as that gets blocked up doing
RX completion, TX completion and other random things.

So the 128 entry RX FIFO now gets emptied and refilled in the ath_intr()
task (and it grabs / releases locks, so now ath_intr() can't just be
a FAST handler yet!) but the locks aren't held for very long. The
completion part is done in the ath taskqueue context.

Details:

* Create a new completed frame list - sc->sc_rx_rxlist;
* Split the EDMA RX process queue into two halves - one that
  processes the RX FIFO and refills it with new frames; another
  that completes the completed frame list;
* When tearing down the driver, flush whatever is in the deferred
  queue as well as what's in the FIFO;
* Create two new RX methods - one that processes all RX queues,
  one that processes the given RX queue.  When MSI is implemented,
  we get told which RX queue the interrupt came in on so we can
  specifically schedule that.  (And I can do that with the non-MSI
  path too; I'll figure that out later.)
* Convert the legacy code over to use these new RX methods;
* Replace all the instances of the RX taskqueue enqueue with a call
  to a relevant RX method to enqueue one or all RX queues.

Tested:

* AR9380, STA
* AR9580, STA
* AR5413, STA
2013-03-19 19:32:28 +00:00
Adrian Chadd
74ea88c379 Add more TODO items. 2013-03-19 17:55:36 +00:00
Adrian Chadd
378a752f59 Now that the tx map field is correctly populated for both edma and
legacy chips, just use that.
2013-03-19 17:54:37 +00:00
Adrian Chadd
1ab002f461 Print out the current fifo queue depth correctly - not just the max
queue depth.

Silly hat to me.
2013-03-18 02:29:57 +00:00
Adrian Chadd
eefc93a947 Dump out information about the RX descriptor free list and FIFO information. 2013-03-18 01:12:36 +00:00
Adrian Chadd
d50e882ab9 Log some more information when the RX buffer allocation failed. 2013-03-18 01:11:52 +00:00
Adrian Chadd
cd4f1ba89f Why'd I keep this here? remove it entirely now. 2013-03-15 20:22:20 +00:00
Adrian Chadd
302868d914 Fix two bugs:
* when pulling frames off of the TID queue, the ATH_TID_REMOVE()
  macro decrements the axq_depth field.  So don't do it twice.

* in ath_tx_comp_cleanup_aggr(), bf wasn't being reset to bf_first
  before walking the buffer list to complete buffers; so those buffers
  will leak.
2013-03-15 20:00:08 +00:00
Adrian Chadd
8454d32107 Remove a now incorrect comment.
This comment dates back to my initial stab at TX aggregation completion,
where I didn't even bother trying to do software retries.
2013-03-15 04:43:27 +00:00
Adrian Chadd
5f2f0e616b Add locking around the new holdingbf code.
Since this is being done during buffer free, it's a crap shoot whether
the TX path lock is held or not.  I tried putting the ath_freebuf() code
inside the TX lock and I got all kinds of locking issues - it turns out
that the buffer free path sometimes is called with the lock held and
sometimes isn't. So I'll go and fix that soon.

Hence for now the holdingbf buffers are protected by the TXBUF lock.
2013-03-15 02:52:37 +00:00
Adrian Chadd
629ce2188a Implement "holding buffers" per TX queue rather than globally.
When working on TDMA, Sam Leffler found that the MAC DMA hardware
would re-read the last TX descriptor when getting ready to transmit
the next one.  Thus the whole ATH_BUF_BUSY came into existance -
the descriptor must be left alone (very specifically the link pointer
must be maintained) until the hardware has moved onto the next frame.

He saw this in TDMA because the MAC would be frequently stopping during
active transmit (ie, when it wasn't its turn to transmit.)

Fast-forward to today.  It turns out that this is a problem not with
a single MAC DMA instance, but with each QCU (from 0->9).  They each
maintain separate descriptor pointers and will re-read the last
descriptor when starting to transmit the next.

So when your AP is busy transmitting from multiple TX queues, you'll
(more) frequently see one QCU stopped, waiting for a higher-priority QCU
to finsh transmitting, before it'll go ahead and continue.  If you mess
up the descriptor (ie by freeing it) then you're short of luck.

Thanks to rpaulo for sticking with me whilst I diagnosed this issue
that he was quite reliably triggering in his environment.

This is a reimplementation; it doesn't have anything in common with
the ath9k or the Qualcomm Atheros reference driver.

Now - it in theory doesn't apply on the EDMA chips, as long as you
push one complete frame into the FIFO at a time.  But the MAC can DMA
from a list of frames pushed into the hardware queue (ie, you concat
'n' frames together with link pointers, and then push the head pointer
into the TXQ FIFO.)  Since that's likely how I'm going to implement
CABQ handling in hostap mode, it's likely that I will end up teaching
the EDMA TX completion code about busy buffers, just to be "sure"
this doesn't creep up.

Tested - iperf ap->sta and sta->ap (with both sides running this code):

* AR5416 STA
* AR9160/AR9220 hostap

To validate that it doesn't break the EDMA (FIFO) chips:

* AR9380, AR9485, AR9462 STA

Using iperf with the -S <tos byte decimal value> to set the TCP client
side DSCP bits, mapping to different TIDs and thus different TX queues.

TODO:

* Make this work on the EDMA chips, if we end up pushing lists of frames
  to the hardware (eg how we eventually will handle cabq in hostap/ibss
  mode.)
2013-03-14 06:20:02 +00:00
Adrian Chadd
0639c54a67 Use the correct antenna configuration variable here. "diversity" just
controls whether it's on or off.

Found by:	clang
2013-03-12 03:03:24 +00:00
Adrian Chadd
0e168bb8e3 Add a few new fields to the RX vendor radiotap header:
* a flags field that lets me know what's going on;
* the hardware ratecode, unmolested by conversion to a bitrate;
* the HAL rs_flags field, useful for debugging;
* specifically mark aggregate sub-frames.

This stuff sorely needs tidying up - it's missing some important
stuff (eg numdelims) and it would be nice to put the flags at the
beginning rather than at the end.

Tested:

* AR9380, STA mode, 2x2 HT40, monitoring RSSI and EVM values
2013-03-11 06:54:58 +00:00
Adrian Chadd
6b3ba411d3 Bump the EVM array size up to fit the AR9380 EVM entries. 2013-03-11 06:01:00 +00:00
Adrian Chadd
1896b0880a Add three-stream EVM values. 2013-03-11 04:19:10 +00:00
Adrian Chadd
ba8d066231 Add another register definition bit - whether to populate EVM or PLCP
data in the RX status descriptor.

Obtained from:	Qualcomm Atheros
2013-03-10 09:43:01 +00:00
Adrian Chadd
b3420862a7 Disable the hw TID != buffer TID check.
I can 100% reliably trigger this on TID 1 traffic by using iperf -S 32
<client fields> to create traffic that maps to TID 1.

The reference driver doesn't do this check.
2013-03-09 08:50:17 +00:00
Adrian Chadd
9d2a962bf3 Print out the queue flags during a TX DMA shutdown. 2013-03-09 06:11:58 +00:00
Adrian Chadd
bdb9fa5c87 add a method to set/clear the VMF field in the TX descriptor.
Obtained from:	Qualcomm Atheros
2013-03-04 07:40:49 +00:00
Adrian Chadd
87c176d272 Add missing flags. 2013-02-28 23:39:38 +00:00
Adrian Chadd
7a27f0a338 Oops - fix an incorrect test. 2013-02-28 23:39:22 +00:00
Adrian Chadd
5612990623 Don't enable the HT flags for legacy rates.
I stumbled across this whilst trying to debug another weird hang reported
on the freebsd-wireless list.

Whilst here, add in the STBC check to ath_rateseries_setup().

Whilst here, fix the short preamble flag to be set only for legacy rates.

Whilst here, comment that we should be using the full set of decisions
made by ath_rateseries_setup() rather than recalculating them!
2013-02-28 23:31:23 +00:00
Adrian Chadd
ee563d630b I give up - just throw the EWMA update into the normal update_stats()
routine.

There were still corner cases where the EWMA update stats are being
called on a rix which didn't have an intermediary stats update; thus
no packets were counted against it.  Sigh.

This should fix the crashes I've been seeing on recent -HEAD.
2013-02-27 04:33:06 +00:00
Adrian Chadd
1a3a560767 Enable STBC for the given rate series if it's negotiated:
* If both ends have negotiated (at least) one stream;
* Only if it's a single stream rate (MCS0-7);
* Only if there's more than one TX chain enabled.

Tested:

* AR9280 STA mode -> Atheros AP; tested both MCS2 (STBC) and MCS12 (no STBC.)
  Verified using athalq to inspect the TX descriptors.

TODO:

* Test AR5416 - no STBC should be enabled;
* Test AR9280 with one TX chain enabled - no STBC should be enabled.
2013-02-27 00:49:32 +00:00
Adrian Chadd
6606ba811c Add in the STBC TX/RX capability support into the HAL and driver.
The HAL already included the STBC fields; it just needed to be exposed
to the driver and net80211 stack.

This should allow single-stream STBC TX and RX to be negotiated; however
the driver and rate control code currently don't do anything with it.
2013-02-27 00:25:44 +00:00
Adrian Chadd
38fda92679 Update the EWMA statistics for each intermediary rate as well as the final
rate.

This fixes two things:

* The intermediary rates now also have their EWMA values changed;
* The existing code was using the wrong value for longtries - so the
  EWMA stats were only adjusted for the first rate and not subsequent
  rates in a MRR setup.

TODO:

* Merge the EWMA updates into update_stats() now..
2013-02-26 10:24:49 +00:00
Adrian Chadd
6322256b83 Part #2 of the TX chainmask changes:
* Remove ar5416UpdateChainmasks();
* Remove the TX chainmask override code from the ar5416 TX descriptor
  setup routines;
* Write a driver method to calculate the current chainmask based on the
  operating mode and update the driver state;
* Call the HAL chainmask method before calling ath_hal_reset();
* Use the currently configured chainmask in the TX descriptors rather than
  the hardware TX chainmasks.

Tested:

* AR5416, STA/AP mode - legacy and 11n modes
2013-02-25 22:45:02 +00:00
Adrian Chadd
d2a72d673f Begin adding support to explicitly set the current chainmask.
Right now the only way to set the chainmask is to set the hardware
configured chainmask through capabilities.  This is fine for forcing
the chainmask to be something other than what the hardware is capable
of (eg to reduce TX/RX to one connected antenna) but it does change what
the HAL hardware chainmask configuration is.

For operational mode changes, it (may?) make sense to separately control
the TX/RX chainmask.

Right now it's done as part of ar5416_reset.c - ar5416UpdateChainMasks()
calculates which TX/RX chainmasks to enable based on the operating mode.
(1 for legacy and whatever is supported for 11n operation.)  But doing
this in the HAL is suboptimal - the driver needs to know the currently
configured chainmask in order to correctly enable things for each
TX descriptor.  This is currently done by overriding the chainmask
config in the ar5416 TX routines but this has to disappear - the AR9300
HAL support requires the driver to dynamically set the TX chainmask based
on the TX power and TX rate in order to meet mini-PCIe slot power
requirements.

So:

* Introduce a new HAL method to set the operational chainmask variables;
* Introduce null methods for the previous generation chipsets;
* Add new driver state to record the current chainmask separate from
  the hardware configured chainmask.

Part #2 of this will involve disabling ar5416UpdateChainMasks() and moving
it into the driver; as well as properly programming the TX chainmask
based on the currently configured HAL chainmask.

Tested:

* AR5416, STA mode - both legacy (11a/11bg) and 11n rates - verified
  that AR_SELFGEN_MASK (the chainmask used for self-generated frames like
  ACKs and RTSes) is correct, as well as the TX descriptor contents is
  correct.
2013-02-25 22:42:43 +00:00
Adrian Chadd
ffdc8f48dd Add a workaround for AR5416, AR9130 and AR9160 chipsets - work around
an incorrectly calculated RTS duration value when transmitting aggregates.

These earlier 802.11n NICs incorrectly used the ACK duration time when
calculating what to put in the RTS of an aggregate frame.  Instead it
should have used the block-ack time.  The result is that other stations
may not reserve enough time and start transmitting _over_ the top of
the in-progress blockack field.  Tsk.

This workaround is to popuate the burst duration field with the delta
between the ACK duration the hardware is using and the required duration
for the block-ack.  The result is that the RTS field should now contain
the correct duration for the subsequent block-ack.

This doesn't apply for AR9280 and later NICs.

Obtained from:	Qualcomm Atheros
2013-02-22 07:07:11 +00:00
Adrian Chadd
ce597531f2 Disable debugging entries about BAW issues. I haven't seen any issues
to do with BAW tracking in the last 9 months or so.
2013-02-21 21:47:35 +00:00
Adrian Chadd
de2d9111ec Be slightly more paranoid with the TX DMA buffer maximum threshold.
Specifically - never jack the TX FIFO threshold up to the absolute
maximum; always leave enough space for two DMA transactions to
appear.

This is a paranoia from the Linux ath9k driver.  It can't hurt.

Obtained from:	Linux ath9k
2013-02-21 08:42:40 +00:00
Adrian Chadd
a54ecf784a Add an option to allow the minimum number of delimiters to be tweaked.
This is primarily for debugging purposes.

Tested:

* AR5416, STA mode
2013-02-21 06:38:49 +00:00
Adrian Chadd
4a502c332a Add a new option to limit the maximum size of aggregates.
The default is to limit them to what the hardware is capable of.

Add sysctl twiddles for both the non-RTS and RTS protected aggregate
generation.

Whilst here, add some comments about stuff that I've discovered during
my exploration of the TX aggregate / delimiter setup path from the
reference driver.
2013-02-21 06:18:40 +00:00
Adrian Chadd
054eace83f Remove this unneeded printf(), sorry! 2013-02-21 02:52:13 +00:00
Adrian Chadd
d7cc11edce Configure larger TX FIFO default and maximum level values.
This has reduced the number of TX delimiter and data underruns when
doing large UDP transfers (>100mbit).

This stops any HAL_INT_TXURN interrupts from occuring, which is a good
sign!

Obtained from:	Qualcomm Atheros
2013-02-20 12:14:49 +00:00
Adrian Chadd
71d6fe723e If any of the TX queues have underrun reporting enabled, enable
HAL_INT_TXURN in the interrupt mask register.

This should now allow for TXURN interrupts to be posted.
2013-02-20 11:24:11 +00:00
Adrian Chadd
f274e91f67 A couple of quick tidyups:
* Delete this debugging print - I used it when debugging the initial
  TX descriptor chaining code.  It now works, so let's toss it.
  It just confuses people if they enable TX descriptor debugging as they
  get two slightly different versions of the same descriptor.

* Indenting.
2013-02-20 11:22:44 +00:00
Adrian Chadd
69930f8794 Enable TX FIFO underrun interrupts. This allows the TX FIFO threshold
adjustment code to now run.

Tested:

* AR5416, STA

TODO:

* Much more thorough testing on the other chips, AR5210 -> AR9287
2013-02-20 11:20:51 +00:00
Adrian Chadd
bab336db27 oops, tab! 2013-02-20 11:17:29 +00:00
Adrian Chadd
a26f33276f Post interrupts in the ath alq trace. 2013-02-20 11:17:03 +00:00
Adrian Chadd
158cb431db CFG_ERR, DATA_UNDERRUN and DELIM_UNDERRUN are all flags, rather than
part of ts_status. Thus:

* make sure we decode them from ts_flags, rather than ts_status;
* make sure we decode them regardless of whether there's an error or not.

This correctly exposes descriptor configuration errors, TX delimiter
underruns and TX data underruns.
2013-02-20 11:14:55 +00:00
Adrian Chadd
feb043c69c Fix an incorrect sizeof()
PR:		kern/176238
Submitted by:	Christoph Mallon <christoph.mallon@gmx.de>
2013-02-18 18:39:15 +00:00
Adrian Chadd
d97c06b3a4 Add a new ATH KTR debug method to log the interrupt status. 2013-02-18 04:10:38 +00:00
Adrian Chadd
1844ff169f * Reduce the PCU lock overhead a little by only re-acquiring it if we
actually do have to reinitialise the RX side of things after an RX
  descriptor EOL error.

* Revert a change of mine from quite a while ago - don't shortcut the
  RX initialisation path.  There's a RX FIFO bug in the earlier chips
  (I'm not sure when it was fixed in this series, but it's fixed
  with the AR9380 and later) which causes the same RX descriptor to
  be written to over and over.  This causes the descriptor to be
  marked as "done", and this ends up causing the whole RX path to
  go very strange.  This should fixed the "kickpcu; handled X packets"
  message spam where "X" is consistently small.
2013-02-16 19:11:57 +00:00
Adrian Chadd
1a85141ad4 Pull out the if_transmit() work and revert back to ath_start().
My changed had some rather significant behavioural changes to throughput.
The two issues I noticed:

* With if_start and the ifnet mbuf queue, any temporary latency
  would get eaten up by some mbufs being queued.  With ath_transmit()
  queuing things to ath_buf's, I'd only get 512 TX buffers before I
  couldn't queue any further frames.

* There's also some non-zero latency involved with TX being pushed
  into a taskqueue via direct dispatch.  Any time the scheduler didn't
  immediately schedule the ath TX task would cause extra latency.
  Various 1ge/10ge drivers implement both direct dispatch (if the TX
  lock can be acquired) and deferred task transmission (if the TX lock
  can't be acquired), with frames being pushed into a drbd queue.
  I'll have to do this at some point, but until I figure out how to
  deal with 802.11 fragments, I'll have to wait a while longer.

So what I saw:

* lots of extra latency, specially under load - if the taskqueue
  wasn't immediately scheduled, things went pear shaped;

* any extra latency would result in TX ath_buf's taking their sweet time
  being replenished, so any further calls to ath_transmit() would drop
  mbufs.

* .. yes, there's no explicit backpressure here - things are just dropped.
  Eek.

With this, the general performance has gone up, but those subtle if_start()
related race conditions are back.  For some reason, this is doubly-obvious
with the AR5416 NIC and I don't quite understand why yet.

There's an unrelated issue with AR5416 performance in STA mode (it's
fine in AP mode when bridging frames, weirdly..) that requires a little
further investigation.  Specifically - it works fine on a Lenovo T40
(single core CPU) running a March 2012 9-STABLE kernel, but a Lenovo T60
(dual core) running an early November 2012 kernel behaves very poorly.
The same hardware with an AR9160 or AR9280 behaves perfectly.
2013-02-13 05:32:19 +00:00
Adrian Chadd
53a835d2db Put this back into the ath taskqueue rather than the ath TX taskqueue.
This now should mean all the entry points into the software TX
scheduler are back in the same taskqueue.
2013-02-11 07:49:40 +00:00
Adrian Chadd
a40880ade4 Go back to direct-dispatch of the software queue and frame TX paths
when they're being called from the TX completion handler.

Going (back) through the taskqueue is just adding extra locking and
latency to packet operations.  This improves performance a little bit
on most NICs.

It still hasn't restored the original performance of the AR5416 NIC
but the AR9160, AR9280 and later NICs behave very well with this.

Tested:

* AR5416 STA (still tops out at ~ 70mbit TCP, rather than 150mbit TCP..)
* AR9160 hostap (good for both TX and RX)
* AR9280 hostap (good for both TX and RX)
2013-02-11 07:48:26 +00:00
Adrian Chadd
81561d0459 Extend the timestamp to be a timeval, rather than ticks.
This makes it easier to see TX and RX buffer latencies.
2013-02-11 02:48:49 +00:00
Adrian Chadd
650da23095 The encryption type field needs to be preserved for each descriptor
making up a frame, in both a sub-frame and for all frames in an
aggregate.

Tested:

* AR5416, STA mode
2013-02-09 02:42:01 +00:00
Adrian Chadd
d03904f1db Fix a corner case that I noticed with the AR5416 (and it's currently
crappy 802.11n performance, sigh.)

With the AR5416, aggregates need to be limited to 8KiB if RTS/CTS is
enabled.  However, larger aggregates were going out with RTSCTS enabled.
The following was going on:

* The first buffer in the list would have RTS/CTS enabled in
  bf->bf_state.txflags;
* The aggregate would be formed;
* The "copy over the txflags from the first buffer" logic that I added
  blanked the RTS/CTS TX flags fields, and then copied the bf_first
  RTS/CTS flags over;
* .. but that'd cause bf_first to be blanked out! And thus the flag
  was cleared;
* So the rest of the aggregate formation would run with those flags
  cleared, and thus > 8KiB aggregates were formed.

The driver is now (again) correctly limiting aggregate formation for
the AR5416 but there are still other pending issues to resolve.

Tested:

* AR5416, STA mode
2013-02-08 09:07:03 +00:00
Adrian Chadd
1b3502e5a1 Create a new TX lock specifically for queuing frames.
This now separates out the act of queuing frames from the act of running
TX and TX completion.
2013-02-07 07:50:16 +00:00
Adrian Chadd
21bca442b9 Methodize the process of adding the software TX queue to the taskqueue.
Move it (for now) to the TX taskqueue.
2013-02-07 02:15:25 +00:00
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
Adrian Chadd
02a9696b0a Add the HAL wrapper for settsf64. 2012-11-23 05:33:01 +00:00
Adrian Chadd
c83ba0b9bf Implement a HAL method to set a 64 bit TSF value.
TODO: implement it (and test) for the AR5210/AR5211.
2012-11-23 05:32:24 +00:00
Adrian Chadd
cc637103f6 Don't allocate or program a key for the AR5210.
The AR5210 doesn't support HAL_CIPHER_CLR ('clear encryption' keycache
slots), so don't bother - just map them to slot 0 and never program them.
2012-11-19 23:54:05 +00:00
Adrian Chadd
143cfad710 Disable WEP hardware encryption on the AR5210, in order to allow other
encryption types.

The AR5210 only has four WEP key slots, in contrast to what the
later MACs have (ie, the keycache.)  So there's no way to store a "clear"
key.

Even if the driver is taught to not allocate CLR key entries for
the AR5210, the hardware will actually attempt to decode the encrypted
frames with the (likely all 0!) WEP keys.

So for now, disable the hardware encryption entirely and just so it
all in software.  That allows both WEP -and- WPA to actually work.

If someone wishes to try and make hardware WEP _but_ software WPA work,
they'll have to create a HAL capability to enable/disable hardware
encryption based on the current STA/Hostap mode. However, making
multi-vap work with one WEP and one WPA VAP will require hardware
encryption to be disabled anyway.
2012-11-19 23:42:46 +00:00
Adrian Chadd
73f81b5b19 Remove this include, it isn't needed. 2012-11-18 20:41:46 +00:00
Adrian Chadd
875d039e0a Correctly populate the RTS field.
Tested:
	* AR5210, STA mode, RTS enabled
2012-11-17 02:39:37 +00:00
Adrian Chadd
3a4d0022de * Remove ah_desc.h, it's not needed
* Add some shifts that I'm using in userspace (athalq.)

However, this exposes a fun little bug..
2012-11-17 02:39:09 +00:00
Adrian Chadd
93cad1bdbd .. include ah_desc.h here now. 2012-11-17 02:02:36 +00:00
Adrian Chadd
f8af1be8f8 Remove the ah_desc.h reference; it's not needed.
I'm using these descriptor header files in userland and I'm trying to
avoid populating a compatibility ah_desc.h file.
2012-11-17 02:00:33 +00:00
Adrian Chadd
69f33b13d1 I'm not sure why ah_desc.h was required here, but it doesn't _need_
to be. So, just toss it.

There's no options or ah_desc fields in here.

Whilst I'm here, fix up the #ifdef and #define to mach.
2012-11-16 20:04:45 +00:00
Adrian Chadd
e3f0668803 * Remove a duplicate TX ALQ post routine!
* For CABQ traffic, I -can- chain them together using the next pointer
  and just push that particular chain head to the CABQ.  However, this
  doesn't magically make EDMA TX CABQ work - I have to do some further
  hoop jumping.
2012-11-16 19:58:15 +00:00
Adrian Chadd
bb327d284b ALQ logging enhancements:
* upon setup, tell the alq code what the chip information is.
* add TX/RX path logging for legacy chips.
* populate the tx/rx descriptor length fields with a best-estimate.
  It's overly big (96 bytes when AH_SUPPORT_AR5416 is enabled)
  but it'll do for now.

Whilst I'm here, add CURVNET_RESTORE() here during probe/attach as a
partial solution to fixing crashes during attach when the attach fails.
There are other attach failures that I have to deal with; those'll come
later.
2012-11-16 19:57:16 +00:00
Adrian Chadd
956d4fb965 ath(4) ALQ logging improvements.
* Add a new method which allows the driver to push the MAC/phy/hal info
  into the logging stream.
* Add a new ALQ logging entry which logs the mac/phy/hal information.
* Modify the ALQ startup path to log the MAC/phy/hal information
  so the decoder knows which HAL/chip is generating this information.
* Convert the header and mac/phy/hal information to use be32, rather than
  host order.  I'd like to make this stuff endian-agnostic so I can
  decode MIPS generated logs on a PC.

This requires some further driver modifications to correctly log the
right initial chip information.

Also - although noone bar me is currently using this, I've shifted the
debug bitmask around a bit.  Consider yourself warned!
2012-11-16 19:39:29 +00:00
Adrian Chadd
bbdf3df1c4 Make sure the final descriptor in an aggregate has rate control information.
This was broken by me when merging the 802.11n aggregate descriptor chain
setup with the default descriptor chain setup, in preparation for supporting
AR9380 NICs.

The corner case here is quite specific - if you queue an aggregate frame
with >1 frames in it, and the last subframe has only one descriptor making
it up, then that descriptor won't have the rate control information
copied into it. Look at what happens inside ar5416FillTxDesc() if
both firstSeg and lastSeg are set to 1.

Then when ar5416ProcTxDesc() goes to fill out ts_rate based on the
transmit index, it looks at the rate control fields in that descriptor
and dutifully sets it to be 0.

It doesn't happen for non-aggregate frames - if they have one descriptor,
the first descriptor already has rate control info.

I removed the call to ath_hal_setuplasttxdesc() when I migrated the
code to use the "new" style aggregate chain routines from the HAL.
But I missed this particular corner case.

This is a bit inefficient with MIPS boards as it involves a few redundant
writes into non-cachable memory.  I'll chase that up when it matters.

Tested:

 * AR9280 STA mode, TCP iperf traffic
 * Rui Paulo <rpaulo@> first reported this and has verified it on
   his AR9160 based AP.

PR:		kern/173636
2012-11-15 03:00:49 +00:00
Adrian Chadd
5f9fe65d64 Place 'dev.ath.X.debug' back under ATH_DEBUG, rather than ATH_DEBUG_ALQ. 2012-11-13 19:45:13 +00:00
Adrian Chadd
7d9dd2ac96 Add some debugging to try and catch an invalid TX rate (0x0) that is
being reported.
2012-11-13 06:28:57 +00:00
Adrian Chadd
603280386b Correctly fix the 'scan during STA mode' crash. 2012-11-11 21:58:18 +00:00
Adrian Chadd
58c82ec453 Remove this; i incorrectly committed the wrong (debug) changes in my
previous commit.
2012-11-11 21:57:18 +00:00
Adrian Chadd
04cdca73d9 Don't call av_set_tim() if it's NULL.
This happens during a scan in STA mode; any queued data frames will
be power save queued but as there's no TIM in STA mode, it panics.

This was introduced by me when I disabled my driver-aware power save
handling support.
2012-11-11 00:34:10 +00:00
Adrian Chadd
3345c65be0 Correct some rather weird and broken behaviour observed when doing
actual traffic with an AR9380/AR9382/AR9485.

The sample rate control stats would show impossibly large numbers for
"successful packets transmitted."  The number was a tad under 2^^64-1.
So after a bit of digging, I found that the sample rate control code
was making 'tries' turn into a negative number.. and this was because
ts_longretry was too small.

The hardware returns "ts_longretry" at the current rate selection,
not overall for that TX descriptor.  So if you setup four TX rate
scenarios and the second one works, ts_longretry is only set for
the number of attempts at that second rate scenario.  The FreeBSD HAL
code does the correction in ath_hal_proctxdesc() - however, this isn't
possible with EDMA.

EDMA TX completion is done separate from the original TX descriptor.
So the real solution is to split out "find ts_rate and ts_longretry"
from "complete TX descriptor".  Until that's done, put a hack in
the EDMA TX path that uses the rate scenario information in the ath_buf.

Tested: AR9380, AR9382, AR9485 STA mode
2012-11-10 22:37:06 +00:00
Kevin Lo
f78d5b7e8a s/ATH_DEBUG/ATH_DEBUG_ALQ 2012-11-10 15:21:39 +00:00
Kevin Lo
9fc1923565 Fix the build. 2012-11-10 08:34:40 +00:00
Adrian Chadd
a64438faed Fix a very incorrect description. 2012-11-09 01:28:11 +00:00