Commit Graph

1264 Commits

Author SHA1 Message Date
adrian
f85277a163 Disable this warning debug for now, as I'm now aware of the particular
situation where it's occuring.

Whilst I'm here, flesh out a more descriptive description.
2012-06-14 04:01:25 +00:00
adrian
a65b3dd589 Implement a global (all non-mgmt traffic) TX ath_buf limitation when
ath_start() is called.

This (defaults to 10 frames) gives for a little headway in the TX ath_buf
allocation, so buffer cloning is still possible.

This requires a lot omre experimenting and tuning.

It also doesn't stop a node/TID from consuming all of the available
ath_buf's, especially when the node is going through high packet loss
or only talking at a low TX rate.  It also doesn't stop a paused TID
from taking all of the ath_bufs.  I'll look at fixing that up in subsequent
commits.

PR:	kern/168170
2012-06-14 00:51:53 +00:00
adrian
528dfae9f3 Implement a separate, smaller pool of ath_buf entries for use by management
traffic.

* Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately.
* Create an enum to represent buffer types in the API.
* Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum.
* Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT.
  This may not be very useful.
* Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer
  is a mgmt buffer and should go back onto the mgmt free list.
* Extend 'txagg' to include debugging output for both normal and mgmt txbufs.
* When checking/clearing ATH_BUF_BUSY, do it on both TX pools.

Tested:

* STA mode, with heavy UDP injection via iperf.  This filled the TX queue
  however BARs were still going out successfully.

TODO:

* Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right
  type is being allocated and freed on the appropriate list.  That'd save
  a write operation (to bf->bf_flags) on each buffer alloc/free.

* Test on AP mode, ensure that BAR TX and probe responses go out nicely
  when the main TX queue is filled (eg with paused traffic to a TID,
  awaiting a BAR to complete.)

PR:		kern/168170
2012-06-13 06:57:55 +00:00
adrian
045b5b971c Remove a duplicate definition. 2012-06-13 05:47:24 +00:00
adrian
60c3364556 Oops, return the newly allocated buffer to the queue, not the completed
buffer.

PR:	kern/168170
2012-06-13 05:41:00 +00:00
adrian
0e5e2a4303 Replace the direct sc_txbuf manipulation with a pair of functions.
This is preparation work for having a separate ath_buf queue for
management traffic.

PR:		kern/168170
2012-06-13 05:39:16 +00:00
adrian
1948616051 Fix uninitialised reference.
Noticed by:	John Hay <jhay@meraka.org.za>
2012-06-11 12:26:23 +00:00
adrian
2cecdd81d8 Wrap the whole (software) TX path from ifnet dequeue to software queue
(or direct dispatch) behind the TXQ lock (which, remember, is doubling
as the TID lock too for now.)

This ensures that:

 (a) the sequence number and the CCMP PN allocation is done together;
 (b) overlapping transmit paths don't interleave frames, so we don't
     end up with the original issue that triggered kern/166190.

     Ie, that we don't end up with seqno A, B in thread 1, C, D in
     thread 2, and they being queued to the software queue as "A C D B"
     or similar, leading to the BAW stalls.

This has been tested:

* both STA and AP modes with INVARIANTS and WITNESS;
* TCP and UDP TX;
* both STA->AP and AP->STA.

STA is a Routerstation Pro (single CPU MIPS) and the AP is a dual-core
Centrino.

PR:		kern/166190
2012-06-11 07:44:16 +00:00
adrian
a067a20110 Add another TID lock. 2012-06-11 07:35:24 +00:00
adrian
932f2b787a Make sure the frames are queued to the head of the list, not the tail.
See previous commit.

PR:		kern/166190
2012-06-11 07:31:50 +00:00
adrian
d2da34afea When scheduling frames in an aggregate session, the frames should be
scheduled from the head of the software queue rather than trying to
queue the newly given frame.

This leads to some rather unfortunate out of order (but still valid
as it's inside the BAW) frame TX.

This now:

* Always queues the frame at the end of the software queue;
* Tries to direct dispatch the frame at the head of the software queue,
  to try and fill up the hardware queue.

TODO:

* I should likely try to queue as many frames to the hardware as I can
  at this point, rather than doing one at a time;
* ath_tx_xmit_aggr() may fail and this code assumes that it'll schedule
  the TID.  Otherwise TX may stall.

PR:		kern/166190
2012-06-11 07:29:25 +00:00
adrian
3559a073df Retried frames need to be inserted in the head of the list, not the tail.
This is an unfortunate byproduct of how the routine is used - it's called
with the head frame on the queue, but if the frame is failed, it's inserted
into the tail of the queue.

Because of this, the sequence numbers would get all shuffled around and
the BAW would be bumped past this sequence number, that's now at the
end of the software queue.  Then, whenever it's time for that frame
to be transmitted, it'll be immediately outside of the BAW and TX will
stall until the BAW catches up.

It can also result in all kinds of weird duplicate BAW frames, leading
to hilarious panics.

PR:		kern/166190
2012-06-11 07:15:48 +00:00
adrian
ddabbbd18b Finish undoing the previous commit - this part of the code is no longer
required.

PR:		kern/166190
2012-06-11 07:08:40 +00:00
adrian
97dfa39fc4 Introduce a new lock debug which is specifically for making sure the
_TID_ lock is held.

For now the TID lock is also the TXQ lock. This is just to make sure
that the right TXQ lock is held for the given TID.
2012-06-11 07:06:49 +00:00
adrian
0760025f8f Revert r233227 and followup commits as it breaks CCMP PN replay detection.
This showed up when doing heavy UDP throughput on SMP machines.

The problem with this is because the 802.11 sequence number is being
allocated separately to the CCMP PN replay number (which is assigned
during ieee80211_crypto_encap()).

Under significant throughput (200+ MBps) the TX path would be stressed
enough that frame TX/retry would force sequence number and PN allocation
to be out of order.  So once the frames were reordered via 802.11 seqnos,
the CCMP PN would be far out of order, causing most frames to be discarded
by the receiver.

I've fixed this in some local work by being forced to:

  (a) deal with the issues that lead to the parallel TX causing out of
      order sequence numbers in the first place;
  (b) fix all the packet queuing issues which lead to strange (but mostly
      valid) TX.

I'll begin fixing these in a subsequent commit or five.

PR:		kern/166190
2012-06-11 06:59:28 +00:00
adrian
d958c69a5f Add a new ioctl for ath(4) which returns the aggregate statistics. 2012-06-10 06:42:18 +00:00
adrian
b1336b8d21 Mostly revert previous commit(s). After doing a bunch of local testing,
it turns out that it negatively affects performance.  I'm stil investigating
exactly why deferring the IO causes such negative TCP performance but
doesn't affect UDP preformance.

Leave the ath_tx_kick() change in there however; it's going to be useful
to have that there for if_transmit() work.

PR:		kern/168649
2012-06-05 06:03:55 +00:00
adrian
6dd8c2eb6c Create a function - ath_tx_kick() - which is called where ath_start() is
called to "kick" along TX.

For now, schedule a taskqueue call.

Later on I may go back to the direct call of ath_rx_tasklet() - but for
now, this will do.

I've tested UDP and TCP TX. UDP TX still achieves 240MBit, but TCP
TX gets stuck at around 100MBit or so, instead of the 150MBit it should
be at.  I'll re-test with no ACPI/power/sleep states enabled at startup
and see what effect it has.

This is in preparation for supporting an if_transmit() path, which will
turn ath_tx_kick() into a NUL operation (as there won't be an ifnet
queue to service.)

Tested:
	* AR9280 STA

TODO:
	* test on AR5416, AR9160, AR928x STA/AP modes

PR:		kern/168649
2012-06-05 03:14:49 +00:00
adrian
673d798918 Migrate the TX path to a taskqueue for now, until a better way of
implementing parallel TX and TX/RX completion can be done without
simply abusing long-held locks.

Right now, multiple concurrent ath_start() entries can result in
frames being dequeued out of order.  Well, they're dequeued in order
fine, but if there's any preemption or race between CPUs between:

* removing the frame from the ifnet, and
* calling and runningath_tx_start(), until the frame is placed on a
  software or hardware TXQ

Then although dequeueing the frame is in-order, queueing it to the hardware
may be out of order.

This is solved in a lot of other drivers by just holding a TX lock over
a rather long period of time.  This lets them continue to direct dispatch
without races between dequeue and hardware queue.

Note to observers: if_transmit() doesn't necessarily solve this.
It removes the ifnet from the main path, but the same issue exists if
there's some intermediary queue (eg a bufring, which as an aside also
may pull in ifnet when you're using ALTQ.)

So, until I can sit down and code up a much better way of doing parallel
TX, I'm going to leave the TX path using a deferred taskqueue task.
What I will likely head towards is doing a direct dispatch to hardware
or software via if_transmit(), but it'll require some driver changes to
allow queues to be made without using the really large ath_buf / ath_desc
entries.

TODO:

* Look at how feasible it'll be to just do direct dispatch to
  ath_tx_start() from if_transmit(), avoiding doing _any_ intermediary
  serialisation into a global queue.  This may break ALTQ for example,
  so I have to be delicate.

* It's quite likely that I should break up ath_tx_start() so it
  deposits frames onto the software queues first, and then only fill
  in the 802.11 fields when it's being queued to the hardware.
  That will make the if_transmit() -> software queue path very
  quick and lightweight.

* This has some very bad behaviour when using ACPI and Cx states.
  I'll do some subsequent analysis using KTR and schedgraph and file
  a follow-up PR or two.

PR:		kern/168649
2012-06-04 22:01:12 +00:00
adrian
cd7b4ede6c Add the AR9280 workarounds for PCIe suspend/resume.
These aren't strictly needed at the moment as we're not doing APSM
and forcing the NIC in and out of network sleep.  But, they don't hurt.

Tested:

* AR9280 (mini-PCIe)

Obtained from:	Qualcomm Atheros, Linux ath9k
2012-05-26 01:36:25 +00:00
adrian
7afba97405 Avoid using hard-coded numbers here. 2012-05-26 01:35:11 +00:00
adrian
a8e02da8f8 Remove an unneeded field from ath_buf. 2012-05-26 01:34:36 +00:00
adrian
0d2aec183a Add some AR5416/AR5418 WAR's for power-on and suspend/resume:
* Now that ah_configPCIE is called for both power on and suspend/resume,
  make sure the right bit(s) are cleared and set when suspending and
  resuming.  Specifically:

  + force disable/enable the PCIe PHY upon suspend/resume;
  + reprogram the PCIe WAR register when resuming and upon power-on.

* Add a recipe which powers down any PCIe PHY hardware inside the AR5416
  (which is the PCI variant) to save on power.  I have (currently) no way
  to test exactly how much power is saved, if any.

Tested on:

* AR5416 cardbus - although unfortunately pccard/cbb/cardbus currently
  detaches the NIC upon suspend, I don't think it's a proper test case.

* AR5418 PCIe attached to expresscard - since we're not doing PCIe APSM,
  it's also not likely a full/good test case.

In both instances I went through a handful of suspend/resume cycles and
ensured that the STA vap reassociated correctly.

TODO:

* Setup a laptop to simply sit in a suspend/resume loop, making sure that
  the NIC always correctly comes back;

* Start doing suspend/resume tests with actual traffic going on in the
  background, as I bet this process is all quite racy at the present;

* Test adhoc/hostap mode, just to be completely sure it's working correctly;

* See if I can jury rig an external power source to an AR5416 to test out
  whether ah_disablePCIE() works.

Obtained from:	Qualcomm Atheros
2012-05-25 17:53:57 +00:00
adrian
6361d7f3de * According to the reference code, AR_WA_D3_L1_DISBABLE is bit 14.
* Add some other WAR bits (very usefully described too) in preparation for
  porting over some suspend/resume fixes from ath9k/Atheros.

Obtained from:	Qualcomm Atheros
2012-05-25 16:45:56 +00:00
adrian
d6bb741dfb oops - ath_hal_disablepcie is actually destined for another purpose,
not to disable the PCIe PHY in prepration for reset.

Extend the enablepci method to have a "poweroff" flag, which if equal
to true means the hardware is about to go to sleep.
2012-05-25 05:01:27 +00:00
adrian
be5ba4a1c6 Prepare for improved (read: pcie) suspend/resume support.
* Flesh out the pcie disable method for 11n chips, as they were defaulting
  to the AR5212 (empty) PCIe disable method.

* Add accessor macros for the HAL PCIe enable/disable calls.

* Call disable on ath_suspend()

* Call enable on ath_resume()

NOTE:

* This has nothing to do with the NIC sleep/run state - the NIC still
  will stay in network-run state rather than supporting network-sleep
  state.  This is preparation work for supporting correct suspend/resume
  WARs for the 11n PCIe NICs.

TODO:

* It may be feasible at this point to keep the chip powered down during
  initial probe/attach and only power it up upon the first configure/reset
  pass.  This however would require correct (for values of "correct")
  tracking of the NIC power configuration state from the driver and that
  just isn't attempted at the moment.

Tested:

* AR9280 on my Lenovo T60, but with no suspend/resume pass (yet).
2012-05-25 02:07:59 +00:00
adrian
79fb9d3693 Re-up the TX ath_buf limit from 128 to 512.
I'll have to leave this high for now, until I've done some significant
surgery with how ath_bufs (and descriptors) are handled.

This should significantly cut down on the opportunities for a full TX
queue hanging traffic.  I'll continue making things work though; I'm
mostly doing this for users. :)
2012-05-22 19:50:21 +00:00
adrian
a217e03ba9 Fix up some corner cases with aggregation handling.
I've come across a weird scenario in net80211 where two TX streams will
happily attempt to setup an aggregation session together.
If we're very lucky, it happens concurrently on separate CPUs and the
total lack of locking in the net80211 aggregation code causes this stuff
to race. Badly.

So >1 call would occur to the ath(4) addba start, but only one call would
complete to addba complete or timeout.  The TID would thus stay paused.

The real fix is to implement some proper per-node (or maybe per-TID)
locking in net80211, which then could be leveraged by the ath(4) TX
aggregation code.

Whilst I'm at it, shuffle around the debugging messages a bit.
I like to keep people on their toes.
2012-05-22 06:31:03 +00:00
adrian
8d75cfbaa6 For now, add a quick debugging patch to log when the hw TXQ != the TID/AC. 2012-05-21 22:43:38 +00:00
adrian
36f1ea103b Rename ath_tx_cleanup() -> ath_tx_tid_cleanup() in order to not clash
with a symbol in if_ath.c
2012-05-21 22:39:13 +00:00
adrian
83179ad85b Re-add 'ic' and properly wrap it in the SUPERG macro. 2012-05-21 17:51:26 +00:00
bschmidt
2a516c354f Remove unused variable. 2012-05-20 09:46:48 +00:00
adrian
e1654c32a7 Migrate the per-frame code out from ath_rx_proc() to ath_rx_pkt().
This will (eventually) be used by the EDMA RX path used by the
AR93xx and later NICs.
2012-05-20 06:35:22 +00:00
adrian
7ee37f6fdd Migrate most of the beacon handling functions out to if_ath_beacon.c.
This is also in preparation for supporting AR9300 and later NICs.
2012-05-20 04:14:29 +00:00
adrian
91668b1b5a Migrate the TDMA management functions out of if_ath.c into if_ath_tdma.c.
There's some TX path TDMA code in if_ath_tx.c which should be migrated
out, but first I should likely try and verify/fix/repair the TDMA support
in 9.x and -HEAD.
2012-05-20 02:49:42 +00:00
adrian
677f51d0dd Migrate the bulk of the RX routines out from if_ath.c to if_ath_rx.[ch].
* migrate the rx processing out into if_ath_rx.c
* migrate the TSF functions into if_ath_tsf.h, as inlines

This is in prepration for supporting the EDMA RX routines, required to
support the AR93xx series NICs.

TODO:

* ath_start() shouldn't be private, but it's called as part of
  the RX path. I should likely migrate ath_rx_tasklet() back into
  if_ath.c and then return this to be 'static'.  The RX code really
  shouldn't need to see TX routines (and vice versa.)

* ath_beacon_* should be in if_ath_beacon.[ch].

* ath_tdma_* should be in if_ath_tdma.[ch] ...
2012-05-20 02:05:10 +00:00
adrian
b8ac2f0291 Migrate ath_debug and sc_debug from an int to a uint64_t / QUAD;
add some more BAR debugging logic.

* Change the definition of ath_debug and ath_softc.sc_debug  from
  int to uint64_t;
* Change the relevant sysctls;
* Add a new BAR TX debugging field;
* Use this in if_ath_tx.

This has been tested by using the sysctl program, which happily allows
for fields > 32 bits to be configured.
2012-05-15 23:39:37 +00:00
adrian
eceb1cf926 Handle non-xretry errors the same as xretry errors for now.
Although I _should_ handle the other errors in various ways (specifically
errors like FILT), treating them as having transmitted successfully
is completely wrong.  Here, they'd be counted as successful and the BAW
would be advanced.. but the RX side wouldn't have received them.

The specific errors I've been seeing here are HAL_TXERR_FILT.

This patch does fix the issue - I've tested it using -i 0.001 pings
(enough to start aggregation) and now the behaviour is correct:

* The RX side never sees a "moved window" error, and
* The TX side sends BARs as needed, with the RX side correctly handling
  them.

PR:		kern/167902
2012-05-15 04:55:15 +00:00
adrian
f2b0ca2bf1 Add some empty DFS methods for AR5210/AR5211 for now, if DFS is enabled
but these don't exist, the code panics.

I should really just add or use a DFS HAL capability before doing this,
so the methods wouldn't be needed..
2012-05-09 18:17:01 +00:00
adrian
0803e21ea9 Re-enable this particular DELAY() for now, at least until the
TX and RX PCU stop/drain routines have been thoroughly debugged.

It's also very likely that I should add hooks back up to the
interface glue (if_ath_pci / if_ath_ahb) to do any relevant
bus flushes that are required.  A WMAC DDR flush may be required
for the AR9130 SoC.
2012-05-07 18:30:22 +00:00
adrian
aa1bde9394 Fix a couple of sc_ac2q[] mappings that were using the TID, not the AC.
PR:		kern/167588
2012-05-04 20:31:27 +00:00
adrian
6177587c41 Change the MIB cycle count API to return HAL_BOOL, rather than uint32_t,
to return whether it was successful.

Add placeholder (blank) methods for previous chips, for both it and
the 11n extension channel busy call.
2012-05-01 14:48:51 +00:00
adrian
39e5694deb After thinking about this a bit more, let's not keep statistics per-channel
in the HAL.  That's very memory hungry (32k just for channel statistics)
which would be better served by keeping a summary in the ANI state.

Or, later, keep a survey history in net80211.

So:

* Migrate the ah_chansurvey array to be a single entry, for the current
  channel.
* Change the ioctl interface and ANI code to just reference that.
* Clear the ah_chansurvey array during channel reset, both in the AR5212
  and AR5416 reset path.
2012-04-28 22:03:19 +00:00
adrian
f67b4d4333 Although not strictly needed, quieten a compiler warning by a user. 2012-04-28 18:56:17 +00:00
adrian
0d581e7a85 Extend the ANI code to implement basic channel survey support.
* Always call ar5416GetListenTime()
* Modify ar5416GetListenTime() to:
  + don't update the ANI state if there isn't any ANI state;
  + don't update the channel survey state if there's no active
    channel - just to be paranoid
  + copy the channel survey results into the current sample slot
    based on the current channel; then increment the sample counter
    and sample history counter.
* Modify ar5416GetMIBCyclesPct() to simply return a HAL_SURVEY_SAMPLE,
  rather than a set of percentages.  The ANI code wasn't using the
  percentages anyway.

TODO:

* Create a new function which fetches the survey results periodically
* .. then modify the ANI code to use the pre-fetched values rather than
  fetching them again
* Roll the 11n ext busy function from ar5416_misc.c to update all the
  counters, then do the result calculation
* .. then, modify the MIB counter routine to correctly fetch a snapshot -
  freeze the counters, fetch the values, then reset the counters.
2012-04-28 08:29:46 +00:00
adrian
ab1ec605a6 Fetch the channel survey code from the HAL.
This information is currently not being populated by any of the HAL
modules.
2012-04-28 08:15:40 +00:00
adrian
db8d363ac8 Extend the HAL channel survey statistics:
* include ext_chan_busy;
* include ofdm/cck phy error counts, which aren't yet implemented.
2012-04-28 08:12:51 +00:00
adrian
252b5377f0 Add a comment about this DELAY(), I'm not sure whether it's supposed
to be for a DDR/FIFO flush or something else.
2012-04-28 05:00:47 +00:00
adrian
bd74977b95 Add an AR5416 PCU DMA stop method, as a check for the AR9130 is needed.
The reference driver has a 3ms delay for the AR9130 but I'm not as yet
sure why.  From what I can gather, it's likely waiting for some FIFO
flush to occur.

At some point in the future it may be worthwhile adding a WMAC
FIFO flush here, but that'd require some side-call through to the SoC
DDR flush routines.

Obtained from:	Atheros
2012-04-28 03:07:36 +00:00
adrian
d06eb3218b Remove some of the redundant locking done in the TX completion path,
when checking whether BAR frames need to be checked.
2012-04-26 23:57:24 +00:00
adrian
142e6644f1 Add the BT register definitions for AR9285/AR9287 BT coexistence.
Obtained from:	Linux ath9k
2012-04-26 02:03:16 +00:00
adrian
9b6c12530c Add placeholder methods for WMI command access (USB, perhaps SDIO later)
which will be needed for AR7010 and AR9287 USB access.

The names differ slightly from Linux and Atheros, for the sake of
consistency.

A lot more work is required in order to convert the 11n HAL support to
fully support USB.
2012-04-25 01:42:22 +00:00
adrian
321d5d661d Add a note that explains what the current state of the register byte order
macros are.
2012-04-25 01:24:39 +00:00
adrian
6ad6e04dc4 .. oops. 2012-04-20 22:07:21 +00:00
adrian
9e5483e0b1 "Upgrade" the AR9285 code to support PCI/ART EEPROM on flash.
I've just verified that this boots on an Atheros AP91. I haven't verified
it with traffic though, so YMMV.
2012-04-20 21:56:13 +00:00
adrian
a1620c9905 Stop using the hardware register value byte order swapping for now,
at least until I can root cause what's going on.

The only platform I've seen this on is the AR9220 when attached to
the AR71xx CPUs.  I get immediate PCIe bus errors and all subsequent
accesses cause further MIPS bus exceptions.  I don't have any other
big-endian platforms to test this on.

If I get a chance (or two), I'll try to whack this on a bus analyser
and see exactly what happens.

I'd rather leave this on, especially for slower, embedded platforms.
But the #ifdef hell is something I'm trying to avoid.
2012-04-19 03:26:21 +00:00
adrian
1bc364bf7e Run the fatal proc as a proc, rather than where it currently is.
Otherwise the reset path will sleep, which it can't do in this context.
2012-04-17 06:02:41 +00:00
adrian
69f376da56 Migrate the net80211 TX aggregation state to be from per-AC to per-TID.
TODO:

* Test mwl(4) more thoroughly!

Reviewed by:	bschmidt (for iwn)
2012-04-15 20:29:39 +00:00
adrian
c5f9250e61 Drop this down from 512 to 128 for now.
This may result in a bit of a throughput drop.  However, any throughput
drop at this point should be investigated and root caused, as it's likely
because TX scheduling (all the way down to how preemption, scheduler work,
etc) is happening in a sub-optimal fashion.

This also makes it much more likely to be reloadable on a live machine.
Allocating 5120 TX ath_buf entries via contigmalloc is very unlikely
after a few hours of using X/Chromium.
2012-04-15 19:54:22 +00:00
adrian
3f3580908c Override some default values to work around various issues in the deep,
dirty and murky past.

* Override the default cache line size to be something reasonable if
  it's set to 0.  Some NICs initialise with '0' (eg embedded ones)
  and there are comments in the driver stating that various OSes (eg
  older Linux ones) would incorrectly program things and 0 out this
  register.

* Just default to overriding the latency timer.  Every other driver
  does this.

* Use a default cache line size of 32 bytes.  It should be "reasonable
  enough".

Obtained from:	Linux ath9k, Atheros
2012-04-15 00:04:23 +00:00
adrian
62fe709d3a Both linux ath9k and the reference driver initialises the PLL here
during chip wakeup.

Obtained from:	Linux ath9k, Atheros
2012-04-14 04:40:11 +00:00
adrian
9645923e3b Upgrade ATH_EEPROM_FIRMWARE to a configuration option. 2012-04-13 18:00:48 +00:00
adrian
7f1f1b94c1 Introduce the ability to grab local EEPROM data from the firmware(9)
interface.

* Introduce a device hint, 'eeprom_firmware', which is the name of firmware
  to lookup.
* If the lookup succeeds, take a copy of it and use it as the eeprom data.

This isn't enabled by default - you have to define ATH_EEPROM_FIRMWARE.
I'll add it to the configuration variables in a later commit.

TODO:

* just keep a firmware reference in ath_softc, and remove the need to
  waste the extra memory in having sc_eepromdata be a malloc()ed block.
2012-04-13 08:48:38 +00:00
adrian
b6f2ea08ae Fix the default, non-superg compile.
Pointy-hat-to:	adrian
2012-04-11 02:34:32 +00:00
adrian
f0d73b6741 Fix compilation with IEEE80211_ENABLE_SUPERG defined.
PR:		kern/164951
2012-04-10 19:47:44 +00:00
adrian
c2d174fcfd Convert the flags over to a set of bit flags. 2012-04-10 19:25:43 +00:00
adrian
69b4bd16e0 Blank the aggregate stats whenever the zero ioctl is called. 2012-04-10 07:27:42 +00:00
adrian
ac77a9a5bc Squirrel away SYNC interrupt debugging if it's enabled in the HAL.
Bus errors will show up as various SYNC interrupts which will be passed
back up to ath_intr().
2012-04-10 07:23:37 +00:00
adrian
6c067d61df Revert this for now - it may work for -8 and -9 and -HEAD, but not
"-HEAD driver + net80211 on -9 kernel."

I'll figure this out at some later stage.
2012-04-10 07:16:28 +00:00
adrian
ed6a13cb3e Squirrel away the SYNC interrupt in case we're doing interrupt debugging. 2012-04-10 07:11:33 +00:00
adrian
a5766a62c7 * Since the API changed along the -CURRENT path (december 2011),
add a FreeBSD_version check.  It should work fine for compiling
  on -HEAD, 9.x and 8.x.

* Conditionally compile the 11n options only when 11n is enabled.

The above changes allow the ath(4) driver to compile and run on
8.1-RELEASE (Hi old PC-BSD!) but with the 11n stuff disabled.

I've done a test against the net80211 and tools in 8.1-RELEASE.
The NIC used in testing is the AR2427 in an EEEPC.

Just to be clear - this change is to allow the -HEAD ath/hal/rate
code to run on 9.x _and_ 8.x with no source changes. However,
when running on earlier kernels, it should only be used for legacy
mode. (Don't define ATH_ENABLE_11N.)
2012-04-10 06:25:11 +00:00
adrian
e793af405d After reviewing the mcast/sleep station code a little, undo some brain
damage which I committed when I had less clue about such things.

Don't ever put normal data frames on the mcast software queue.
Just put mcast frames there if needed.

Pass the txq decision into ath_tx_normal_setup(), as we've already made
the decision.  Don't re-do it.

Whilst i'm here, add another random debugging statement.
2012-04-08 00:40:16 +00:00
adrian
1e4ae572e5 Do a dma sync before the descriptors are chained together.
I need to find a better place to do this..
2012-04-07 05:51:43 +00:00
adrian
8b30efff05 Break out the legacy duration and protection code into routines,
call these after rate control selection is done.

The duration/protection code wasn't working - it expected the rix to
be valid.  Unfortunately after I moved the rate control selection into
late in the process, the rix value isn't valid and thus the protection/
duration code would get things wrong.

HT frames are now correctly protected with an RTS and for the AR5416,
this involves having the aggregate frames be limited to 8K.

TODO:

* Fix up the DMA sync to occur just before the frame is queued to the
  hardware.  I'm adjusting the duration here but not doing the DMA
  flush.

* Doubly/triply ensure that the aggregate frames are being limited to
  the correct size, or the AR5416 will get unhappy when TXing RTS-protected
  aggregates.
2012-04-07 05:48:26 +00:00
adrian
960a4d850d As I thought, this is a bad idea. When forming aggregates, the RTS/CTS
stuff and rate control lookup is only done on the first frame.
2012-04-07 05:46:00 +00:00
adrian
89f805c29a Enforce the RTS aggregation limit if RTS/CTS protection is enabled;
if any subframes in an aggregate have different protection from the
first frame in the formed aggregate, don't add that frame to the
aggregate.

This is likely a suboptimal method (I think we'll mostly be OK marking
frames that have seqno's with the same protection as normal data frames)
but I'll just be cautious for now.
2012-04-07 03:22:11 +00:00
adrian
17c1a9e4d5 Store away the RTS aggregate limit from the HAL.
This will be used by some upcoming code to ensure that aggregates
are enforced to be a certain size.  The AR5416 has a limitation on
RTS protected aggregates (8KiB).
2012-04-07 02:51:53 +00:00
adrian
8e4ce17ba2 Remove duplicate txflags field from ath_buf.
rename bf_state.bfs_flags to bf_state.bfs_txflags, as that is what
it effectively is.
2012-04-07 02:01:26 +00:00
adrian
4b2962c0bd Implement BAR TX.
A BAR frame must be transmitted when an frame in an A-MPDU session fails
to transmit - it's retried too often, or it can't be cloned for
re-transmission.  The BAR frame tells the remote side to advance the
left edge of the block-ack window (BAW) to a new value.

In order to do this:

* TX for that particular node/TID must be paused;
* The existing frames in the hardware queue needs to be completed, whether
  they're TXed successfully or otherwise;
* The new left edge of the BAW is then communicated to the remote side
  via a BAR frame;
* Once the BAR frame has been sucessfully TXed, aggregation can resume;
* If the BAR frame can't be successfully TXed, the aggregation session
  is torn down.

This is a first pass that implements the above.  What needs to be done/
tested:

* What happens during say, a channel reset / stuck beacon _and_ BAR
  TX.  It _should_ be correctly buffered and retried once the
  reset has completed.  But if a bgscan occurs (and they shouldn't,
  grr) the BAR frame will be forcibly failed and the aggregation session
  will be torn down.

  Yes, another reason to disable bgscan until I've figured this out.

* There's way too much locking going on here.  I'm going to do a couple
  of further passes of sanitising and refactoring so the (re) locking
  isn't so heavy.  Right now I'm going for correctness, not speed.

* The BAR TX can fail if the hardware TX queue is full.  Since there's
  no "free" space kept for management frames, a full TX queue (from eg
  an iperf test) can race with your ability to allocate ath_buf/mbufs
  and cause issues.  I'll knock this on the head with a subsequent
  commit.

* I need to do some _much_ more thorough testing in hostap mode to ensure
  that many concurrent traffic streams to different end nodes are correctly
  handled.  I'll find and squish whichever bugs show up here.

But, this is an important step to being able to flip on 802.11n by default.
The last issue (besides bug fixes, of course) is HT frame protection and
I'll address that in a subsequent commit.
2012-04-04 23:45:15 +00:00
adrian
7752b3142e Track and optionally log the actual sync interrupt cause.
These are involved in tracking host interface issues (ie, PCI/PCIe/AHB
interface.)
2012-04-04 22:51:50 +00:00
adrian
5f2a4bba47 Disable the HWQ contents upon a TX queue reset, rather than a TX queue flush.
This is designed to assist in figuring out what the hardware state is
when something like a queue hang has occured.
2012-04-04 22:24:11 +00:00
adrian
16c6304ced Now that I've fixed the BAW TX hangs, disable this verbose debugging
again.
2012-04-04 22:22:50 +00:00
adrian
866c0e9fc2 Correctly handle AR_MoreAggr when assembling multi-descriptor final frames.
Linux ath9k doesn't have this issue as it doesn't try queuing multi-
descriptor frames to the hardware.

Before, I was only setting the first and last descriptor in the final
frame correctly - and that was done by accident. The first descriptor in
the last sub-frame was being correctly updated by ath_tx_setds_11n();
the last descriptor in the last sub-frame was being correctly updated
by ath_buf_set_rate(). But both of those are "incorrect".

The correct behaviour is:

* AR_IsAggr is set for all descriptors for all subframes in an aggregate.
* AR_MoreAggr is set for all descriptors for all non-final sub-frames
  in an aggregate.

Ie, all descriptors in the last sub-frame of an aggregate must have this
field set to 0.

I still need to do a couple of extra passes to ensure the pad delimiter
field is being correctly handled in all descriptors in the last sub-frame.
2012-04-04 21:49:49 +00:00
adrian
a544afcdc9 Add a threadid to the ah_decode API.
This adds the current thread ID to each logged register and mark entry,
allowing for easier debugging of concurrent/overlapping NIC operations.
2012-04-04 20:46:20 +00:00
adrian
c754ab5e30 Disable a specific Merlin hardware workaround which may cause hangs on some
PCIe controllers.

Obtained from:	Atheros / Linux
2012-04-04 20:42:32 +00:00
adrian
d8968134ad oops, add a missing lock. 2012-03-29 21:54:19 +00:00
adrian
9cb839a32c Defer the rescheduling of TID -> TXQ frames in some instances.
Right now ath_txq_sched() is mainly called from the TX ath_tx_processq()
routine, which is (mostly) done as part of the taskqueue.  It shouldn't
be called outside the taskqueue.

But now that I'm about to flip back on BAR TX, I'm going to start
stressing the ath_tx_tid_pause() and ath_tx_tid_resume() paths.
What I don't want to have happen is a reschedule of the TID traffic
_during_ the completion of TX frames.

Ideally I'd like to have a way to flag back up to the processing code
that the current hardware queue should be rechecked for software TID
queue frames.  But for now, this should suffice for the BAR TX case.

I may eventually delete this code once I've brought some further
sanity to the general TX queue/completion path.
2012-03-29 17:39:18 +00:00
adrian
06ce35f781 Use the assigned sequence number when checking if a retried packet is
within the BAW.

This regression was introduced in ane earlier commit by me to fix the
BAW seqno allocation-but-not-insertion-into-BAW race.  Since it was only
ever using the to-be allocated sequence number, any frame retries
with the first frame in the BAW still in the software queue would
have constantly failed, as ni_txseqs[tid] would always be outside
the BAW.

TODO:

* Extract out the mostly common code here in the agg and non-agg ADDBA
  case and stuff it into a single function.

PR:		kern/166357
2012-03-26 16:05:19 +00:00
adrian
6abfad5150 Add some more debugging to try and nail down exactly what's going on when
I see traffic stalls.

It turns out that the bug isn't because the first and last frame in the
BAW is in the software queue.  It is more likely that it's because
the first frame in the BAW is still in the software queue and thus there's
no more room to allocate and do subsequent TX.

PR:		kern/166357
2012-03-25 23:50:34 +00:00
adrian
27ff2217e7 Add the new channel width change field to the ath(4) driver.
This is not entirely correct as it simply resets the channel, flushing
whatever is in the TX/RX queue.  This can and will break aggregation
BAW tracking.  But the alternative (HT40 frames being sent with the hardware
in HT20 mode) is even worse.

There's still a small window between the htinfo being received (and the ni_chw
field being updated) which could cause problems.  I'll look at fleshing this
out in follow-up commits.

PR:		kern/166286
2012-03-25 03:14:31 +00:00
adrian
0167a18d8f Add some further debugging to try and aid tracking down what the state of
things were just before a full software queue is drained.
2012-03-22 21:48:36 +00:00
adrian
a791b92eab Sprinkle some style(9) things around. 2012-03-22 21:47:14 +00:00
adrian
f4dc64af6e Delay sequence number allocation for A-MPDU until just before the frame
is queued to the hardware.

Because multiple concurrent paths can execute ath_start(), multiple
concurrent paths can push frames into the software/hardware TX queue
and since preemption/interrupting can occur, there's the possibility
that a gap in time will occur between allocating the sequence number
and queuing it to the hardware.

Because of this, it's possible that a thread will have allocated a
sequence number and then be preempted by another thread doing the same.
If the second thread sneaks the frame into the BAW, the (earlier) sequence
number of the first frame will be now outside the BAW and will result
in the frame being constantly re-added to the tail of the queue.
There it will live until the sequence numbers cycle around again.

This also creates a hole in the RX BAW tracking which can also cause
issues.

This patch delays the sequence number allocation to occur only just before
the frame is going to be added to the BAW.  I've been wanting to do this
anyway as part of a general code tidyup but I've not gotten around to it.
This fixes the PR.

However, it still makes it quite difficult to try and ensure in-order
queuing and dequeuing of frames. Since multiple copies of ath_start()
can be run at the same time (eg one TXing process thread, one TX completion
task/one RX task) the driver may end up having frames dequeued and pushed
into the hardware slightly/occasionally out of order.

And, to make matters more annoying, net80211 may have the same behaviour -
in the non-aggregation case, the TX code allocates sequence numbers
before it's thrown to the driver.  I'll open another PR to investigate
this and potentially introduce some kind of final-pass TX serialisation
before frames are thrown to the hardware.  It's also very likely worthwhile
adding some debugging code into ath(4) and net80211 to catch when/if this
does occur.

PR:		kern/166190
2012-03-20 04:50:25 +00:00
adrian
1a24a89db9 Fix a couple of debugging outputs.
* printf -> device_printf
* print the buffer pointer and sequence number for any buffer that wasn't
  correctly tidied up before it was freed.  This is to aid in some
  current SMP TX debugging stalls.

PR:		kern/166190
2012-03-16 23:24:27 +00:00
adrian
c104224e00 Add a dependency on ALQ if IEEE80211_ALQ and/or AH_DEBUG_ALQ is included. 2012-03-16 23:12:40 +00:00
adrian
a23302347c Stick the if_drv_flags access (check and modify) behind the ifq lock.
Although access to the flags to check/set OACTIVE is racy due to how
the default if_start() function works, this should remove any races
with read/modify/write between threads.
2012-03-10 20:09:02 +00:00
adrian
2251c534df Fix a panic introduced in a previous commit - non-beaconing modes (eg STA)
don't setup the avp mcast queue.

This is a bit annoying though - it turns out the mcast queue isn't
initialised for STA mode but it's then touched to see whether anything
is in it.  That should be fixed in a subsequent commit.

Noticed by:	gperez@entel.upc.edu
PR:		kern/165895
2012-03-10 19:58:23 +00:00
adrian
baaae4c089 Don't flood the cabq/mcastq with frames.
In a very noisy 2.4GHz environment (with HT/40 enabled, making it worse)
I saw the following occur:

* the air was considered "busy" a lot of the time;
* the cabq time is quite short due to staggered beacons being enabled;
* it just wasn't able to keep up TX'ing CABQ frames;
* .. and the cabq would swallow up all the TX ath_buf's.

This patch introduces a twiddle which allows the maximum cabq depth to be
set, forcing further frames to be dropped.

It defaults to the TX buffer count at the moment, so the default behaviour
isn't changed.

I've also started fleshing out a similar setup for the data path, so
it doesn't swallow up all the available TX buffers and preventing management
frames (such as ADDBA) out.

PR:		kern/165895
2012-03-10 04:14:04 +00:00
adrian
5ccebb7a33 Document that we may end up with some suboptimal handling of data
frames with stations in power saving mode.

I'm not (yet) sure how to handle TX'ing aggregates frames to stations
that are in power saving mode, or whether that's even a feasible thing
to do. So in order to (mostly) not forget, leave a couple of comments
in the code.

The code presently assumes that the aggregation TID state for an ath_node
is locked not by the ath_node lock or a node+TID lock, but behind the
hardware queue said TID maps to.  This assumption is going to be
incorrect for stations in power saving mode as we'll be TX'ing frames
on the multicast queue.

In any case, I'm afraid its a "later problem". :/
2012-03-09 22:58:34 +00:00
adrian
fe40fdbb98 Should the mcast queue be locked here? In case more multicast traffic
comes along?

This commit was brought to you via an Atheros AR5210, associated to an 3x3
HT40 11na access point.  Yes, this driver still works with it.
2012-03-09 22:41:09 +00:00
adrian
59c041e360 Insert extra paranoia into the ath(4) driver.
This function must be called with both the source and destination TXQs
locked or things will get hairy.

I added this as part of some debugging in a PR but it turned out to not
be the cause.  I still think it's -correct- so, here it is.
2012-03-09 08:36:30 +00:00
adrian
f9172f43af Correctly initialise the TXQ link pointer to the last descriptor in
the last buffer in the list.

The current behaviour (due to me, so pointy hat is firmly on my head here)
was incorrect - it was setting the link pointer to the last descriptor
of the _first_ buffer in the TXQ.  Instead, it should have set it to the
last descriptor in the _last_ buffer in the TXQ.

This showed up as occasional TX stalls with frames in the TXQ but no
TX progress being made.  Further inspection showed the TXQ looked like
it contained multiple "lists" of frames - there'd be a list of correct
frames, then a NULL link pointer, but there'd be a next buffer in the
list.

Since this code is only called upon an interface reset, it's likely
this only began showing up when I started doing stress testing
in environments which annoy the radios enough to cause lockups.

I've not yet any TX stalls with this patch applied.

PR:		kern/165866
2012-03-08 23:53:38 +00:00
adrian
aa727b1f0f Wrap another ATH_LOCK around the scanning flag.
PR:		kern/163318
2012-03-02 03:11:53 +00:00
adrian
9d9d3e6003 Wrap the scan code state change stuff behind ATH_LOCK and the PCU fiddling
behind the PCU lock.

sc_scanning is being checked without ATH_LOCK behind held and could
in theory run from multiple threads.
2012-03-02 02:57:10 +00:00
gavin
0104789850 Correct capitalization of "Hz" in user-visible text (manpages, printf(),
etc).

MFC after:	3 days
2012-02-28 13:19:34 +00:00
adrian
342a7804fb Add in some debugging code to check whether the current rate table has
been bait-and-switched from the rate control code.

This will avoid the panic that I saw and will avoid sending invalid rates
(eg 11a/11g OFDM rates when in 11b, on 11b-only NICs (AR5211)) where the
rate table is not "big".

It also will point out situations where this occurs for the 11n NICs
which will have sufficiently large rate tables that "invalid rix" doesn't
occur.

I'll try to follow this up with a commit that adds a current operating mode
check. The "rix" is only relevant to the current operating mode and rate
table.

PR:	kern/165475
2012-02-26 06:04:44 +00:00
adrian
bf0a7194e7 Attempt to further fix some of the concurrency/reset issues that occur.
* ath_reset() is being called in softclock context, which may have the
  thing sleep on a lock.  To avoid this, since we really _shouldn't_
  be sleeping on any locks, break out the no-loss reset path into a tasklet
  and call that from:

  + ath_calibrate()
  + ath_watchdog()

  This has the added advantage that it'll end up also doing the frame
  RX cleanup from within the taskqueue context, rather than the softclock
  context.

* Shuffle around the taskqueue_block() call to be before we grab the lock
  and disable interrupts.

  The trouble here is that taskqueue_block() doesn't block currently
  queued (but not yet running) tasks so calling it doesn't guarantee
  no further tasks (that weren't running on _A_ CPU at the time of this
  call) will complete.  Calling taskqueue_drain() on these tasks won't
  work because if any _other_ thread calls taskqueue_enqueue() for whatever
  reason, everything gets very angry and stops working.

  This slightly changes the race condition enough to let ath_rx_tasklet()
  run before we try disabling it, and thus quietens the warnings a bit.

  The (more) true solution will be doing something like the following:

  * having a taskqueue_blocked mask in ath_softc;
  * having an interrupt_blocked mask in ath_softc;
  * only calling taskqueue_drain() on each individual task _after_ the
    lock has been acquired - that way no further tasklet scheduling
    is going to occur.
  * Then once the tasks have been blocked _and_ the interrupt has been
    disabled, call taskqueue_drain() on each, ensuring that anything
    that _was_ scheduled or running is removed.

  The trouble is if something calls taskqueue_enqueue() on a task
  after taskqueue_blocked() has been called but BEFORE taskqueue_drain()
  has been called, ta_pending will be set to 1 and taskqueue_drain()
  will sit there stuck in msleep() until you hard-kill the machine.

PR: kern/165382
PR: kern/165220
2012-02-25 19:12:54 +00:00
adrian
8c1fe31ca0 Use the passed-in channel rather than ic->ic_curchan.
I'm not sure _why_ the ic is NULL here, but I've seen it occasionally do
this after I've been tinkering with things for a while.  It ends up
crashing in a call to ath_chan_set() via the net80211 scan code and scan
task.
2012-02-23 08:32:54 +00:00
adrian
262a202382 Break out the radar code into a separate source file.
This mirrors the internal HAL organisation and reduces the differences
between the HAL codebases slightly.

Obtained from:	Atheros
2012-02-20 03:07:07 +00:00
adrian
c1367aa3f1 Try to ensure that ieee80211_newstate() and the vap_newstate methods
hold the lock.

This is part of my series of work to try and capture when net80211
locking isn't.

ObNote: it'd be nice to be able to mark a lock as "assert if the lock
is dropped", so I could capture functions which decide that dropping
and reacquiring the lock is a good idea (without re-checking the
sanity of the state protected by the lock.)
2012-02-18 09:18:06 +00:00
adrian
7580cb4608 Fix the return type.
Submitted by:	arundel
Found by:	clang/llvm
2012-02-17 08:45:08 +00:00
adrian
0f8150f67b Enforce some consistent ordering and handling of interrupt disable/enable
with RX/TX halting.

* Always disable/enable interrupts during a channel change, just to simply
  things.

* Ensure that the ath taskqueue has completed and is paused before
  continuing.

This dramatically reduces the instances of overlapping RX and reset
conditions.

PR:	kern/165220
2012-02-17 03:46:38 +00:00
adrian
1871433d24 Begin breaking out the txrx stop code into a locked and unlocked variant.
PR:	kern/165220
2012-02-17 03:23:01 +00:00
adrian
269e055ebb Fix the usefir128 config bit flipping. 2012-02-14 20:06:28 +00:00
adrian
3713a7972e Improve the radar register config API.
* Fix the "enabled" flag to actually reflect whether radar detection is
  enabled or not.
* Add flags for the relstep/relpwr checks.
2012-02-14 20:05:28 +00:00
adrian
635374749a Attempt to address some potential vap->iv_bss race conditions.
There are unfortunately a number of situations where vap->iv_bss is changed
or freed by some code in net80211.  Because multiple threads can concurrently
be doing work (and the vap->iv_bss access isn't at all done behind any kind
of lock), it's quite possible that:

* a change will occur in one thread - eg, by a call through
  ieee80211_sta_join1();
* a state change occurs in another thread - eg an RX is scheduled
  in the ath tasklet and it calls ieee80211_input_mimo_all(), which
  does dereference vap->iv_bss;
* these two executing concurrently, causing things to explode.

Another instance is ath_beacon_alloc() which takes an ieee80211_node *.
It's called with the vap->iv_bss node from ath_newstate(). If the node has
changed in the meantime (say it's been freed elsewhere) the reference
that it grabbed _before_ refcounting it may be stale.

I would _prefer_ that these sorts of things were serialised somewhere but
that may be a bit much to ask.  Instead, the best we can (currently) hope
is that the underlying bss node is still (somewhat) valid.

There is a related PR (kern/164382) described by the first case above.
That should be fixed by properly serialising the RX path and reset path
so an RX can't occur at the same time as the vap free/shutdown path.

This is inspired by some related fixes in r212127.

PR: kern/165060
2012-02-13 00:28:41 +00:00
adrian
01d6cc11bb Enforce the hardware chainmask when allowing the user to override the
chainmask.

This way a disabled radio chain can't be enabled by a user.
2012-02-10 10:10:41 +00:00
adrian
9ad77cd30e .. oops, use the right chainmask. 2012-02-10 10:09:16 +00:00
adrian
b18b86a306 Add in a new driver feature to allow the TX and RX chainmask to be
overridden at attach time.

Some 802.11n NICs may only have one physical antenna connected.
The radios will be very upset if you try enabling radios which aren't
connected to antennas.

This allows hints to override the TX and RX chainmask.

These hints are:

hint.ath.X.rx_chainmask
hint.ath.X.tx_chainmask

They can be set at either boot time or in kenv before the module is loaded.

This and the previous HAL commit were sponsored in late 2011 by Hobnob, Inc.

Sponsored by:	Hobnob, Inc.
2012-02-10 10:01:09 +00:00
adrian
fac2dffabb Extend the HAL code to allow the RX and TX chainmask to be overridden
by capabilities.

Add an ar5416SetCapability() function, which contains logic to override
the chainmask and update the relevant stream.

This is designed to be called after the attach function, which presets
the TX/RX chainmask and stream.

TODO: check the chainmask against the hardware chainmask so non-existing
chains aren't enabled.
2012-02-10 09:58:20 +00:00
adrian
021c66f70f Contribute some example code which demonstrates how to initialise the
radar parameters for the AR5416 and later NICs.

These parameters have been tested on the following NICs:

* AR5416
* AR9160
* AR9220
* AR9280

And yes, these will return radar pulse parameters and (for AR9160 and later)
radar FFT information as PHY errors.

This is again not enough to do radar detection, it's just here to faciliate
development and validation of radar detection algorithms.

The (pulse, not FFT) decoding code for AR5212, AR5416 and later NICs exist
in the HAL.

This code is disabled for now as generating radar PHY errors can quickly
cause issues in busy environment.s  Some further debugging of the RX path
is needed.

Finally, these parameters are likely not useful for the AR5212 era NICs.
The madwifi-dfs branch should have suitable example parameters for the
11a era NICs.
2012-02-06 20:23:21 +00:00
adrian
9b7841536b Support AR9281/AR5B91 - a 1x2 stream device based on the AR9280.
* Override the TX/RX stream count if the EEPROM reports a single RX or
  TX stream, rather than assuming the device will always be a 2x2 strea
  device.

* For AR9280 devices, don't hard-code 2x2 stream.  Instead, allow the
  ar5416FillCapabilityInfo() routine to correctly determine things.

The latter should be done for all 11n chips now that
ar5416FillCapabilityInfo() will set the TX/RX stream count based on the
active TX/RX chainmask in the EEPROM.

Thanks to Maciej Milewski for donating some AR9281 NICs to me for
testing.
2012-01-31 22:31:16 +00:00
adrian
1a819ae84f Correctly fetch the TX/RX stream count from the HAL.
Pointy hat to: me
2012-01-31 22:27:35 +00:00
adrian
da7d786fd4 Radar API related fixes.
* For legacy NICs, the combined RSSI should be used.
  For earlier AR5416 NICs, use control chain 0 RSSI rather than combined
  RSSI.
  For AR5416 > version 2.1, use the combined RSSI again.

* Add in a missing AR5212 HAL method (get11nextbusy) which may be called
  by radar code.

This serves no functional change for what's currently in FreeBSD.
2012-01-30 23:07:27 +00:00
adrian
921264fd36 Oops, commit a missing implementation change.
Whilst I'm here, add a comment about what would happen in this function
if hypothetically you had a radar pattern matching detector written.
2012-01-28 22:24:59 +00:00
adrian
16c84c6bf0 Change the prototype so the radar enable can fail. 2012-01-28 21:44:42 +00:00
adrian
59383c87dd Two changes from my DFS work:
* Grab the net80211com lock when calling ieee80211_dfs_notify_radar().
* Use the tsf extend function to turn the 64 bit base TSF into a per-
  frame 64 bit TSF.  This will improve radiotap logging (which will
  now have a (more) correct per-frame TSF, rather then the single TSF64
  value read at the beginning of ath_rx_proc().
2012-01-28 21:37:33 +00:00
adrian
6d7f67ee9f Add some node debugging which has helped me track down which particular
concurrent vap->iv_bss free issues have been occuring.
2012-01-26 07:03:30 +00:00
adrian
36eed81887 Fix up some style(9) indenting and reorganise some of the hal methods.
There should be no functional change due to this commit.
2012-01-24 06:12:48 +00:00
adrian
4cdf3841ed Add a missing HAL method macro. I'm using this as part of some personal
DFS radar stuff.
2012-01-24 06:07:05 +00:00
adrian
334291414b Break out the "memory" EEPROM data read method from being AR9130 specific
to being more generic.

Other embedded SoCs also throw the configuration/PCI register
info into flash.

For now I'm just hard-coding the AR9280 option (for on-board AR9220's on
AP94 and commercial designs (eg D-Link DIR-825.))

TODO:

* Figure out how to support it for all 11n SoC NICs by doing it in
  ar5416InitState();
* Don't hard-code the EEPROM size - add another field which is set
  by the relevant chip initialisation code.
* 'owl_eep_start_loc' may need to be overridden in some cases to 0x0.
  I need to do some further digging.
2012-01-15 19:22:34 +00:00
adrian
56029d49c5 Re-enable the PHY radar error frames if sc_dodfs is set.
This was messing up a local port of the atheros reference radar detection
code; I'll fix the port instead.
2012-01-11 00:18:33 +00:00
adrian
ac93e4797d style(9) changes. This shouldn't change functionality. 2012-01-11 00:16:44 +00:00
adrian
bb6e0c3939 .. the AR5416 HAL code touches the MIMO parts in HAL_CHANNEL,
so this is also needed.

Pointed out by:	bz
2012-01-07 20:23:05 +00:00
adrian
9fdf403f85 Commit a temporary workaround for people who are building kernels
where they've disabled all the wireless devices/framework.

This is just a build workaround. If you're actively using wireless,
you must still define AH_SUPPORT_AR5416 as I'm not sure what else
will break!

The real solution is to make the module build depend if AH_SUPPORT_AR5416
is defined, as well as make the 11n code in if_ath_tx.c and if_ath_tx_ht.c
completely optional (maybe depend upon ATH_SUPPORT_11N.)
2012-01-07 20:13:55 +00:00
adrian
7a175427ee If frames are dumped out of the queue, let's at least see what they are.
This shows that the majority of the weird traffic I see here are probe
frames that haven't been sent out, but I can also trigger this condition
by doing ICMP w/ -i 0.3 - enough to trigger the TX during actual scanning,
but not fast enough to stop scanning from occuring.

PR:		kern/163689
2012-01-01 01:08:51 +00:00
dim
b8f81a9070 Reapply r228785 now it has been tested by Adrian. Also add comments
with the old AR_SCR_SLE_XXX values, with a short explanation why they
were changed.

Reviewed by:	adrian
MFC after:	1 week
2011-12-30 02:58:37 +00:00
adrian
cff3739e21 AR5416 has 14 GPIO pins, from 0->13. 2011-12-26 08:21:29 +00:00
adrian
5c14f25447 Since the only thing with a mux is the AR5416 and later, and we're now
doing split software/hardware LED configuration, we can now simply
treat "softled" as an "output" mux type.

This works fine on this DWA-552. Previous generation (pre-11n NICs) don't
have a GPIO mux - only input/output configuration - so they ignore this
field.
2011-12-26 07:48:29 +00:00
adrian
41ae7c33b3 Flesh out configurable hardware based LED blinking.
The hardware (MAC) LED blinking involves a few things:

* Selecting which GPIO pins map to the MAC "power" and "network" lines;
* Configuring the MAC LED state (associated, scanning, idle);
* Configuring the MAC LED blinking type and speed.

The AR5416 HAL configures the normal blinking setup - ie, blink rate based
on TX/RX throughput.  The default AR5212 HAL doesn't program in any
specific blinking type, but the default of 0 is the same.

This code introduces a few things:

* The hardware led override is configured via sysctl 'hardled';
* The MAC network and power LED GPIO lines can be set, or left at -1
  if needed.  This is intended to allow only one of the hardware MUX
  entries to be configured (eg for PCIe cards which only have one LED
  exposed.)

TODO:

* For AR2417, the software LED blinking involves software blinking the
  Network LED.  For the AR5416 and later, this can just be configured
  as a GPIO output line.  I'll chase that up with a subsequent commit.

* Add another software LED blink for "Link", separate from "activity",
  which blinks based on the association state.  This would make my
  D-Link DWA-552 have consistent and useful LED behaviour (as they're
  marked "Link" and "Activity."

* Don't expose the hardware LED override unless it's an AR5416 or later,
  as the previous generation hardware doesn't have this multiplexing
  setup.
2011-12-26 07:47:05 +00:00
adrian
122e4872cc Setup the initial LED state on attach and resume.
Some of the NICs I have here power up with the LEDs blinking, which is
incorrect. The blinking should only occur when the NIC is attempting
to associate.

* On powerup, set the state to HAL_LED_INIT, which turns on the "Power" MAC
  LED but leaves the "Network" MAC LED the way it is.

* On resume, also init it to HAL_LED_INIT unless in station mode, where
  it's forced to HAL_LED_RUN. Hopefully the net80211 state machine will
  call newstate() at some point, which will refiddle the LEDs.

I've tested this on a handful of 11n and pre-11n NICs. The blinking
behaviour is slightly more sensible now.
2011-12-26 06:25:12 +00:00
adrian
137bb4966c Update the hardware LED blinking code to do something useful rather than
relying on what the register defaults are.

This forces the blink mode to be proportional to the TX and RX frames
which match the RX filter.

This (along with a few tweaks to if_ath_led.c to configure the correct
GPIO pins) allows my DWA-552 AR5416 NIC to blink the LEDs in a useful
fashion, however those LEDs are marked "Link" and "Act(ivity)", which
don't really map well to the "power" / "network" LED interface which
the MAC provides. Some further tinkering is needed to see what other
useful operating modes are possible.
2011-12-26 06:07:21 +00:00
adrian
96b06a4162 Refactor out the software LED config code into a common function, called
ath_led_config().

The eventual aim is to have both software and hardware based LED
configuration done here.
2011-12-26 05:46:22 +00:00
adrian
b907af0d1a First pass of LED related code changes.
Migrate the LED code out of if_ath.c and into if_ath_led.c.
These routines are _all_ software based LED blinking.
2011-12-26 05:37:09 +00:00
adrian
8662cd3275 Do a quick style(9) pass of some of the code introduced with 802.11n
support.
2011-12-26 05:26:35 +00:00
adrian
557be54d63 Disable the code which hard-sets the LEDs on. This prevents the LED
state from correctly updating things.

The reference driver directly enables/disables the LED state as required,
rather than nailing it up like it currently is.  That'll have to come
later by adding some further HAL methods.

Obtained from:	Atheros
2011-12-23 09:09:10 +00:00
adrian
d39ac0cc90 Port over some more GPIO fixes from the atheros reference HAL.
* Bring the AR5416 GPIO mux mask code in line with the code from the
  HAL.

* Add HAL_DEBUG_GPIO debugging statements, to track what's going on.

* Add Kiwi GPIO specific changes for reading values back.

Obtained from:	Atheros
2011-12-23 08:53:22 +00:00
adrian
9209d4cfb8 Port over some GPIO and LED fixes.
* As a preparation for AR9287 GPIO support, add in the AR9287 GPIO mask.
* Fix the association mask values; these are post-shift values but were
  being shifted in twice. This resulted in some garbage being written
  in the wrong place and the link LED (at least on my d-link AR5416
  NIC) giving totally incorrect blink patterns.
2011-12-23 08:32:53 +00:00
adrian
e268c964fd Remove unused #define's.
Pointy hat to: adrian, for not properly reading things when he copied
  ar9285.h to ar9287.h.
2011-12-23 04:05:39 +00:00
adrian
9ae4b343e4 Rework this ugly mess that tries to handle reset serialisation.
Some users were reporting concurrent resets _were_ occuring - ie,
either two ath_reset()s ran at the same time (likely one on each CPU)
or ath_reset() versus ath_chan_change().

Instead, this now tries to grab the serialisation semaphore and will
pause() for a while if it fails. It will always eventually succeed though
and will log an error if it hits the recursion situation.

All of this stuff needs to die a horrible death at some point and be
replaced with a properly serialising method of programming this stuff
(eg using the net80211 taskqueue for all of this stuff.) The trouble
is figuring out how to handle the concurrent ioctl() based things without
introducing more LORs (which is another reason why I haven't just wrapped
all of this stuff in large, long-lived locks, a-la what Linux can get
away with.)

MFC after:	Absolutely, positively never.
2011-12-23 03:59:49 +00:00
adrian
a2b2712980 Make some more of the 11n specific code conditional.
This doesn't fix compilation w/out AH_SUPPORT_AR5416 as all of the software
aggregation support in if_ath_tx.c and 11n code in if_ath_tx_ht.c touches
the 11n specific fields. I'll work on that later.
2011-12-23 02:40:35 +00:00
adrian
606dec5914 Add a temporary debugging statement in order to try and identify what's
going on with the occasional garbage rs_antenna field reported by AR9285
users.

I've discovered that the 11n NICs only fill out the entire RX status
descriptor on the final descriptor in an aggregate. Some of the fields
(notably RSSI) are complete nonsense for A-MPDU subframes. This may
be another example of this.

The driver doesn't currently toss out statistics for non-final aggregate
frames. It's likely that this should be done.

If any users hit this particular debugging message they should report it
immediately to freebsd-wireless@freebsd.org - please ensure you have
ATH_DEBUG enabled so it prints out the full receive descriptor.

PR:		kern/163312
2011-12-23 02:21:22 +00:00
adrian
a0cdeafbe7 Use the correct types when calling the decompression mask function.
There's currently no public code which uses this feature and the
current reference driver doesn't enable this feature at all.
It's possible it was used by a previous version of the driver and
that indeed it should return HAL_STATUS; but at this point I'm
happy to require that they complain and submit a patch.

This was found by LLVM compile-time type checking.

Submitted by:	dim
2011-12-22 21:54:53 +00:00
dim
1034fcaca8 Revert r228786. We'll need to work around the warnings in another way.
Requested by:	adrian
MFC after:	1 week
2011-12-22 14:09:08 +00:00
dim
28169e3faa Revert r228785. We'll need to work around the warnings in another way.
Requested by:	adrian
MFC after:	1 week
2011-12-22 13:47:36 +00:00
dim
f2ee53d6c6 Fix enum conversion problems in sys/dev/ath/ath_hal/ar5212/ar5212_misc.c
and sys/dev/ath/ath_hal/ar5416/ar5416_misc.c:

sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:577:24: warning: implicit conversion from enumeration type 'HAL_STATUS' to different enumeration type 'HAL_BOOL' [-Wconversion]
                return HAL_EINVAL;
                ~~~~~~ ^~~~~~~~~~

and:

sys/dev/ath/ath_hal/ar5416/ar5416_misc.c:164:9: warning: implicit conversion from enumeration type 'HAL_STATUS' to different enumeration type 'HAL_BOOL' [-Wconversion]
        return HAL_OK;
        ~~~~~~ ^~~~~~

In both cases, enums HAL_BOOL and HAL_STATUS are mixed up.

MFC after: 1 week
2011-12-21 17:36:45 +00:00
dim
c15a655c3d Fix shift overflow problem in sys/dev/ath/ath_hal/ar5210/ar5210_power.c
and sys/dev/ath/ath_hal/ar5211/ar5211_power.c:

sys/dev/ath/ath_hal/ar5210/ar5210_power.c:36:3: warning: signed shift result (0x200000000) requires 35 bits to represent, but 'int' only has 32 bits [-Wshift-overflow]
                OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE, AR_SCR_SLE_ALLOW);
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sys/dev/ath/ath_hal/ah_internal.h:472:42: note: expanded from:
                (OS_REG_READ(_a, _r) &~ (_f)) | (((_v) << _f##_S) & (_f)))
                                                       ^
sys/dev/ath/ah_osdep.h:127:49: note: expanded from:
            (bus_space_handle_t)(_ah)->ah_sh, (_reg), (_val))
                                                       ^~~~

The AR_SCR_SLE_{WAKE,SLP,NORM} values are pre-shifted in ar5210reg.h and
ar5211reg.h, while they should be unshifted, like in ar5212reg.h.  Then,
when the OS_REG_RMW_FIELD() macro shifts them again, the values will
overflow, becoming effectively zero.

MFC after: 1 week
2011-12-21 17:16:43 +00:00
bschmidt
49344f6037 Fix some net80211 enum nits:
- ic_vap_create() uses an ieee80211_opmode argument
- ieee80211_rate2media() takes an ieee80211_phymode argument
- ieee80211_plcp2rate() takes an ieee80211_phytype argument
- cast to enum ieee80211_protmode and ieee80211_roamingmode to silence
  compiler warnings

Submitted by:	arundel@
2011-12-17 10:23:17 +00:00
adrian
7c11417460 Add the 11n chipset RF frontends to the linker set, even though they're not
attached this way.

The AR5212 based NICs have a variety of RF frontends, so there's a linker set
which the AR5212 attach routine calls. The same framework is used for the
AR5416 and later but as there's a fixed RF frontend for each 11n NIC, it
is just directly attached.

However in the case of compiling a cut down HAL (eg _just_ AR9130 WMAC support),
the linker set ends up being empty and this causes the compile to fail.

So this is just a workaround for that - it means those users who wish an 11n
only HAL can compile the 11n chipsets and RF frontend they need, and just
"ath_ar5212" for the AR5212/AR5416 common code, and it'll just work.

Sponsored by:	Hobnob, Inc.
2011-12-15 00:59:11 +00:00
adrian
1d2f1def3e Print out the radio RF version at startup, so I can better see which
RF frontend versions people have when they submit problem reports.

Sponsored by:	Hobnob, Inc.
2011-12-15 00:55:27 +00:00
adrian
cdcb2e87c5 Use the correct RF version probe routine.
Obtained from:	Atheros
Sponsored by:	Hobnob, Inc.
2011-12-15 00:54:11 +00:00
adrian
c63bdaa471 Re-lock the ath lock after ath_reset() has been called.
The calibrate callout is done with the sc lock held.

This only showed up when using an older NIC (AR5212) whose
radio/phy requires the rfgain adjustment.

Pointy-hat-to:	adrian
Sponsored by:	Hobnob, Inc.
2011-11-23 07:12:26 +00:00
adrian
daf0131aaf Flesh out the TX aggregation completion statistics.
* Failall is now named just that.
* Add TX ok and TX fail, for aggregate frame sub-frames.

This will break athstats; a followup commit wil resolve this.

Sponsored by:	Hobnob, Inc.
2011-11-23 05:00:25 +00:00
adrian
e8ee756732 Use the correct lock when calling msleep().
This fixes panics that users have been seeing when operating in station mode,
where the interface undergoes a lot more resets then in hostap mode (ie whilst
doing channel scanning.)

Reported by:	arundel, wblock@wonkity.com
Sponsored by:	Hobnob, Inc.
2011-11-21 22:57:28 +00:00
adrian
08ecf874bb Fix some whitespace pollution. 2011-11-21 21:59:01 +00:00
adrian
1fa90aaeee Add some (totally untested!) code to correctly set the RF half/quarter
mode configuration registers. This is apparently required for correct
behaviour, but also requires the chip to actually officially support it.

Sponsored by:	Hobnob, Inc.
2011-11-19 21:12:35 +00:00
adrian
3a882beede Begin breaking apart the receive setup/stop path in preparation for more
"correct" handling of frames in the RX pending queue during interface
transitions.

* ath_stoprecv() doesn't blank out the descriptor list - that's what
  ath_startrecv() does. So, change a comment to reflect that.

* ath_stoprecv() does include a large (3ms) delay to let pending DMA
  complete. However, I'm under the impression that the stopdma hal
  method does check for a bit in the PCU to indicate DMA has stopped.
  So, to help with fast abort and restart, modify ath_stoprecv() to take
  a flag which indicates whether this is needed.

* Modify the uses of ath_stoprecv() to pass in a flag to support the
  existing behaviour (ie, do the delay.)

* Remove some duplicate PCU teardown code (which wasn't shutting down DMA,
  so it wasn't entirely correct..) and replace it with a call to
  ath_stoprecv(sc, 0) - which disables the DELAY call.

The upshoot of this is now channel change doesn't simply drop completed
frames on the floor, but instead it cleanly handles those frames.
It still discards pending TX frames in the software and hardware queues
as there's no (current) logic which forcibly recalculates the rate control
information (or whether they're appropriate to be on the TX queue after
a channel change), that'll come later.

This still doesn't stop all the sources of queue stalls but it does
tidy up some of the code duplication.

To be complete, queue stalls now occur during normal behaviour -
they only occur after some kind of broken behaviour causes an interface
or node flush, upsetting the TX/RX BAW. Subsequent commits will
incrementally fix these and other related issues.

Sponsored by:	Hobnob, Inc.
2011-11-19 21:05:31 +00:00
adrian
7b8778fe5a Flesh out some slightly dirty reset/channel change serialisation code
for the ath(4) driver.

Currently, there's nothing stopping reset, channel change and general
TX/RX from overlapping with each other. This wasn't a big deal with
pre-11n traffic as it just results in some dropped frames.
It's possible this may have also caused some inconsistencies and
badly-setup hardware.

Since locks can't be held across all of this (the Linux solution)
due to LORs with the network stack locks, some state counter
variables are used to track what parts of the code the driver is
currently in.

When the hardware is being reset, it disables the taskqueue and
waits for pending interrupts, tx, rx and tx completion before
it begins the reset or channel change.

TX and RX both abort if called during an active reset or channel
change.

Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS
is set. Instead, completed TX and RX frames are passed back up to
net80211 before the reset occurs.

This is not without problems:

* Raw frame xmit are just dropped, rather than placed on a queue.
  The net80211 stack should be the one which queues these frames
  rather than the driver.

* It's all very messy. It'd be better if these hardware operations
  were serialised on some kind of work queue, rather than hoping
  they can be run in parallel.

* The taskqueue block/unblock may occur in parallel with the
  newstate() function - which shuts down the taskqueue and restarts
  it once the new state is known. It's likely these operations should
  be refcounted so the taskqueue is restored once no other areas
  in the code wish to suspend operations.

* .. interrupt disable/enable should likely be refcounted as well.

With this work, the driver does not drop frames during stuck beacon
or fatal errors and thus 11n traffic continues to run correctly.
Default and full resets however do still drop frames and it's possible
this may occur, causing traffic loss and session stalls.

Sponsored by:	Hobnob, Inc.
2011-11-18 05:06:30 +00:00
adrian
9317b12276 Disable writing to the extension CYCPWR1 register.
This seems to make ANI behave better on the AR5416/AR5418.

Sponsored by:	Hobnob, Inc.
2011-11-12 16:47:23 +00:00
adrian
bcb4d40c08 Correct device id comments. 2011-11-11 00:48:41 +00:00
adrian
273ff1fe2a Bump this up to where it used to be.
I need to investigate this a little closer, but it seems that in noisy
environments the NF load takes longer than 5 * DELAY(10) and this is
messing up future NF calibrations. (The background: NF calibrations
begin at the value programmed in after the load has completed, so
if this is never loaded in, the NF calibrations only ever start at
the currently calibrated NF value, rather than starting at something
high (say -50.)

More investigation about the effect on 11n RX and calibration results
are needed.

Sponsored by:	Hobnob, Inc.
2011-11-09 23:28:47 +00:00
adrian
e5b49f0c7e Introduce a work-around for issues with the AR5416 based MAC on SMP devices.
The AR5416 MAC (which shows up in the AR5008, AR9001, AR9002 devices) has
issues with PCI transactions on SMP machines. This work-around enforces
that register access is serialised through a (global for now) spinlock.

This should stop the hangs people have seen with the AR5416 PCI devices
on SMP hosts.

Obtained by:	Linux, Atheros
2011-11-09 22:39:44 +00:00
adrian
5eb7ebdde2 Commit a missing fix - the AR_SREV_KIWI_10_OR_LATER() check. 2011-11-09 21:41:18 +00:00
adrian
c8facc38a1 Even though the HAL doesn't currently support Kiwi 1.0/1.1,
be "more correct" about the Kiwi setup.

Obtained from:	Atheros
2011-11-09 19:09:03 +00:00
adrian
e7e8771098 If software retransmit occurs with an ath_buf marked ATH_BUF_BUSY,
it's cloned and that clone is retransmitted. This means that the
ath_buf pointer squirreled away on the baw window array is suddenly
wrong and was causing all kinds of console output.

This updates the pointer in that particular BAW slot to the new
ath_buf after ensuring that:

* the new and old buffers have the same seqno;
* the current slot pointer matches the old buffer pointer.

This quietens the debugging output (again), restoring said debugging
to only signify when a broken condition has occured.

Sponsored by:	Hobnob, Inc.
2011-11-09 18:24:20 +00:00
adrian
44b1ad7245 * Force the MAC to wakeup before we try resetting it, to ensure
it actually _gets_ reset properly.
* Add some more comments describing why things are done.

Obtained from:	Atheros
2011-11-09 14:34:25 +00:00
adrian
378fb742f6 Tidy up the AR9287 HAL a tiny bit - fix up AR9280 references. 2011-11-09 14:30:58 +00:00
adrian
4459c01ca0 Migrate the AR5416 ANI code to use the previously introduced method
to fetch the current channel busy statistics, rather than duplicating
it here.

This forms the (very crude) basis for doing basic channel surveying.

Sponsored by:	Hobnob, Inc.
2011-11-09 05:48:20 +00:00
adrian
5bc5574397 Disable OFDM weak signal detection by default. Leave this to be
enabled if required by STA operation.

This quietens a lot of OFDM errors seen in hostap mode, where
there are no beacon RSSI levels to tune the dynamic range of the
baseband.

This may reduce reception range at the fringes, but does increase
stability.

Sponsored by:	Hobnob, Inc.
2011-11-09 05:45:30 +00:00
adrian
1ba02d5891 Use a restricted set of parameters when operating in hostap mode.
The 5ghz hostap mode (where DFS is being done) requires ANI to be disabled
or the radar detection parameters don't work as advertised (as they're based
on signal strength level, and tweaking ANI affects the signal strangth,
dynamic range and power increase the baseband is looking for in order to
detect it as a "signal".)

Obtained from:	Linux, Atheros
Sponsored by:	Hobnob, Inc.
2011-11-09 05:43:48 +00:00
adrian
546a0649e9 Add logic to ANI to tweak the firstep parameter when in hostap mode.
This is normally done based on the beacon RSSI but this isn't available
in hostap mode.

Obtained from:	Atheros
Sponsored by:	Hobnob, Inc.
2011-11-09 05:41:40 +00:00
adrian
36319f2a98 .. and add some ANI fixes missing from the last ANI commit.
Obtained from:	Atheros
Sponsored by:	Hobnob, Inc.
2011-11-09 05:39:17 +00:00
adrian
44251859b6 Include some ANI fixes for the AR5416.
* If we fall through from an ANI command (eg because it's out of range,
  or it's disabled) then fall through to the next ANI command rather then
  being stuck there.

* Fix some off-by-one comparisons, meaning the final level in some parameters
  were never tweaked.

Obtained from:	Atheros
Sponsored by:	Hobnob, Inc.
2011-11-09 05:37:11 +00:00
adrian
850570a5ae Add a new HAL parameter which forces a full reset rather than warm reset.
This forces a full reset of the baseband/radio and seems needed to clear
some issues (with Merlin at least) when the baseband gets confused in a
very noisy environment.

Sponsored by:	Hobnob, Inc.
2011-11-09 05:30:24 +00:00
adrian
0e53f04ecf Port over a new routine which grabs the percentage of time spent in TX frame, RX frame,
RX clear, RX extension clear.

This is useful for estimating channel business.

The same routines should be written for AR5210->AR5212 where appopriate.

Obtained from:	Atheros
2011-11-09 05:25:30 +00:00
adrian
42e9a9c265 Add in some more PCI/PCIe differentiation. 2011-11-09 04:38:27 +00:00
adrian
e5679fd563 Try to make it more obvious when users are using the PCI or PCIe versions of
the 11n chips.
2011-11-09 04:35:33 +00:00
adrian
9593f94786 Fix the compile to work when IEEE80211_DEBUG isn't defined.
Sponsored by:	Hobnob, Inc.
2011-11-09 04:08:01 +00:00
adrian
778aebbf9d Fix the KTR option to compile by default - it was referencing
some unmerged interrupt status debugging code from my branch.

* Add ah_intrstate[8] which will have the record of the last
  call to ath_hal_getintr().
* Wrap the KTR code behind ATH_KTR_INTR_DEBUG.
* Add the HAL interrupt debugging behind AH_INTERRUPT_DEBUGGING.

This is only done for the AR5416 and later NICs but it will be
trivial to add to the earlier NICs if required.

Neither are enabled by default, although to minimise HAL binary
API differences, the ah_intrstate[] array is always compiled into
the ath_hal struct.
2011-11-08 22:50:28 +00:00
adrian
b9db55d70c Introduce TX aggregation and software TX queue management
for Atheros AR5416 and later wireless devices.

This is a very large commit - the complete history can be
found in the user/adrian/if_ath_tx branch.

Legacy (ie, pre-AR5416) devices also use the per-software
TXQ support and (in theory) can support non-aggregation
ADDBA sessions. However, the net80211 stack doesn't currently
support this.

In summary:

TX path:

* queued frames normally go onto a per-TID, per-node queue
* some special frames (eg ADDBA control frames) are thrown
  directly onto the relevant hardware queue so they can
  go out before any software queued frames are queued.
* Add methods to create, suspend, resume and tear down an
  aggregation session.
* Add in software retransmission of both normal and aggregate
  frames.
* Add in completion handling of aggregate frames, including
  parsing the block ack bitmap provided by the hardware.
* Write an aggregation function which can assemble frames into
  an aggregate based on the selected rate control and channel
  configuration.
* The per-TID queues are locked based on their target hardware
  TX queue. This matches what ath9k/atheros does, and thus
  simplified porting over some of the aggregation logic.
* When doing TX aggregation, stick the sequence number allocation
  in the TX path rather than net80211 TX path, and protect it
  by the TXQ lock.

Rate control:

* Delay rate control selection until the frame is about to
  be queued to the hardware, so retried frames can have their
  rate control choices changed. Frames with a static rate
  control selection have that applied before each TX, just
  to simplify the TX path (ie, not have "static" and "dynamic"
  rate control special cased.)
* Teach ath_rate_sample about aggregates - both completion and
  errors.
* Add an EWMA for tracking what the current "good" MCS rate is
  based on failure rates.

Misc:

* Introduce a bunch of dirty hacks and workarounds so TID mapping
  and net80211 frame inspection can be kept out of the net80211
  layer. Because of the way this code works (and it's from Atheros
  and Linux ath9k), there is a consistent, 1:1 mapping between
  TID and AC. So we need to ensure that frames going to a specific
  TID will _always_ end up on the right AC, and vice versa, or the
  completion/locking will simply get very confused. I plan on
  addressing this mess in the future.

Known issues:

* There is no BAR frame transmission just yet. A whole lot of
  tidying up needs to occur before BAR frame TX can occur in the
  "correct" place - ie, once the TID TX queue has been drained.

* Interface reset/purge/etc results in frames in the TX and RX
  queues being removed. This creates holes in the sequence numbers
  being assigned and the TX/RX AMPDU code (on either side) just
  hangs.

* There's no filtered frame support at the present moment, so
  stations going into power saving mode will simply have a number
  of frames dropped - likely resulting in a traffic "hang".

* Raw frame TX is going to just not function with 11n aggregation.
  Likely this needs to be modified to always override the sequence
  number if the frame is going into an aggregation session.
  However, general raw frame injection currently doesn't work in
  general in net80211, so let's just ignore this for now until
  this is sorted out.

* HT protection is just not implemented and won't be until the above
  is sorted out. In addition, the AR5416 has issues RTS protecting
  large aggregates (anything >8k), so the work around needs to be
  ported and tested. Thus, this will be put on hold until the above
  work is complete.

* The rate control module 'sample' is the only currently supported
  module; onoe/amrr haven't been tested and have likely bit rotted
  a little. I'll follow up with some commits to make them work again
  for non-11n rates, but they won't be updated to handle 11n and
  aggregation. If someone wishes to do so then they're welcome to
  send along patches.

* .. and "sample" doesn't really do a good job of 11n TX. Specifically,
  the metrics used (packet TX time and failure/success rates) isn't as
  useful for 11n. It's likely that it should be extended to take into
  account the aggregate throughput possible and then choose a rate
  which maximises that. Ie, it may be acceptable for a higher MCS rate
  with a higher failure to be used if it gives a more acceptable
  throughput/latency then a lower MCS rate @ a lower error rate.
  Again, patches will be gratefully accepted.

Because of this, ATH_ENABLE_11N is still not enabled by default.

Sponsored by:	Hobnob, Inc.
Obtained from:	Linux, Atheros
2011-11-08 22:43:13 +00:00
adrian
d1f6843e2d Add support to the TX descriptor printing code to follow ath_buf
chains. This allows for debugging of aggregate frames.

Sponsored by:	Hobnob, Inc.
2011-11-08 22:01:03 +00:00
adrian
d69e09b56f Make sure TXEOL is set on default queues. Otherwise we don't get an
interrupt on the completion of a TX queue and this can cause TX
hangs / timeout.

Sponsored by:	Hobnob, Inc.
2011-11-08 21:55:40 +00:00
adrian
65d79f5f4c Refactor out the TX buffer management and completion code in
preparation for TX aggregation.

* Add in logic which calls ath_buf bf->bf_comp if it's set.
  This allows for AMPDU (and RIFS, and FF, if someone desires) code
  to handle completion - which includes freeing subframes, retransmitting
  subframes, etc.

* Break out the buffer free, buffer busy/unbusy default completion handler
  code into separate functions. This allows bf_comp methods to free and
  unbusy each subframe ath_buf as required.

* Break out the statistics update code into a separate function, just
  to clean up the TX completion path a little.

Sponsored by:	Hobnob, Inc.
2011-11-08 21:49:33 +00:00
adrian
49cbf8b5e4 Change the descriptor logic to use bf_lastds to point to the last
descriptor, rather than using the maths involving bf_desc[bf_nseg - 1].

When doing TX aggregation, the status will be updated in the -final-
descriptor of the -final- subframe in an aggregate. Thus bf_lastds
may point to the last descriptor in a completely different ath_buf.

Sponsored by:	Hobnob, Inc.
2011-11-08 21:25:36 +00:00
adrian
7bcb6d191c Change ath_buf allocation to:
* Immediately return NULL if a buffer isn't available;
* Track the "buffers not available" count;
* Clear some fields used for tx aggregation;
* Add ath_buf_clone() which clones the majority of buffer state.
  This is needed when retransmission of a "busy" buffer is required.

Sponsored by:	Hobnob, Inc.
2011-11-08 21:13:05 +00:00
adrian
8c46d06cce Break out the TX DMA stop code into a separate function.
Sponsored by:	Hobnob, Inc.
2011-11-08 21:06:36 +00:00
adrian
227a997065 Add a 'vap' to ath_keyset().
Add some code (which is currently disabled) which modifies the group
multicast key cache behaviour. I haven't yet figured out what the
exact/correct behaviour is so I'm leaving it disabled. It's worth
investigating and "correcting", especially for future work with
mesh/ibss and encryption.

Sponsored by:	Hobnob, Inc.
2011-11-08 19:25:52 +00:00
adrian
7464bb4495 Some more various fixes, etc from my 11n branch.
* When doing software TX queue handling and flush, it's possible
  that the deletion of a VAP (eg a STA shutdown) will queue a
  "STA Disassociate" frame whilst the interface is being deleted.
  The VAP is then deleted, and the frame ends up being queued
  to a node that is freed before it can be TX'ed. Things go awry
  at this point.

  There's no way at the present to avoid freeing the underlying node
  when the vap is being deleted. It's too late in the game.

  I suspect the real fix is to make sure the frame is software
  queued with no completion information somehow, so it doesn't
  link back to a node whose underlying VAP has been freed.
  For now, we'll just have to do this.

* Add some comments showing what's going on.

* Move an instance of the ATH_LOCK() around to protect the interrupt
  set. I'll worry about changing that to a PCU lock later on once
  the 11n code is in the tree.

Sponsored by:	Hobnob, Inc.
2011-11-08 19:18:34 +00:00
adrian
ebf7f1ae73 Add KTR tracepoints to the ath driver, in order to debug TX, RX
and interrupt handling.

Sponsored by:	Hobnob, Inc.
2011-11-08 19:02:59 +00:00
adrian
913f44bdc8 In preparation for supporting 11n TX/RX properly, allow for TX queue draining
and interface resets to be marked as ATH_RESET_DEFAULT, ATH_RESET_FULL,
ATH_RESET_NOLOSS.

Currently a reset is still a reset - ie, all tx/rx frames in the hardware
queues are purged. This means that those frames will be lost to the 11n TX
and RX aggregation state tracking, breaking AMPDU sessions.

The (eventual) new semantics:

* ATH_RESET_DEFAULT:
      full reset, this is the default for reset situations
      which I haven't yet figured out what they should be.
* ATH_RESET_FULL:
      A full reset - for things such as channel changes.
* ATH_RESET_NOLOSS:
      Don't flush TX/RX queues - handle pending RX frames and leave TX
      frames where they are; restart TX DMA from where it was.
2011-11-08 18:56:52 +00:00
adrian
5b3fc4fe6e Break out the node cleanup and node free path, in preparation for
doing software TX queue management.

The software queued TX frames will be freed by the new cleanup
function.

Sponsored by:	Hobnob, Inc.
2011-11-08 18:48:26 +00:00
adrian
3f66d2db4f Preparation for correct 802.11n tx/rx handling.
* Change ath_rx_proc() to ath_rx_tasklet(); make that the taskqueue function.
  This way (eventually) ath_rx_proc() can be called from elsewhere in the
  packet reset/processing queue so frames aren't just "flushed" during
  interface resets/reconfigure. This breaks 802.11n RX aggregation tracking.
* Extend ath_tx_proc() to take a 'resched' flag, which marks whether to
  reschedule further RX PCU reads or not.
* Change ath_tx_processq() to take a "dosched" flag, which will eventually
  be used to indicate whether to reschedule the software TX scheduler.

Sponsored by:	Hobnob, Inc.
2011-11-08 18:45:15 +00:00
adrian
22b39990b1 Conditionally compile the PCI latency workaround; I think it's
only required for some earlier NICs.
2011-11-08 18:37:52 +00:00
adrian
6ecc40aefc Merge in some fixes from the if_ath_tx branch.
* Close down some of the kickpcu races, where the interrupt handler
  can and will run concurrently with the taskqueue.
* Close down the TXQ active/completed race between the interrupt
  handler and the concurrently running tx completion taskqueue
  function.
* Add some tx and rx interrupt count tracking, for debugging.
* Fix the kickpcu logic in ath_rx_proc() to not simply drain and
  restart the TX queue - instead, assume the hardware isn't
  (too) confused and just restart RX DMA. This may break on
  previous chipsets, so if it does I'll add a HAL flag and
  conditionally handle this (ie, for broken chipsets, I'll
  just restore the "stop PCU / flush things / restart PCU"
  logic.)
* Misc stuff

Sponsored by:	Hobnob, Inc.
2011-11-08 18:10:04 +00:00
adrian
324216748e Migrate the STAILQ lists to TAILQs.
A bunch of the 11n TX aggregation logic wants to traverse lists of buffers
in various ways. In order to provide O(1) behaviour in this instance,
use TAILQs.

This does blow out the memory footprint and CPU cycles slightly for some
of these operations. I may convert some of these back to STAILQs once
the rest of the software transmit queue handling has been stabilised.

Sponsored by:	Hobnob, Inc.
2011-11-08 17:08:12 +00:00
adrian
8f9fd74063 Some cosmetic fixes to ath_rate_sample.
* Use 64 bit integer types for the sample rate statistics.
  When TX'ing 11n aggregates, a 32 bit counter will overflow in a few
  hours due to the high packet throughput.

* Create a default label of "" rather than defaulting to "Mb" - that way
  if a rate hasn't yet been selected, it won't say "-1 Mb".

Sponsored by:	Hobnob, Inc.
2011-11-08 14:46:03 +00:00
adrian
476761abc0 Begin merging in some of my 802.11n TX aggregation driver changes.
* Add a PCU lock, which isn't currently used but will eventually be
  used to serialise some of the driver access.

* Add in all the software TX aggregation state, that's kept per-node
  and per-TID.

* Add in the software and aggregation state to ath_buf.

* Add in hooks to ath_softc for aggregation state and the (upcoming)
  aggregation TX state calls.

* Add / fix the HAL access macros.

Obtained from:	Linux, ath9k
Sponsored by:	Hobnob, Inc.
2011-11-08 02:12:11 +00:00
adrian
d5ee0678cc Bring over the 11n aggregation statistics struct from the if_ath_tx branch. 2011-11-08 01:35:44 +00:00
adrian
2b3224e3c9 Merge in ath rate flags and ath_rc_series from my 11n TX branch.
This is in preparation for 802.11n TX aggregation support.
2011-11-08 01:35:05 +00:00
ed
0c56cf839d Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.
The SYSCTL_NODE macro defines a list that stores all child-elements of
that node. If there's no SYSCTL_DECL macro anywhere else, there's no
reason why it shouldn't be static.
2011-11-07 15:43:11 +00:00
ed
e97eae1577 Mark MALLOC_DEFINEs static that have no corresponding MALLOC_DECLAREs.
This means that their use is restricted to a single C file.
2011-11-07 06:44:47 +00:00
adrian
89ec155d24 Call the correct chipset power routine when disabling the AR5416 and later NICs. 2011-11-04 13:32:13 +00:00
adrian
d014d8bac2 Add some new ath(4) debugging bits, from my if_ath_tx 11n TX branch. 2011-10-29 07:17:47 +00:00
adrian
dce52fa119 When punting frames to the RX tap, free the mbufs since we've tampered with
their length.

Without this, an error frame mbuf would:

* have its size adjusted;
* thrown at the radiotap code;
* then since it's never consumed, the rxbuf/mbuf is then re-added to the
  RX descriptor list with the small size;
* .. and the hardware ends up (sometimes) only DMA'ing part of a frame into
  the small buffer, chaining RX frames together (setting the more flag).

I discovered this particular issue when doing some promiscuous radiotap
testing; I found that I'd occasionally get rs_more set in RX descriptors
w/ the first frame length being very small (sub-100 bytes.) The driver
handles 2-descriptor RX frames (but not more), so this still worked; it
was just odd.

This is suboptimal and may benefit from being replaced with caching
the m_pkthdr_len and m_len fields, then restoring them after completion.
2011-10-28 15:44:09 +00:00
adrian
c253b28f92 As a prelude to bringing over the 11n work, include some extra statistics fields. 2011-10-26 16:09:05 +00:00
adrian
6ea6d557dc Add in some more 11n related HAL methods. 2011-10-25 23:33:54 +00:00
adrian
a509bf8b7a The AR5413 datasheet specifies that AR_TxIntrReq should be set consistently
for all frames, so do so.
2011-10-25 23:28:16 +00:00
adrian
58307b54ab Add some fixes to the 11n aggregation HAL calls:
* preserve AR_TxIntrReq on every descriptor in an aggregate chain,
  not just the first descriptor;
* always blank out the descriptor in ar5416ChainTxDesc() when forming
  aggregates - the way I'm using this in the 11n branch is to first
  chain aggregates together, then use the other HAL calls to fill in
  the details.
2011-10-25 23:24:05 +00:00
adrian
6595f592d0 Correct/complete a partially-disabled TX interrupt mitigation configuration.
Although a previous commit disabled TX interrupt mitigation handling and
configuration, the mask register bits weren't setup correctly.
2011-10-25 23:17:53 +00:00
adrian
a08846d3fd Fix an incorrect flag.
Obtained from:	Atheros
2011-10-25 23:14:40 +00:00
adrian
a2f5e9a502 Save and restore the association ID across interface resets.
Obtained from:	Atheros
MFC after:	1 week
2011-10-25 23:13:36 +00:00
adrian
6e02a1785b Add some 11n bits from the if_ath_tx 11n branch:
* Add the TID field in the TX status descriptor;
* Add in the 11n first/middle/last functions for fiddling
  with the descriptors. These are from the Linux and the
  reference driver, but I'm not (currently) using them.
* Add further AR_ISR_S5 register definitions.

Obtained from:	Linux ath9k, Atheros
2011-10-25 23:09:07 +00:00
adrian
04a73f171e Reduce the NF wait timeout. When doing heavy 11n RX loads, this can actually
interfere with traffic, as the NF load can take quite a while and poking the
AGC every 10uS is just a bit silly.

Instead, just leave the baseband NF calibration where it is and just read it
back next time a longcal interval happens.
2011-10-25 23:01:53 +00:00
adrian
6876e3d9c1 Add in a currently-disabled WAR for PCI NICs.
Some earlier series (~AR5212?) play badly with BIOSes.

In these instances, they may require a forced reset (by transitioning
the NIC through D0 -> D3 -> D0) before they probe/attach correctly.

This is currently disabled because:

* I haven't figured out the "right" code to ensure this only happens
  for PCI NICs (not PCIe or Cardbus);
* I haven't at all done wide scale testing for this, and I'm not yet
  ready for said wide-scale testing.

I'm documenting this primarily so users with misbehaving NICs have
something to tinker with.

Obtained from:	Atheros
2011-10-18 03:32:18 +00:00
adrian
e6dc2dfa1d Add a WAR from the reference code - clear the PCI error status
upon detach.

Obtained from:	Atheros
2011-10-18 03:24:17 +00:00
adrian
09fc5efa9d Port over some missing code from the ar5212 reference driver reset path.
The final missing bit here is enabling the PCI configuration register
read, but there's currently no glue available for the HAL to read (and
write) PCI configuration space registers.

Obtained from:	Atheros
2011-10-18 03:17:06 +00:00
adrian
3b5040418a Implement the first part of the BB read workaround.
The AR5008/AR9001 series NICs have a bug where BB register reads
will occasionally be corrupted. This could cause issues with things
such as ANI, which adjust operational parameters based on the
BB radio register reads. This was introduced in the AR5008 chip
and fixed with the first released AR9002 series NIC (AR9280v2.)

A followup commit will implement the acutal WAR when reading
BB registers. I'm still not sure how I'll implement it - whether
it should be done in the osdep layer, or whether it should just
live in the AR5416 HAL. Either way, they can use this capability
bit to determine whether to implement the WAR or not.

Thankyou to various sources inside Atheros who have helped me track
down what this particular issue is.

Obtained from:	Atheros
2011-10-18 03:01:41 +00:00
adrian
9000cf77a5 Add in OS_REG_BIT_SET, a macro which does what it says it does.
This will be used in an upcoming commit to the ar5212 HAL.
2011-10-18 02:46:26 +00:00
adrian
1e651efecd Include opt_ah.h when compiling the driver.
There are HAL methods which are actually direct register
access, rather than simply HAL calls. Because of this, these
register accesses would use the non-debug path in ah_osdep.h
as opt_ah.h isn't included.

With this, the correct register access methods are used,
so debugging traces show things such as TXDP checking and
TSF32 access.
2011-10-18 02:43:59 +00:00
adrian
6d4595e17a Don't enable the PHY radar errors in calcrxfilter.
That way the radar errors aren't enabled prematurely.

A DFS tester has reported that radar events are reported
during channel scanning, before DFS is actually enabled.
2011-10-17 14:17:37 +00:00
eadler
9d7884364e - change "is is" to "is" or "it is"
- change "the the" to "the"

Approved by:	lstewart
Approved by:	sahil (mentor)
MFC after:	3 days
2011-10-16 14:30:28 +00:00
adrian
9cf34024d8 ath_pci PCI setup fixes.
* Break out the PCI setup override code into a new function.
* Re-apply the PCI overrides on powersave resume. The retry timeout
  register isn't currently being saved/resumed by the PCI driver/bus
  code.
2011-10-14 03:24:35 +00:00
adrian
78eb31771d Add an AR5416 aware version of the "current RSSI" function.
Pre-11n devices and AR5416 use AR_PHY(263) for current RX RSSI.
AR9130 and later have a fourth calibration register (for doing
ADC calibration) and thus the register has moved to AR_PHY(271).

This isn't currently used by any of the active code; I'm committing
this for completeness and in case any third party code attempts to
use it for legacy reasons.
2011-10-04 00:32:10 +00:00
adrian
cb6db8fe7c Port over the radar pulse decoding code common to the AR5416 and later chipsets.
Obtained from:	Atheros
2011-10-03 12:12:03 +00:00
adrian
8c4de897b3 Remove an unused variable. 2011-10-02 14:10:25 +00:00
adrian
e0b19442ed Various interrupt handling and RX interrupt mitigation fixes.
* The AR_ISR_RAC interrupt processing method has a subtle bug in all
  the MAC revisions (including pre-11n NICs) until AR9300v2.
  If you're unlucky, the clear phase clears an update to one of the
  secondary registers, which includes TX status.

  This shows up as a "watchdog timeout" if you're doing very low levels
  of TX traffic. If you're doing a lot of non-11n TX traffic, you'll
  end up receiving a TX interrupt from some later traffic anyway.

  But when TX'ing 11n aggregation session traffic (which -HEAD isn't yet
  doing), you may find that you're only able to TX one frame (due to
  BAW restrictions) and this may end up hitting this race condition.

  The only solution is to not use RAC and instead use AR_ISR and the
  AR_ISR_Sx registers. The bit in AR_ISR which represents the secondary
  registers are not cleared; only the AR_ISR_Sx bits are. This way
  any updates which occur between the read and subsequent write will
  stay asserted and (correctly) trigger a subsequent interrupt.

  I've tested this on the AR5416, AR9160, AR9280. I will soon test
  the AR9285 and AR9287.

* The AR_ISR TX and RX bits (and all others!) are set regardless of
  whether the contents of the AR_IMR register. So if RX mitigation is
  enabled, RXOK is going to be set in AR_ISR and it would normally set
  HAL_INT_RX.

  Fix the code to not set HAL_INT_RX when RXOK is set and RX mitigation
  is compiled in. That way the RX path isn't prematurely called.

  I would see:

  * An interrupt would come in (eg a beacon, or TX completion) where
    RXOK was set but RXINTM/RXMINT wasn't;
  * ath_rx_proc() be called - completing RX frames;
  * RXINTM/RXMINT would then fire;
  * ath_rx_proc() would then be called again but find no frames in the
    queue.

  This fixes the RX mitigation behaviour to not overly call ath_rx_proc().

* Start to flesh out more correct timer interrupt handling - it isn't
  kite/merlin specific. It's actually based on whether autosleep support
  is enabled or not.

This is sourced from my 11n TX branch and has been tested for a few weeks.

Finally, the interrupt handling change should likely be implemented
for AR5210, AR5211 and AR5212.
2011-10-02 14:08:56 +00:00
adrian
a8501dc6a4 Document exactly what the RX interrupt mitigation timers do. 2011-10-02 13:51:26 +00:00
adrian
1ec817d535 For now (ie: until autosleep support is fully fleshed out), always clear
all of the RX status fields when initialising a new RX descriptor.
2011-10-02 13:47:03 +00:00
adrian
5efb6b8695 Disable TX interrupt mitigation just for the time being.
There are some timing concerns which I've yet to fully map out.
In any case, there's an existing software driven mitigation method
for TX interrupts and when TX'ing 11n frames, the whole frame itself
generates an interrupt rather then the subframes.
2011-10-02 13:43:06 +00:00
adrian
5f2fef9093 Fix a corner case in the HAL debugging changes, where ah was NULL.
Although I tried to fix this earlier by introducing HALDEBUG_G(), it
turns out there seem to be other cases where the pointer value is still
NULL.

* Fix DO_HALDEBUG() and the HALDEBUG macro to check whether ah is NULL
  before deferencing it
* Remove HALDEBUG_G() as it's no longer needed

This is hopefully a merge candidate for 9.0-RELEASE as enabling
debugging at startup could result in a kernel panic.
2011-09-30 05:17:57 +00:00
adrian
38b4a98424 Don't bother triggering the cabq queue if it's empty.
Obtained from:	Atheros
2011-09-28 03:11:51 +00:00
adrian
bdf51ae15c Fix lock order to be correcter.
Nothing else locks these two queues (cabq, avp mcastq), but it should
be consistent and correct.
2011-09-28 03:07:51 +00:00
adrian
fcce3eb232 Change the default CABQ time to be 70% of the beacon interval,
rather than the whole beacon interval.

The reference driver and Linux ath9k both choose 80% of the
beacon interval and they do it in the driver rather than
the HAL (Ath reference) or ath9k_hw (ath9k.)

This quietens stuck beacon conditions on my AR9220/AR9280
based NICs when a lot of burst broadcast/multicast traffic
is going on. It doesn't seem to annoy the earlier MACs as
much as the AR9280 and later one.

Obtained from:	Linux ath9k, Atheros
2011-09-28 03:05:04 +00:00
adrian
24bffc47a9 The AR5212 setup path (also used by the AR5416 code) configures a
local variable with a beacon interval of 100 TU. This never gets modified
if the beacon interval configuration changes.

This may have been correct in earlier times, but with the advent of
staggered beacons (which default to 1 / ATH_BCBUF beacon interval, so
25 TU here) this value is incorrect.

It is used to configure the default CABQ readytime. So here, the cabq
was being configured to be much greater than the target beacon timer
(TBTT.)

The driver should be configuring a cabq readytime value rather then
leaving it to the HAL to choose sensible defaults. This should be
done in the future - I'm simply trying to ensure sensible defaults
are chosen.
2011-09-28 03:03:23 +00:00
adrian
29cd3e0c88 Update the default AIFS value for hostap mode.
Obtained from:	Linux ath9k, Atheros reference
2011-09-28 02:54:42 +00:00
adrian
b7f3e89486 Fix the order of parameters passed to the HT frame duration calculation.
Approved by:	re (kib)
2011-09-11 09:43:13 +00:00
adrian
b64fa0490d Update the TSF and next-TBTT methods to work for the AR5416 and later NICs.
This is another commit in a series of TDMA support fixes for the 11n NICs.

* Move ath_hal_getnexttbtt() into the HAL; write methods for it.
  This returns a timer value in TSF, rather than TU.

* Move ath_hal_getcca() and ath_hal_setcca() into the HAL too, where they
  likely now belong.

* Create a new HAL capability: HAL_CAP_LONG_RXDESC_TSF.
  The pre-11n NICs write 15 bit TSF snapshots into the RX descriptor;
  the AR5416 and later write 32 bit TSF snapshots into the RX descriptor.
* Use the new capability to choose between 15 and 31 bit TSF adjustment
  functions in ath_extend_tsf().

* Write ar5416GetTsf64() and ar5416SetTsf64() methods.
  ar5416GetTsf64() tries to compensate for TSF changes at the 32 bit boundary.

According to yin, this fixes the TDMA beaconing on 11n chipsets and TDMA
stations can now associate/talk, but there are still issues with traffic
stability which need to be investigated.

The ath_hal_extendtsf() function is also used in RX packet timestamping;
this may improve adhoc mode on the 11n chipsets. It also will affect the
timestamps seen in radiotap frames.

Submitted by:	Kang Yin Su <cantona@cantona.net>
Approved by:	re (kib)
2011-09-08 01:23:05 +00:00
adrian
cdf7076d71 Add a definition for ASYNC_CAUSE_CLR. It's not used yet, but the
reference driver does clear the async interrupts after each service.
I'll tinker with this in a future commit.

Obtained from:	Atheros
Approved by:	re (kib)
2011-09-07 03:00:58 +00:00
adrian
b9fc62c9ff Fix 5ghz calibration logic when using AR9280 w/ fast clock.
When the fast clock (44mhz) is enabled for 5ghz HT20, the
dual ADCs aren't enabled. Trying to do the ADC calibrations
here would result in calibration never completing; this
resulted in IQ calibration never running and thus performance
issues in 11a/11n HT20 mode.

Leave it enabled for non-fastclock (40mhz) 11a mode and
HT40 modes.

This has been fixed in discussion with Felix Fietkau (nbd)
and discussions with the Atheros baseband team.

Linux ath9k now has a similar fix.

Approved by:	re (kib)
2011-09-06 10:54:56 +00:00
adrian
291d2442b6 Fix the addac serial load register write for AR5416.
Obtained from:	Linux, Atheros
Approved by:	re (kib)
2011-09-06 10:49:05 +00:00