Commit Graph

378 Commits

Author SHA1 Message Date
Adrian Chadd
7ebd03d755 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 Chadd
fad901eb2b 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 Chadd
3440495a52 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 Chadd
a497cd8806 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 Chadd
6558ffd99a 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 Chadd
c65ee21d46 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 Chadd
7e97436b0e 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 Chadd
ee3219757a 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 Chadd
6e0f116875 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 Chadd
197d53c565 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
Bernhard Schmidt
fcd9500f91 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 Chadd
46a924c4c8 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 Chadd
0fbe75a1c9 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 Chadd
a2d8240de5 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 Chadd
5856d663ae Fix some whitespace pollution. 2011-11-21 21:59:01 +00:00
Adrian Chadd
9a842e8b59 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 Chadd
ef27340c5b 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 Chadd
ddbe3036e5 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 Chadd
31fdf3d6d2 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 Chadd
eb6f0de09d 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 Chadd
1f25c0f7a7 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 Chadd
9352fb7ab0 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 Chadd
6edf1dc729 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 Chadd
e346b0732c 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 Chadd
2d43342484 Break out the TX DMA stop code into a separate function.
Sponsored by:	Hobnob, Inc.
2011-11-08 21:06:36 +00:00
Adrian Chadd
55c7b87745 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 Chadd
16d4de92f9 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 Chadd
f52d345218 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 Chadd
517526efe8 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 Chadd
4afa805ec7 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 Chadd
96ff485dc3 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 Chadd
8f939e7967 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 Chadd
6b349e5a86 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 Chadd
3dd85b265f 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
Ed Schouten
d745c852be 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 Chadd
dcfd99a788 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 Chadd
3f3087fd02 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 Chadd
a05e382c09 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
Adrian Chadd
0e0290482b Don't bother triggering the cabq queue if it's empty.
Obtained from:	Atheros
2011-09-28 03:11:51 +00:00
Adrian Chadd
7b15790a4b 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 Chadd
fc4de9b7fc 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 Chadd
f3fb16875c Fix a missing initialisation of bt_flags when setting up the TDMA beacon.
The AR5212 HAL didn't check this field; timers are enabled a different
way.

The AR5416 HAL however did, and since this field was uninitialised, it had
whatever was on the stack at the time. This lead to "unpredictable"
behaviour.

This allows TDMA to work on the AR5416 and later chipsets.

Thanks to:	paradyse@gmail.com
Approved by:	re (kib, blanket)
2011-08-24 14:11:00 +00:00
Adrian Chadd
f35ec93778 Remove this call, now that I've solved the radar module problem without
needing this particular modification.

It can be called during ath_dfs_radar_enable() and still achieve the
same functionality, so I am.

Approved by:	re (kib, blanket)
2011-08-09 04:24:56 +00:00
Adrian Chadd
8db87e4079 Introduce some more DFS related hooks, inspired both by local work
and the Atheros reference code.

The radar detection code needs to know what the current DFS domain is.
Since net80211 doesn't currently know this information, it's extracted
from the HAL regulatory domain information.

The specifics:

* add a new ath_dfs API hook, ath_dfs_init_radar_filters(), which
  updates the radar filters whenever the regulatory domain changes.
* add HAL_DFS_DOMAIN which describes the currently configured DFS domain .
* add a new HAL internal variable which tracks the currently configured
  HAL DFS domain.
* add a new HAL capability, HAL_CAP_DFS_DMN, which returns the currently
  configured HAL DFS domain setting.
* update the HAL DFS domain setting whenever the channel setting is
  updated.

Since this isn't currently used by any radar code, these should all
be no-ops for existing users.

Obtained from:	Atheros
Submitted by:	KBC Networks, sibridge
Approved by:	re (kib, blanket)
2011-08-08 16:22:42 +00:00
Adrian Chadd
1fdadc0fb6 Fix a corner case in RXEOL handling which was likely introduced by yours
truly.

Before 802.11n, the RX descriptor list would employ the "self-linked tail
descriptor" trick which linked the last descriptor back to itself.
This way, the RX engine would never hit the "end" of the list and stop
processing RX (and assert RXEOL) as it never hit a descriptor whose next
pointer was 0. It would just keep overwriting the last descriptor until
the software freed up some more RX descriptors and chained them onto the
end.

For 802.11n, this needs to stop as a self-linked RX descriptor tickles the
block-ack logic into ACK'ing whatever frames are received into that
self-linked descriptor - so in very busy periods, you could end up with
A-MPDU traffic that is ACKed but never received by the 802.11 stack.
This would cause some confusion as the ADDBA windows would suddenly
be out of sync.

So when that occured here, the last descriptor would be hit and the PCU
logic would stop. It would only start again when the RX descriptor list
was updated and the PCU RX engine was re-tickled. That wasn't being done,
so RXEOL would be continuously asserted and no RX would continue.

This patch introduces a new flag - sc->sc_kickpcu - which when set,
signals the RX task to kick the PCU after its processed whatever packets
it can. This way completed packets aren't discarded.

In case some other task gets called which resets the hardware, don't
update sc->sc_imask - instead, just update the hardware interrupt mask
directly and let either ath_rx_proc() or ath_reset() restore the imask
to its former setting.

Note: this bug was only triggered when doing a whole lot of frame snooping
with serial console IO in the RX task. This would defer interrupt processing
enough to cause an RX descriptor overflow. It doesn't happen in normal
conditions.

Approved by: re (kib, blanket)
2011-08-02 02:46:03 +00:00
Adrian Chadd
73f895fcf6 Disable the RXORN/RXEOL interrupts if RXEOL occurs, preventing an
interrupt storm.

This is easily triggered by flipping on and off tcpdump -y IEEE802_11_RADIO
w/ witness enabled. This causes a whole lot of console IO and when you're
attached to a serial console (eg on my AR7161 embedded board), the RX
interrupt doesn't get called quickly enough and the RX queue fills up.

This wasn't a problem in the past because of the self-linked RX descriptor
trick - the RX would never hit the "end" of the RX descriptor list.
However this isn't possible for 802.11n (see previous commit history for
why.)

Both Linux ath9k and the Atheros reference driver code do this; I'm just
looking now for where they then restart the PCU receive. Right now the RX
will just stop until the interface is reset.

Obtained from:	Linux, Atheros
Approved by:	re (kib)
2011-07-31 16:16:25 +00:00
Adrian Chadd
4b326fda72 Remove two debugging printf()s which snuck in during the testing of the
last commit.

Approved by:	re (kib)
Pointy-hat-to:	adrian@
2011-07-31 08:13:25 +00:00
Adrian Chadd
45abcd6c9c Implement the 4KB split transaction workaround for Merlin (AR9280).
The AR9280 apparently has an issue with descriptors which straddle a page
boundary (4k). I'm not yet sure whether I should use PAGE_SIZE in the
calculations or whether I should use 4096; the reference code uses 4096.

This patch fiddles with descriptor allocation so a descriptor entry
doesn't straddle a 4kb address boundary. The descriptor memory allocation
is made larger to contain extra descriptors and then the descriptor
address is advanced to the next 4kb boundary where needed.

I've tested this both on Merlin (AR9280) and non-Merlin (in this case,
AR9160.)

Obtained from:	Linux, Atheros
Approved by:	re (kib)
2011-07-31 08:01:41 +00:00
Adrian Chadd
f51c84eaf6 This links in the ath dfs ioctl into the driver and defines the
ioctl interface for DFS modules to use.

Since there's no open source dfs code yet, this doesn't introduce any
operational changes.

Approved by:	re (kib)
2011-07-21 14:25:12 +00:00
Adrian Chadd
f52efb6d38 Fix a corner case in STA beacon processing when a CSA is received but
the AP doesn't transmit beacons.

If the AP requests a CSA (ie, a channel switch) and then enters CAC
(channel availability check) for 60 seconds, it doesn't send beacons
and it just listens for radar events (and other things which we don't
do yet.)

Now, ath_newstate() was not resetting the beacon timer config on
a transition to the RUN state when in STA mode - it was setting
sc_syncbeacon, which simply updates the beacon config from the
contents of the next received beacon.

This means the STA never generates beacon miss events.

If the AP goes into CAC for 60 seconds and recovers, the STA will
happily receive the first beacon and reconfigure timers.
But if it gets a radar event after that, it'll change channel
again, not notify the station that it's changed channel..
and since the station is happily waiting for the first beacon
to configure the beacon timer details from, it won't ever
generate a beacon miss interrupt and it'll sit there forever
(or until the AP appears on that channel once again.)

This change forces the last known beacon timer config to be
written to hardware on a transition from CSA->RUN in STA mode.
This forces bmiss events to occur and the STA will eventually
(after a handful of beacon miss events) begin scanning for
another access point.
2011-06-29 13:21:52 +00:00