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
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
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
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.
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.
* 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.
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.
mode configuration registers. This is apparently required for correct
behaviour, but also requires the chip to actually officially support it.
Sponsored by: Hobnob, Inc.
"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.
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.
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.
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
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.
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.
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.
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.
* 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.
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.
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
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.
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
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.
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.
* 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.
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.
* 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.
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.
* 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.
* 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.
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.
* 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.
* 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.
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.
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.
* 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.
* 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
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.
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
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
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
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.
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.
* 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.
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.
* 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.
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.
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.
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
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.
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)
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)
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)
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)
* Fix SLEEP1/SLEEP2 register definitions; the CAB/Beacon timeout
fields have changed in AR5416 and later
* The TIM_PERIOD and DTIM_PERIOD registers are now microsecond fields,
not TU.
Obtained from: Linux ath9k, Atheros reference
Approved by: re (kib, blanket)
