Commit Graph

1532 Commits

Author SHA1 Message Date
rpaulo
bcc25db7d5 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
66c01d36f3 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
f4c59de78e Use the new ieee80211_tx_complete() function. 2013-08-27 14:39:37 +00:00
adrian
46b70ac9f4 Log the MAC address of the node in question rather than the pointer. 2013-08-17 01:14:28 +00:00
adrian
79db6ff607 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
8946ce2bbe 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
42eb189c98 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
ca3bfcb001 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
ad69138108 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
4537d8ddce 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
01512fbd78 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
cba1418efe 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
7a0e9421a5 Add another comment about WB195 (AR9285+AR3011) when using ASPM. 2013-06-10 20:10:34 +00:00
adrian
d4f88869bd 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
d34155fd92 Add accessor macros for the bluetooth coexistence routines. 2013-06-07 05:18:07 +00:00
adrian
fd875f85f0 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
aa6dbdbade 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
87c3bc4a47 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
ebc6d094af 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
f482ea2896 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
c9d8be05cc 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
1110d62208 Add the combined (mixed) diversity support capability bit for the
AR9285/AR9485.
2013-06-04 02:56:56 +00:00
adrian
bcac128462 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
d46bc8559f 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
f2a8e681b1 Turn the reassociate debug print into a DPRINTF. 2013-05-29 05:10:11 +00:00
adrian
967895b1af Shuffle around the cleanup unpause calls a bit. 2013-05-29 01:40:13 +00:00
adrian
f70201bb2a 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
e1aea355e7 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
c283b0b0ae 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
3fb878f217 Fix build break - the SetCapability calls return HAL_BOOL,
not HAL_STATUS.
2013-05-21 14:28:05 +00:00
adrian
21bb675419 Extend the TXOP enforce capability to support checking whether it's
supported.
2013-05-21 05:51:49 +00:00
adrian
861524b68c Make the HT rate duration calculation work for MCS rates > 15. 2013-05-20 07:10:43 +00:00
adrian
16418fa472 More non-ATH_DEBUG build fixes. 2013-05-19 01:33:17 +00:00
adrian
3feeec31e4 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
83ab6e624a 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
3803b70a8a 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
78ff6ffd7d 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
80dd90c797 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
f671503c18 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
49cc8337ff Dump out the holding buffer descriptor contents and addresses stopping DMA. 2013-05-16 17:45:01 +00:00
adrian
c059ecd485 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
77b65439cb Add ALQ beacon debugging. 2013-05-13 21:18:00 +00:00
adrian
a3b2ceee4e Support sending ATH_ALQ messages with no payload. 2013-05-13 21:17:27 +00:00
adrian
e848dec808 Improve the debugging output - use the MAC address rather than various
pointer values everywhere.
2013-05-13 19:52:35 +00:00
adrian
6bbf566f5d 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
8f11253cd8 Oops, commit the other half of r250606. 2013-05-13 19:02:22 +00:00
adrian
5a3798f699 This lock only protects the rate control state for now, mention this. 2013-05-13 18:57:18 +00:00
adrian
4bd9be4c73 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
4d334b94a5 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
19cabfe6e2 Update the holding buffer locking for EDMA. 2013-05-09 15:57:55 +00:00