Commit Graph

413 Commits

Author SHA1 Message Date
Adrian Chadd
d3054f72e0 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 Chadd
a1dd224b99 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 Chadd
020d7846cb Add in some more PCI/PCIe differentiation. 2011-11-09 04:38:27 +00:00
Adrian Chadd
5b77f8e9f5 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 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
543d97bb43 Call the correct chipset power routine when disabling the AR5416 and later NICs. 2011-11-04 13:32:13 +00:00
Adrian Chadd
d79ac7a74f Add in some more 11n related HAL methods. 2011-10-25 23:33:54 +00:00
Adrian Chadd
e674b5f30d 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 Chadd
6897698afe 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 Chadd
00d829dae7 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 Chadd
9ff4b713b2 Fix an incorrect flag.
Obtained from:	Atheros
2011-10-25 23:14:40 +00:00
Adrian Chadd
0047ff7096 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 Chadd
5916ef68df 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 Chadd
24f5f7ee4e 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 Chadd
0cbbe87008 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 Chadd
46614948dd 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 Chadd
31a47d8c14 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 Chadd
a57433b96b 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 Chadd
f6f6e2c803 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 Chadd
f20aaceeb4 Remove an unused variable. 2011-10-02 14:10:25 +00:00
Adrian Chadd
62f62f4f4a 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 Chadd
7e132ca3e3 Document exactly what the RX interrupt mitigation timers do. 2011-10-02 13:51:26 +00:00
Adrian Chadd
75350906bc 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 Chadd
9bf15204ae 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 Chadd
0e56140a1b 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 Chadd
353d29772b 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 Chadd
c3f2102bef 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 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
c62055f6de 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 Chadd
aacc74998a 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 Chadd
d497ffcab4 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
Adrian Chadd
607756e9de TIM/Timer fixes for AR5416 and later:
* 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)
2011-08-24 00:45:53 +00:00
Adrian Chadd
34ff1d08f6 These timer registers are all 1uS in resolution in AR5416
or later. Previous hardware had some as TU, some as 1/8th
TU.

* Modify AR_NEXT_DBA and AR_NEXT_SWBA to use a new macro,
  ONE_EIGHTH_TU_TO_USEC(), which converts the 1/8th TU
  fields to USEC. This is just cosmetic and matches the
  Atheros reference driver.

* Fix AR_NEXT_TBTT, which is USEC, not TU.

Submitted by:	paradyse@gmail.com
Approved by:	re (kib, blanket)
2011-08-23 13:36:09 +00:00
Adrian Chadd
ffae5d00d2 Bitten again by the optional HALDEBUG compilation.
Remove this debugging, it's not needed anymore and when not enabled,
those variables trigger a compiler warning.

Approved by:	re (kib, blanket)
Pointy-hat-to:	adrian, for not testing a non-debug compile of this code enough
2011-08-08 18:05:22 +00:00
Adrian Chadd
7dd4de1301 The older HAL code sets up the regulatory domain once; FreeBSD/net80211
allows it to be overridden at runtime.

Thus, add a function which updates ah_dfsDomain after a channel set
call to ath_hal_set_channels().

Approved by:	re (kib, blanket)
2011-08-08 17:33:35 +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
60829c4817 Add another HAL method - ah_isFastClockEnabled - which returns AH_TRUE
if 5ghz fast clock is enabled in the current operating mode.

It's slightly dirty, but it's part of the reference HAL and used by
the (currently closed-source) radar event code to map radar pulses
back to microsecond durations.

Obtained from:	Atheros
Approved by:	re (kib, blanket)
2011-08-08 13:15:39 +00:00
Adrian Chadd
625b09b021 Undo this for now. It's "right", but it means everything will rely on
the ar9130 code.

Since at least one kernel config specifies individual ath HAL chips
rather than just "device ath_hal" (arm/AVILA), I'm doing this so people
aren't caught out when they update to -HEAD or 9.0 and discover their
ath setup doesn't compile.

I'll revisit this with a proper fix sometime before 9.0-RELEASE.

Approved by:	re (kib, blanket)
Pointed out by:	ray@
Pointy hat to:	adrian@
2011-08-03 23:57:38 +00:00
Adrian Chadd
844537c1e0 Add in a dirty hack that allows for AR9280/AR9285/AR9287 embedded
systems, in the same way that AR9130 embedded systems work.

This isn't -everything- that is required - the PCI glue still
needs to be taught about the eepromdata hint, along the same
lines as the AHB glue.

Approved by:	re (kib, blanket)
2011-08-03 13:39:11 +00:00
Adrian Chadd
b1698e1f6b * Fix a clash in structure naming which occurs with (closed source)
radar detection code. This is just to make porting the atheros
  radar code easier.

* add a missing space.

Approved by:	re (kib, blanket)
2011-08-03 13:36:14 +00:00
Adrian Chadd
52227d94df Remove the EEPROM minor >= 19 check for txgaintype; that's only needed for
Merlin / v14 eeprom formats.

Approved by:	re (kib, blanket)
2011-08-03 06:51:14 +00:00
Adrian Chadd
44ade163ce Add extra flags for the radar event API.
(They're not used by any public code at the current time.)

Approved by:	re (kib)
2011-07-31 05:01:42 +00:00
Adrian Chadd
6eec7effeb Add some more phyerr bits.
Obtained from:	Atheros
Approved by:	re (kib)
2011-07-31 03:33:02 +00:00
Adrian Chadd
7239f9f75b Introduce the FRAC_5G EEPROM parameter.
This seems to indicate whether to program the NIC for fractional 5ghz
mode (ie, 5mhz spaced channels, rather than 10 or 20mhz spacing) or not.
The default (0) seems to mean "only program fractional mode if needed".
A different value (eg 1) seems to always enable fractional 5ghz mode
regardless of the frequency.

Obtained from:	Atheros
Approved by:	re (kib)
2011-07-30 13:45:12 +00:00
Adrian Chadd
b649b13f03 Prepare for embedded use of the AR9285/AR9287.
Calibration/PCI data that's written to flash (rather than EEPROM attached
to the NIC) is typically already in host-endian. The existing checks
end up swapping 16 bit words incorrectly - the correct solution would be
to read the magic value and determine the EEPROM endianness from that.
(This is what Linux does.)

This doesn't completely enable embedded use of the AR9285/AR9287 -
notably, the EEPROM read methods need to be made generic and available
to all EEPROM drivers. I'll worry about that later.

Approved by:	re (kib)
2011-07-30 13:37:38 +00:00
Adrian Chadd
bb40c7e83f Fix AR5416 radar parameter initialisation.
* I messed up the order of parameter true/false; oops!
* AR_PHY_RADAR_1 was being written at the wrong place, and was writing
  potential garbage to the hardware.

Approved by:	re (kib)
2011-07-30 13:34:57 +00:00
Adrian Chadd
78b72aff33 Fix the initial calibration sample count when doing ADC calibrations.
Obtained from:	Atheros
Approved by:	re (kib)
2011-07-30 13:31:27 +00:00
Adrian Chadd
e875139a4f Fix ANI handling to work correctly when (trying) to receive radar errors.
* Teach the AR5212/AR5416 ANI code to use the RX filter methods, rather
  than calling the RX filter routines directly.

* Make HAL_ANI_PRESENT and HAL_ANI_MODE unconditionally available,
  regardless of whether ah_ani_function is masking it.

* (Mostly) fully disable ANI if interference mitigation is disabled.
  When disabled, the ANI code doesn't touch any ANI/PHY registers,
  leaving them the default value. This is in line with what the
  Atheros reference driver does.

* Correctly set the ANI parameters during ANI reset, rather than
  when ANI is enabled. In this way, if ANI is disabled or enabled
  whilst the NIC is not active (and there's no current channel),
  bogus parameters or a NULL pointer deference doesn't occur.

There's still some lingering issues - notably, the MIB events/interrupts
aren't fully disabled, so MIB interrupts still occur. I'll worry about
that later.

Approved by:	re (kib)
2011-07-30 13:30:24 +00:00
Adrian Chadd
f1ef788d6f Bring over AR5416 specific RX filter get/set routines.
This in particular fixes radar PHY handling - on the AR5212
NIC, one enables the AR_PHY_ERR_RADAR bit in AR_PHY_ERR;
the AR5416 and later also needs a bit set in AR_RX_FILTER.

A follow-up commit is needed to convert the AR5416 ANI code
to use this particular method, as it's currently using the
AR5212 methods directly.

Obtained from:	Atheros
Approved by:	re (kib)
2011-07-30 13:25:11 +00:00
Adrian Chadd
c86c3aa3d9 I noticed that the Merlin NICs I had (AR9220, AR9280) never completed
the ADC calibrations if the NIC is in 5ghz 11a or 5ghz HT/20 modes.
I've been told that the dual-ADC is only engaged in turbo/40mhz modes.

Since Sowl (AR9160) seems to return valid-looking calibration data
in 5ghz 20MHz modes, I'm only disabling it for Merlin for now.
It may turn out I can disable it for all chipsets and only enable
it for 40MHz modes.

Approved by:	re (kib)
2011-07-30 13:21:33 +00:00