| 343493 |
27-Jan-2019 |
avos |
MFC r306323:
[ath_hal] Add FCC6_FCCA regulatory domain (0x0014).
PR: 194336
Requested by: Chris Hutchinson <portmaster@bsdforge.com> |
| 331722 |
29-Mar-2018 |
eadler |
Revert r330897:
This was intended to be a non-functional change. It wasn't. The commit
message was thus wrong. In addition it broke arm, and merged crypto
related code.
Revert with prejudice.
This revert skips files touched in r316370 since that commit was since
MFCed. This revert also skips files that require $FreeBSD$ property
changes.
Thank you to those who helped me get out of this mess including but not
limited to gonzo, kevans, rgrimes.
Requested by: gjb (re) |
| 330897 |
14-Mar-2018 |
eadler |
Partial merge of the SPDX changes
These changes are incomplete but are making it difficult
to determine what other changes can/should be merged.
No objections from: pfg |
| 305614 |
08-Sep-2016 |
pfg |
MFC r303891, r303892:
sys: replace comma with semicolon when pertinent.
Uses of commas instead of a semicolons can easily go undetected. The comma
can serve as a statement separator but this shouldn't be abused when
statements are meant to be standalone. |
| 302408 |
08-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.
Additional commits post-branch will follow.
Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation |
| 301304 |
04-Jun-2016 |
adrian |
[ath_hal] add placeholders for AUDIO stomp for Kite/Kiwi.
It just stomps all; which is enough for some testing.
|
| 301303 |
04-Jun-2016 |
adrian |
[ath_hal] add BTCOEX_STOMP_AUDIO; delete unused methods.
|
| 301089 |
01-Jun-2016 |
adrian |
[ath_hal] add extra MCI definitions used by the later chips (QCA9565/Aphrodite).
Obtained from: Linux ath9k
|
| 301043 |
31-May-2016 |
adrian |
[ath_hal] rename the MCI state info routine.
It's not /really/ "get state".
|
| 301042 |
31-May-2016 |
adrian |
[ath_hal] add support for setting the azimuth timestamp in the outgoing TX payload.
FYI: This is an unsupported/deprecated feature of the 11n hardware.
|
| 301041 |
31-May-2016 |
adrian |
[ath_hal] reserve a HAL_TXDESC_ bit for azimuth TX timestamp requests.
|
| 301014 |
31-May-2016 |
adrian |
[ath_hal] migrate the bluetooth definitions out from ah.h / ar9300_freebsd_inc.h.
The eventual MCI driver side of things needs the MCI bits to live
in the HAL API so we can get to them.
Tested:
* QCA9565, STA mode + bluetooth
|
| 301013 |
31-May-2016 |
adrian |
[ath_hal] add bluetooth coexistence definitions for both legacy and MCI.
The legacy bits are just from ah.h; the MCI bits are from the ar9300
HAL "freebsd" extras.
A subsequent commit will include ah_btcoex.h into ah.h and remove
the older defintions.
|
| 300267 |
20-May-2016 |
adrian |
[ath] convert recent changes over to HAL format.
This is needed to compile the ath tools, that includes this code
to run in userland.
Tested:
* Carambola 2, AR9331, STA mode
|
| 300246 |
19-May-2016 |
avos |
ath: refactor/split getchannels() method.
Split getchannels() method in ath_hal/ah_regdomain.c into a subset
of functions for better readability.
Note: due to different internal structure, it cannot use
ieee80211_add_channel*() (however, some parts are done in a
similar manner).
Differential Revision: https://reviews.freebsd.org/D6139
|
| 298939 |
02-May-2016 |
pfg |
dev/ath: minor spelling fixes in comments.
No functional change.
Reviewed by: adrian
|
| 297793 |
10-Apr-2016 |
pfg |
Cleanup unnecessary semicolons from the kernel.
Found with devel/coccinelle.
|
| 296176 |
29-Feb-2016 |
adrian |
Fix up the ath(4) device names for QCA chipsets.
Submitted by: Tobias Kortkamp <t@tobik.me>
|
| 291469 |
30-Nov-2015 |
adrian |
fix ht/40 configuration for ar9331 (hornet).
The synth programming here requires the real centre frequency,
which for HT20 channels is the normal channel, but HT40 is
/not/ the primary channel. Everything else was using 'freq',
which is the correct centre frequency, but the hornet config
was using 'ichan' to do the lookup which was also the primary
channel.
So, modify the HAL call that does the mapping to take a frequency
in MHz and return the channel number.
Tested:
* Carambola 2, AR9331, tested both HT/20 and HT/40 operation.
|
| 291418 |
28-Nov-2015 |
adrian |
[ath_hal] use the correct revision information for QCA953x.
This probe/attaches correctly in my local branch and now displays
a useful message:
ath0: <Qualcomm Atheros QCA953x> at mem 0x18100000-0x1811ffff irq 0 on nexus0
...
ath0: AR9530 mac 1280.0 RF5110 phy 0.0
|
| 291413 |
28-Nov-2015 |
adrian |
* Add device string for QCA955x (scorpion);
* Add device ID and device string for QCA953x (honeybee).
|
| 290616 |
09-Nov-2015 |
garga |
Fix kernel build, broken in r290612
Approved by: adrian
|
| 290612 |
09-Nov-2015 |
adrian |
ath(4): begin fleshing out a "reset type" extension to force cold/warn resets.
Right now the only way to force a cold reset is:
* The HAL itself detects it's needed, or
* The sysctl, setting all resets to be cold.
Trouble is, cold resets take quite a bit longer than warm resets.
However, there are situations where a cold reset would be nice.
Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results,
etc.
The vendor HAL has a separate method to set the reset reason (which is
how HAL_RESET_BBPANIC gets set) which informs the HAL during the reset path
why it occured. This is almost but not quite the same; I may eventually
unify both approaches in the future.
This commit just extends HAL_RESET_TYPE to include both status (eg BBPANIC)
and type (eg do COLD.) None of the HAL code uses it yet though; that'll
come later.
It also is a big no-op in each HAL - I need to go teach each of the HALs
about cold/warm reset through this path.
|
| 289099 |
10-Oct-2015 |
adrian |
Flip on fast frames support for AR5416 and AR9300 series NICs.
This was off because the net80211 aggregation code was using the same
state pointers for both fast frames and ampdu tx support which led to some
pretty unfortunate panic-y behaviour.
Now that net80211 doesn't panic, let's flip this back on.
It doesn't (yet) do the horrific sounding thing of A-MPDU aggregates
of fast frames; that'll come next. It's a pre-requisite to supporting
AMSDU + AMPDU anyway, which actually speeds things up quite considerably
(think packing lots of little ACK frames into a single AMSDU.)
Tested:
* QCA955x SoC, AP mode
* AR5416, STA mode
* AR9170, STA mode (with local fast frame patches)
|
| 281128 |
06-Apr-2015 |
adrian |
Return the correct HAL data type for HAL_DIAG_ANI_STATS.
I .. stupidly added code to return HAL_ANI_STATS to HAL_DIAG_ANI_STATS.
I discovered this in a noisy environment when the returned values were
enough to .. well, make everything terrible.
So - restore functionality.
Tested:
* AR5416 (uses the AR5212 HAL), in a /very/ noisy 2GHz environment.
Enough to trigger ANI to get upset and generate useful data.
|
| 280942 |
01-Apr-2015 |
adrian |
Use the HAL API for returning ar5212AniState, rather than just dumping
AniState itself.
|
| 280940 |
01-Apr-2015 |
adrian |
Start the process of migrating the ANI statistics out of the HALs and into
the top-level HAL.
The athstats program is blindly using a copy of the ar5212 ANI stats structure
to pull out ANI statistics/state and this is problematic for the AR9300
HAL.
So:
* Define HAL_ANI_STATS and HAL_ANI_STATE
* Use HAL_ANI_STATS inside the AR5212 HAL
This commit doesn't (yet) convert the ar5212AniState -> HAL_ANI_STATE when
exporting it to userland; that'll come in the next commit.
|
| 280828 |
29-Mar-2015 |
adrian |
Move the HAL channel survey support out to be in the top-level HAL,
rathe than private in each HAL module.
Whilst here, modify ath_hal_private to always have the per-channel
noisefloor stats, rather than conditionally. This just makes
life easier in general (no strange ABI differences between different
HAL compile options.)
Add a couple of methods (clear/reset, add) rather than using
hand-rolled versions of things.
|
| 280827 |
29-Mar-2015 |
adrian |
Add a new field to HAL_ANISTATS - the extension channel busy count.
This is only used by the AR9300 HAL for now - but just be careful if
you decide to recompile the kernel with NO_CLEAN=1.
|
| 277821 |
28-Jan-2015 |
adrian |
Add a new HAL capability - required to compile the updated AR9300
HAL i have lying about.
|
| 277290 |
17-Jan-2015 |
adrian |
Oops; correctly reload the CCA registers with the uncapped value
in prep for the next NF calibration pass.
Totally missing braces. Damn you C.
Submitted by: Sascha Wildner <swildner@dragonflybsd.org>
MFC after: 1 week
|
| 277275 |
16-Jan-2015 |
adrian |
Add bluetooth MCI coexistence HAL methods - used for AR9462 and AR9565 NICs.
It's found, amongst other things, in the Acer Chromebook (Intel)
devices.
Tested:
* AR9462 (WB222)
Obtained from: Qualcomm Atheros
|
| 274922 |
23-Nov-2014 |
dim |
Fix the following -Werror warning from clang 3.5.0, while building the
ath kernel module:
sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: error: taking the absolute value of unsigned type 'unsigned int' has no effect [-Werror,-Wabsolute-value]
if (abs(lp[0] * EEP_SCALE - target) < EEP_DELTA) {
^
sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs'
#define abs(_a) __builtin_abs(_a)
^
sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: note: remove the call to '__builtin_abs' since unsigned values cannot be negative
sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs'
#define abs(_a) __builtin_abs(_a)
^
1 error generated.
This warning occurs because both lp[0] and target are unsigned, so the
subtraction expression is also unsigned, and calling abs() is a no-op.
However, the intention was to look at the absolute difference between
the two unsigned quantities. Introduce a small static function to
clarify what we're doing, and call that instead.
Reviewed by: adrian
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D1212
|
| 272292 |
30-Sep-2014 |
adrian |
Add initial support for the AR9485 CUS198 / CUS230 variants.
These variants have a few differences from the default AR9485 NIC,
namely:
* a non-default antenna switch config;
* slightly different RX gain table setup;
* an external XLNA hooked up to a GPIO pin;
* (and not yet done) RSSI threshold differences when
doing slow diversity.
To make this possible:
* Add the PCI device list from Linux ath9k, complete with vendor and
sub-vendor IDs for various things to be enabled;
* .. and until FreeBSD learns about a PCI device list like this,
write a search function inspired by the USB device enumeration code;
* add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this
to initialise its local driver parameters upon attach;
* copy these parameters over in the AR9300 HAL;
* don't default to override the antenna switch - only do it for
the chips that require it;
* I brought over ar9300_attenuation_apply() from ath9k which is cleaner
and easier to read for this particular NIC.
This is a work in progress. I'm worried that there's some post-AR9380
NIC out there which doesn't work without the antenna override set as
I currently haven't implemented bluetooth coexistence for the AR9380
and later HAL. But I'd rather have this code in the tree and fix it
up before 11.0-RELEASE happens versus having a set of newer NICs
in laptops be effectively RX deaf.
Tested:
* AR9380 (STA)
* AR9485 CUS198 (STA)
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 269760 |
09-Aug-2014 |
adrian |
Bump the HAL_REGRANGE fields from 16 bit to 32 bit.
The AR9380 and later chips have a 128KiB register window, so the register
read diag api needs changing.
The tools are about to be updated as well. No, they're not backwards
compatible.
|
| 269749 |
09-Aug-2014 |
adrian |
Add two new debug mark entries for chip power configuration.
|
| 265348 |
05-May-2014 |
adrian |
Add Atheros AR1111 support to the HAL.
This seems to probe/attach as an AR9485 and thus nothing else besides
adding the device id seems to be required.
ath0: <Atheros AR1111> mem 0xf4800000-0xf487ffff irq 19 at device 0.0 on pci5
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 RX streams; 1 TX streams
ath0: AR9485 mac 576.1 RF5110 phy 1926.8
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000
The NIC I have here is a 1 antenna, 2GHz only device.
Thankyou to Jim Thompson <jim@netgate.com> for the AR1111 NIC.
Tested:
* AR1111 (pretending not to be an AR9485, but failing miserably);
STA mode with powersave.
Relnotes: yes
Sponsored by: Netgate
|
| 265112 |
30-Apr-2014 |
adrian |
* Only update ah_powerMode if we're setting the chip sleep state.
Some code will appear soon that is actually setting the chip powerstate
separate from the self-generated frames power state.
* Allow the AR5416 family chips to actually have the power state changed
from the self generated state change.
Tested (STA mode):
* AR5210
* AR5211
* AR5412
* AR5413
* AR5416
* AR9285
|
| 265033 |
27-Apr-2014 |
adrian |
Note that the AR5416 and later hardware supports the MYBEACON RX filter.
|
| 265032 |
27-Apr-2014 |
adrian |
* Add a new capability which returns whether the hardware supports
the MYBEACON RX filter (only receive beacons which match the BSSID)
or all beacons on the current channel.
* Add the relevant RX filter entry for MYBEACON.
Tested:
* AR5416, STA
* AR9285, STA
TODO:
* once the code is in -HEAD, just make sure that the code which uses it
correctly sets BEACON for pre-AR5416 chips.
Obtained from: QCA, Linux ath9k
|
| 265031 |
27-Apr-2014 |
adrian |
Program the AR_TSFOOR_THRESHOLD register with a default lifted from
the QCA HAL.
This fires off an interrupt if the TSF from the AP / IBSS peer is
wildly out of range. I'll add some code to the ath(4) driver soon
which makes use of this.
TODO:
* verify this didn't break TDMA!
|
| 265030 |
27-Apr-2014 |
adrian |
Fix the AR_SLEEP1 and AR_SLEEP2 definitions. Oops!
Tested:
* AR9285, STA
* AR5416, STA
Obtained from: QCA, Linux ath9k
|
| 265029 |
27-Apr-2014 |
adrian |
Do a read-after-write to ensure the interrupt register update is flushed
to the hardware.
The QCA HAL has a comment noting that if this isn't done, modifications
to AR_IMR_S2 before AR_IMR is flushed may produce spurious interrupts.
Obtained from: QCA
|
| 264900 |
24-Apr-2014 |
adrian |
Fix the AR5211 power mode tracking stuff.
Tested:
* AR5211, STA mode
|
| 264899 |
24-Apr-2014 |
adrian |
Fix the AR5210 HAL code to store the association ID and restore it
upon reset.
Tested:
* AR5210, STA mode
|
| 264898 |
24-Apr-2014 |
adrian |
Fix ah_powerMode to be set at the correct place for the AR5210.
Tested:
* AR5210, STA mode
|
| 263618 |
22-Mar-2014 |
adrian |
Also set the AR5212 HAL power mode tracking in the right spot.
Tested:
* D-Link DWL-G650 NIC (AR2413), STA mode
|
| 263417 |
20-Mar-2014 |
adrian |
Shuffle ah_powerMode to be in a sane spot for the given power operation.
This way the state changes from sleep->awake before the registers are poked
and from awake->sleep after the registers are poked.
This way spurious warnings aren't printed by my (to be committed)
debugging code.
Tested:
* AR5416, STA
|
| 262969 |
10-Mar-2014 |
adrian |
Migrate the chip power mode status to public ath_hal, rather than the
private per-chip HAL.
This allows the ah_osdep.[ch] code to check whether the power state is
valid for doing chip programming.
It should be a no-op for normal driver work but it does require a
clean kernel/module rebuild, as the size of HAL structures have changed.
Now, this doesn't track whether the hardware is ACTUALLY awake,
as NETWORK_SLEEP wakes the chip up for a short period when traffic
is received. This doesn't actually set the power mode to AWAKE, so
we have to be careful about how we touch things.
But it's enough to start down the path of implementing station mode
chipset power savings, as a large part of the silliness is making
sure the chip is awake during periodic calibration / ANI and
random places where transmit may be occuring. I'd rather not a repeat
of debugging power save on ath9k, where races with calibration
and transmit path stuff took a couple years to shake out.
Tested:
* AR5416, STA mode
|
| 262375 |
23-Feb-2014 |
hiren |
PicoStation M2HP presents reg domain 0x2a which is not found in atheros or linux
reference code. Add this workaround for now.
Reviewed by: adrian
|
| 256139 |
08-Oct-2013 |
adrian |
Add channel survey support to the AR5212 HAL.
The AR5212 series of MACs implement the same channel counters as the
later 11n chips - except, of course, the 11n specific counter (extension
channel busy.)
This allows users of these NICs to use 'athsurvey' to see how busy their
current channel is.
Tested:
* AR5212, AR2413 NICs, STA mode
Approved by: re@ (gleb)
|
| 252236 |
26-Jun-2013 |
adrian |
Add a HAL local routine to map the 2GHz channel frequency to an IEEE
channel.
There's some HAL code in the AR9300 HAL that requires a back-mapping
and using the net80211 code isn't appropriate here.
|
| 251656 |
12-Jun-2013 |
adrian |
Set the antenna "config group" field.
The reference HAL pushes a config group parameter to the driver layer
to inform it which particular chip behaviour to implement.
This particular value tags it as an AR9285.
|
| 251655 |
12-Jun-2013 |
adrian |
Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver.
The AR9485 chip and AR933x SoC both implement LNA diversity.
There are a few extra things that need to happen before this can be
flipped on for those chips (mostly to do with setting up the different
bias values and LNA1/LNA2 RSSI differences) but the first stage is
putting this code into the driver layer so it can be reused.
This has the added benefit of making it easier to expose configuration
options and diagnostic information via the ioctl API. That's not yet
being done but it sure would be nice to do so.
Tested:
* AR9285, with LNA diversity enabled
* AR9285, with LNA diversity disabled in EEPROM
|
| 251643 |
12-Jun-2013 |
adrian |
Remove the AR9285 specific structure for LNA diversity and use the HAL.
The AR9300 HAL update included the LNA diversity configuration information
so it can be used in the AR9485 configuration code.
|
| 251483 |
07-Jun-2013 |
adrian |
Add bluetooth fixes to the AR5416/AR92xx HAL:
* Call the bluetooth setup function during the reset path, so the bluetooth
settings are actually initialised.
* Call the AR9285 diversity functions during bluetooth setup; so the AR9285
diversity and antenna configuration registers are correctly programmed
* Misc debugging info.
Tested:
* AR9285+AR3011 bluetooth combo; this code itself doesn't enable bluetooth
coexistence but it's part of what I'm currently using.
|
| 251442 |
05-Jun-2013 |
adrian |
Enable slow diversity combining for the AR9285.
Now that I understand what's going on - and the RX antenna array maps
to what the receive LNA configuration actually is - I feel comfortable
in enabling this.
If people do have issues with this, there's enough debugging now available
that we have a chance to diagnose it without writing it up as 'weird
crap.'
Tested:
* AR9285 STA w/ diversity combining enabled in EEPROM
TODO:
* (More) testing in hostap mode
|
| 251441 |
05-Jun-2013 |
adrian |
As a temporary work-around (read: until there's a nice API for exposing
and controlling this form of antenna diversity) - print out the AR9285
antenna diversity configuration at attach time.
This will help track down and diagose if/when people have connectivity
issues on cards (eg if they connect a single antenna to LNA1, yet the
card has RX configured to only occur on LNA2.)
Tested:
* AR9285 w/ antenna diversity enabled in EEPROM;
* AR9285 w/ antenna diversity disabled in EEPROM; mapping only to a
single antenna (LNA1.)
|
| 251400 |
05-Jun-2013 |
adrian |
Add a new capability flag to announce that the chip implements LNA mixing
for the RX path.
This is different to the div comb HAL flag, that says it actually
can use this for RX diversity (the "slow" diversity path implemented
but disabled in the AR9285 HAL code.)
Tested:
* AR9285, STA operation
|
| 251399 |
05-Jun-2013 |
adrian |
Document the AR9285/AR9485 LNA configuration information that's
stored in the ctl/ext RSSI field for chain 2.
Tested:
* AR9285, STA
|
| 251360 |
04-Jun-2013 |
adrian |
Add the combined (mixed) diversity support capability bit for the
AR9285/AR9485.
|
| 251340 |
03-Jun-2013 |
adrian |
Fix receive on the AR9285 (Kite) with only one antenna connected.
The main problem here is that fast and driver RX diversity isn't actually
configured; I need to figure out why that is. That said, this makes
the single-antenna connected AR9285 and AR2427 (AR9285 w/ no 11n) work
correctly.
PR: kern/179269
|
| 250856 |
21-May-2013 |
adrian |
Fix build break - the SetCapability calls return HAL_BOOL,
not HAL_STATUS.
|
| 250841 |
21-May-2013 |
adrian |
Extend the TXOP enforce capability to support checking whether it's
supported.
|
| 250824 |
20-May-2013 |
adrian |
Make the HT rate duration calculation work for MCS rates > 15.
|
| 250346 |
08-May-2013 |
adrian |
Implement STBC receive frame statistics.
The AR9280 and later can receive STBC. This adds some statistics
tracking to count these frames.
A patch to athstats will be forthcoming.
|
| 250166 |
02-May-2013 |
adrian |
Add device identification and probe/attach support for the QCA9565.
The QCA9565 is a 1x1 2.4GHz 11n chip with integrated on-chip bluetooth.
The AR9300 HAL already has support for this chip; it just wasn't
included in the probe/attach path.
Tested:
* This commit brought to you over a QCA9565 wifi connection from
FreeBSD.
* .. ie, basic STA, pings, no iperf or antenna diversity checking just yet.
|
| 249580 |
17-Apr-2013 |
adrian |
Setup needed tables for TPC on AR5416->AR9287 chips.
* Add ah_ratesArray[] to the ar5416 HAL state - this stores the maximum
values permissable per rate.
* Since different chip EEPROM formats store this value in a different place,
store the HT40 power detector increment value in the ar5416 HAL state.
* Modify the target power setup code to store the maximum values in the
ar5416 HAL state rather than using a local variable.
* Add ar5416RateToRateTable() - to convert a hardware rate code to the
ratesArray enum / index.
* Add ar5416GetTxRatePower() - which goes through the gymnastics required
to correctly calculate the target TX power:
+ Add the power detector increment for ht40;
+ Take the power offset into account for AR9280 and later;
+ Offset the TX power correctly when doing open-loop TX power control;
+ Enforce the per-rate maximum value allowable.
Note - setting a TPC value of 0x0 in the TX descriptor on (at least)
the AR9160 resulted in the TX power being very high indeed. This didn't
happen on the AR9220. I'm guessing it's a chip bug that was fixed at
some point. So for now, just assume the AR5416/AR5418 and AR9130 are
also suspect and clamp the minimum value here at 1.
Tested:
* AR5416, AR9160, AR9220 hostap, verified using (2GHz) spectrum analyser
* Looked at target TX power in TX descriptor (using athalq) as well as TX
power on the spectrum analyser.
TODO:
* The TX descriptor code sets the target TX power to 0 for AR9285 chips.
I'm not yet sure why. Disable this for TPC and ensure that the TPC
TX power is set.
* AR9280, AR9285, AR9227, AR9287 testing!
* 5GHz testing!
Quirks:
* The per-packet TPC code is only exercised when the tpc sysctl is set
to 1. (dev.ath.X.tpc=1.) This needs to be done before you bring the
interface up.
* When TPC is enabled, setting the TX power doesn't end up with a call
through to the HAL to update the maximum TX power. So ensure that
you set the TPC sysctl before you bring the interface up and configure
a lower TX power or the hardware will be clamped by the lower TX
power (at least until the next channel change.)
Thanks to Qualcomm Atheros for all the hardware, and Sam Leffler for use
of his spectrum analyser to verify the TX channel power.
|
| 249579 |
17-Apr-2013 |
adrian |
Use the TPC bank by default for AR9160.
Tested:
* AR9160, hostap, verified TX power using (2GHz) spectrum analyser
TODO:
* 5GHz verification!
|
| 249517 |
15-Apr-2013 |
adrian |
Now that the register definitions are in -HEAD, enable this.
|
| 249516 |
15-Apr-2013 |
adrian |
Bring over some AR9271 register definitions from the QCA HAL.
Obtained from: Qualcomm Atheros
|
| 249137 |
05-Apr-2013 |
adrian |
Add a new TX power field - it's inteded to be used where low TX power
is configured for higher rates (lower than max) but higher TX power
is configured for the lower rates, above the configured cap, to improve
long distance behaviour.
|
| 249131 |
05-Apr-2013 |
adrian |
HAL additions to enable MCI Bluetooth coexistence in the AR9300 HAL.
* Add the rest of the missing GPIO output mux types;
* Add in a new debug category;
* And a new MCI btcoex configuration option in ath_hal.ah_config
Obtained from: Qualcomm Atheros
|
| 248677 |
24-Mar-2013 |
adrian |
Add new regulatory domain.
Obtained from: Qualcomm Atheros
|
| 248670 |
23-Mar-2013 |
adrian |
CABQ calculation changes to try and fix some weird corner cases leading
to stuck beacons.
* Set the cabq readytime (ie, how long to burst for) to 50% of the total
beacon interval time
* fix the cabq adjustment calculation based on how the beacon offset is
calculated (the SWBA/DBA time offset.)
This is all still a bit magic voodoo but it does seem to have further
quietened issues with missed/stuck beacons under my local testing.
In any case, it better matches what the reference HAL implements.
Obtained from: Qualcomm Atheros
|
| 248182 |
12-Mar-2013 |
adrian |
Use the correct antenna configuration variable here. "diversity" just
controls whether it's on or off.
Found by: clang
|
| 248129 |
10-Mar-2013 |
adrian |
Add another register definition bit - whether to populate EVM or PLCP
data in the RX status descriptor.
Obtained from: Qualcomm Atheros
|
| 247774 |
04-Mar-2013 |
adrian |
add a method to set/clear the VMF field in the TX descriptor.
Obtained from: Qualcomm Atheros
|
| 247366 |
27-Feb-2013 |
adrian |
Add in the STBC TX/RX capability support into the HAL and driver.
The HAL already included the STBC fields; it just needed to be exposed
to the driver and net80211 stack.
This should allow single-stream STBC TX and RX to be negotiated; however
the driver and rate control code currently don't do anything with it.
|
| 247287 |
25-Feb-2013 |
adrian |
Part #2 of the TX chainmask changes:
* Remove ar5416UpdateChainmasks();
* Remove the TX chainmask override code from the ar5416 TX descriptor
setup routines;
* Write a driver method to calculate the current chainmask based on the
operating mode and update the driver state;
* Call the HAL chainmask method before calling ath_hal_reset();
* Use the currently configured chainmask in the TX descriptors rather than
the hardware TX chainmasks.
Tested:
* AR5416, STA/AP mode - legacy and 11n modes
|
| 247286 |
25-Feb-2013 |
adrian |
Begin adding support to explicitly set the current chainmask.
Right now the only way to set the chainmask is to set the hardware
configured chainmask through capabilities. This is fine for forcing
the chainmask to be something other than what the hardware is capable
of (eg to reduce TX/RX to one connected antenna) but it does change what
the HAL hardware chainmask configuration is.
For operational mode changes, it (may?) make sense to separately control
the TX/RX chainmask.
Right now it's done as part of ar5416_reset.c - ar5416UpdateChainMasks()
calculates which TX/RX chainmasks to enable based on the operating mode.
(1 for legacy and whatever is supported for 11n operation.) But doing
this in the HAL is suboptimal - the driver needs to know the currently
configured chainmask in order to correctly enable things for each
TX descriptor. This is currently done by overriding the chainmask
config in the ar5416 TX routines but this has to disappear - the AR9300
HAL support requires the driver to dynamically set the TX chainmask based
on the TX power and TX rate in order to meet mini-PCIe slot power
requirements.
So:
* Introduce a new HAL method to set the operational chainmask variables;
* Introduce null methods for the previous generation chipsets;
* Add new driver state to record the current chainmask separate from
the hardware configured chainmask.
Part #2 of this will involve disabling ar5416UpdateChainMasks() and moving
it into the driver; as well as properly programming the TX chainmask
based on the currently configured HAL chainmask.
Tested:
* AR5416, STA mode - both legacy (11a/11bg) and 11n rates - verified
that AR_SELFGEN_MASK (the chainmask used for self-generated frames like
ACKs and RTSes) is correct, as well as the TX descriptor contents is
correct.
|
| 247145 |
22-Feb-2013 |
adrian |
Add a workaround for AR5416, AR9130 and AR9160 chipsets - work around
an incorrectly calculated RTS duration value when transmitting aggregates.
These earlier 802.11n NICs incorrectly used the ACK duration time when
calculating what to put in the RTS of an aggregate frame. Instead it
should have used the block-ack time. The result is that other stations
may not reserve enough time and start transmitting _over_ the top of
the in-progress blockack field. Tsk.
This workaround is to popuate the burst duration field with the delta
between the ACK duration the hardware is using and the required duration
for the block-ack. The result is that the RTS field should now contain
the correct duration for the subsequent block-ack.
This doesn't apply for AR9280 and later NICs.
Obtained from: Qualcomm Atheros
|
| 247092 |
21-Feb-2013 |
adrian |
Be slightly more paranoid with the TX DMA buffer maximum threshold.
Specifically - never jack the TX FIFO threshold up to the absolute
maximum; always leave enough space for two DMA transactions to
appear.
This is a paranoia from the Linux ath9k driver. It can't hurt.
Obtained from: Linux ath9k
|
| 247073 |
21-Feb-2013 |
adrian |
Remove this unneeded printf(), sorry!
|
| 247033 |
20-Feb-2013 |
adrian |
Configure larger TX FIFO default and maximum level values.
This has reduced the number of TX delimiter and data underruns when
doing large UDP transfers (>100mbit).
This stops any HAL_INT_TXURN interrupts from occuring, which is a good
sign!
Obtained from: Qualcomm Atheros
|
| 247030 |
20-Feb-2013 |
adrian |
If any of the TX queues have underrun reporting enabled, enable
HAL_INT_TXURN in the interrupt mask register.
This should now allow for TXURN interrupts to be posted.
|
| 246579 |
09-Feb-2013 |
adrian |
The encryption type field needs to be preserved for each descriptor
making up a frame, in both a sub-frame and for all frames in an
aggregate.
Tested:
* AR5416, STA mode
|
| 245952 |
26-Jan-2013 |
pfg |
Clean some 'svn:executable' properties in the tree.
Submitted by: Christoph Mallon
MFC after: 3 days
|
| 245281 |
11-Jan-2013 |
adrian |
Place-holders for enable/active parameter flags.
|
| 244950 |
02-Jan-2013 |
adrian |
Fix the short repeat option code to not flip the option to 0 when
we call this w/ NOVAL set.
|
| 244943 |
02-Jan-2013 |
adrian |
Bring over the basic spectral scan framework code from Qualcomm Atheros.
This includes the HAL routines to setup, enable/activate/disable spectral
scan and configure the relevant registers.
This still requires driver interaction to enable spectral scan reporting.
Specifically:
* call ah_spectralConfigure() to configure and enable spectral scan;
* .. there's currently no way to disable spectral scan... that will have
to follow.
* call ah_spectralStart() to force start a spectral report;
* call ah_spectralStop() to force stop an active spectral report.
The spectral scan results appear as PHY errors (type 0x5 on the AR9280,
same as radar) but with the spectral scan bit set (0x10 in the last byte
of the frame) identifying it as a spectral report rather than a radar
FFT report.
Caveats:
* It's likely quite difficult to run spectral _and_ radar at the same
time. Enabling spectral scan disables the radar thresholds but
leaves radar enabled. Thus, the driver (for now) needs to ensure
that only one or the other is enabled.
* .. it needs testing on HT40 mode.
Tested:
* AR9280 in STA mode, HT/20 only
TODO:
* Test on AR9285, AR9287;
* Test in both HT20 and HT40 modes;
* .. all the driver glue.
Obtained from: Qualcomm Atheros
|
| 244854 |
30-Dec-2012 |
adrian |
Add the initial HAL glue for the spectral analysis support.
* Finish adding the HAL capability to announce whether a NIC supports
spectral scan or not;
* Add spectral scan methods to the HAL structure;
* Add HAL_SPECTRAL_PARAM for configuration of the spectral scan logic.
The capability ID and HAL_SPECTRAL_PARAM struct are from Qualcomm
Atheros.
|
| 244853 |
30-Dec-2012 |
adrian |
Add spectral scan capability.
|
| 244768 |
28-Dec-2012 |
adrian |
Add the AR9280 and later spectral scan register definitions.
Obtained from: Linux ath9k, Qualcomm Atheros (datasheet)
|
| 244767 |
28-Dec-2012 |
adrian |
Add radar_bin_thresh_sel (bit 24:26), which defines when
to consider the radar FFT report bins as "strong".
|
| 244529 |
21-Dec-2012 |
adrian |
Note why fast frames is disabled for 802.11n NICs now.
It actually works, but net80211 handles A-MPDU and Fast frames
incorrectly; it tries enabling both in some instances, with tragic
results.
|
| 243975 |
07-Dec-2012 |
adrian |
Add XC900 SKU mapping.
|
| 243843 |
04-Dec-2012 |
adrian |
Methodise the BT diversity configuration function; so the AR9285
can correctly override it.
This was missed in the previous commit.
|
| 243842 |
04-Dec-2012 |
adrian |
Override the BT coex parameter function for the AR9285.
|
| 243841 |
04-Dec-2012 |
adrian |
Reformat/reindent.
|
| 243840 |
03-Dec-2012 |
adrian |
Add and tie in the AR5416 bluetooth coexistence methods into the HAL.
|
| 243743 |
01-Dec-2012 |
adrian |
Add a new HAL capability - check and enforce whether the NIC supports
enforcing the TXOP and TBTT limits:
* Frames which will overlap with TBTT will not TX;
* Frames which will exceed TXOP will be filtered.
This is not enabled by default; it's intended to be enabled by the
TDMA code on 802.11n capable chipsets.
|
| 243589 |
27-Nov-2012 |
adrian |
Add a note about the magic values here; don't change them.
|
| 243588 |
27-Nov-2012 |
adrian |
When programming the beacon timer configuration, be very explicit about
what the maximum legal values are.
The current beacon timer configuration from TDMA wraps things at
HAL_BEACON_PERIOD-1 TU. For the 11a chips this is fine, but for
the 11n chips it's not enough resolution. Since the 11a chips have a
limit on what's "valid", just enforce this so when I do write larger
values in, they get suitably wrapped before programming.
Tested:
* AR5413, TDMA slave
Todo:
* Run it for a (lot) longer on a clear channel, ensure that no strange
slippages occur.
* Re-validate this on STA configurations, just to be sure.
|
| 243472 |
24-Nov-2012 |
adrian |
Add a comment which covers what's going on with the 64 bit TSF write.
After chatting with the MAC team, the TSF writes (at least on the 11n
MACs, I don't know about pre-11n MACs) are done as 64 bit writes that
can take some time. So, doing a 32 bit TSF write is definitely not
supported. Leave a comment here which explains that.
Whilst here, add a comment which outlines that after a reset or TSF
write, the TSF write may take a while (up to 50uS) to update.
A write or reset shouldn't be done whilst the previous one is in
flight. Also (and this isn't currently done) a read shouldn't
occur until the SLEEP32_TSF_WRITE_STAT is clear. Right now we're
not doing that, mostly because we haven't been doing lots of TSF
resets/writes until recently.
|
| 243424 |
23-Nov-2012 |
adrian |
Implement a HAL method to set a 64 bit TSF value.
TODO: implement it (and test) for the AR5210/AR5211.
|
| 243317 |
19-Nov-2012 |
adrian |
Disable WEP hardware encryption on the AR5210, in order to allow other
encryption types.
The AR5210 only has four WEP key slots, in contrast to what the
later MACs have (ie, the keycache.) So there's no way to store a "clear"
key.
Even if the driver is taught to not allocate CLR key entries for
the AR5210, the hardware will actually attempt to decode the encrypted
frames with the (likely all 0!) WEP keys.
So for now, disable the hardware encryption entirely and just so it
all in software. That allows both WEP -and- WPA to actually work.
If someone wishes to try and make hardware WEP _but_ software WPA work,
they'll have to create a HAL capability to enable/disable hardware
encryption based on the current STA/Hostap mode. However, making
multi-vap work with one WEP and one WPA VAP will require hardware
encryption to be disabled anyway.
|
| 243249 |
18-Nov-2012 |
adrian |
Remove this include, it isn't needed.
|
| 243174 |
17-Nov-2012 |
adrian |
Correctly populate the RTS field.
Tested:
* AR5210, STA mode, RTS enabled
|
| 243173 |
17-Nov-2012 |
adrian |
* Remove ah_desc.h, it's not needed
* Add some shifts that I'm using in userspace (athalq.)
However, this exposes a fun little bug..
|
| 243169 |
17-Nov-2012 |
adrian |
.. include ah_desc.h here now.
|
| 243168 |
17-Nov-2012 |
adrian |
Remove the ah_desc.h reference; it's not needed.
I'm using these descriptor header files in userland and I'm trying to
avoid populating a compatibility ah_desc.h file.
|
| 243164 |
16-Nov-2012 |
adrian |
I'm not sure why ah_desc.h was required here, but it doesn't _need_
to be. So, just toss it.
There's no options or ah_desc fields in here.
Whilst I'm here, fix up the #ifdef and #define to mach.
|
| 242689 |
07-Nov-2012 |
adrian |
Add new HAL configuration features for the updated AR9300 HAL.
|
| 242625 |
05-Nov-2012 |
dim |
Remove duplicate const specifiers in many drivers (I hope I got all of
them, please let me know if not). Most of these are of the form:
static const struct bzzt_type {
[...list of members...]
} const bzzt_devs[] = {
[...list of initializers...]
};
The second const is unnecessary, as arrays cannot be modified anyway,
and if the elements are const, the whole thing is const automatically
(e.g. it is placed in .rodata).
I have verified this does not change the binary output of a full kernel
build (except for build timestamps embedded in the object files).
Reviewed by: yongari, marius
MFC after: 1 week
|
| 242509 |
03-Nov-2012 |
adrian |
HAL API changes!
* introduce a new HAL API method to pull out the TX status descriptor
contents.
* Add num_delims to the 11n first aggr method. This isn't used by the
driver at the moment so it won't affect anything.
|
| 242412 |
31-Oct-2012 |
adrian |
Since the PLL changes aren't in here yet for the AR9130 half/quarter
rate support, disable it.
|
| 242411 |
31-Oct-2012 |
adrian |
Oops - this was incorrectly removed in a previous commit.
|
| 242409 |
31-Oct-2012 |
adrian |
Oops - missing from the last commit - add ANI immunity levels for AR9160.
Obtained from: Qualcomm Atheros
|
| 242408 |
31-Oct-2012 |
adrian |
HAL updates!
* Add some more ANI spur immunity levels.
* For AR5111 radios attached to an AR5212, limit the 5GHz channels
that are available. A later revision of the AR5111 supports the 4.9GHz
PSB channels but right now there's no check in place for the radio
revision.
If someone wants PSB support on AR5212+AR5111 radios then please let
me know and I'll add the relevant version check.
Obtained from: Qualcomm Atheros
|
| 242407 |
31-Oct-2012 |
adrian |
Add in the last random assortment of missing bits for the AR9380 HAL.
Obtained from: Qualcomm Atheros
|
| 242406 |
31-Oct-2012 |
adrian |
Add the emulation PCI device id - these days, 0xabcd shows up all over
the internet as "AR9380 and later which didn't get its PCI ID written
in at power-on", so it's hardly an unknown constant.
Obtained from: Qualcomm Atheros
|
| 241195 |
04-Oct-2012 |
adrian |
Implement the quarter rate fractional channel programming for the
AR5416 and AR9280, but leave it disabled by default.
TL;DR: don't enable this code at all unless you go through the process
of getting the NIC re-certified. This is purely to be used as a
reference and NOT a certified solution by any stretch of the imagination.
The background:
The AR5112 RF synth right up to the AR5133 RF synth (used on the AR5416,
derivative is used for the AR9130/AR9160) only implement down to 2.5MHz
channel spacing in 5GHz. Ie, the RF synth is programmed in steps of 2.5MHz
(or 5, 10, 20MHz.) So they can't represent the quarter rate channels
in the 4.9GHz PSB (which end in xxx2MHz and xxx7MHz). They support
fractional spacing in 2GHz (1MHz spacing) (or things wouldn't work,
right?)
So instead of doing this, the RF synth programming for the AR5112 and
later code will round to the nearest available frequency.
If all NICs were RF5112 or later, they'll inter-operate fine - they all
program the same. (And for reference, only the latest revision of the
RF5111 NICs do it, but the driver doesn't yet implement the programming.)
However:
* The AR5416 programming didn't at all implement the fractional synth
work around as above;
* The AR9280 programming actually programmed the accurate centre frequency
and thus wouldn't inter-operate with the legacy NICs.
So this patch:
* Implements the 4.9GHz PSB fractional synth workaround, exactly as the
RF5112 and later code does;
* Adds a very dirty workaround from me to calculate the same channel
centre "fudge" to the AR9280 code when operating on fractional frequencies
in 5GHz.
HOWEVER however:
It is disabled by default. Since the HAL didn't implement this feature,
it's highly unlikely that the AR5416 and AR928x has been tested in these
centre frequencies. There's a lot of regulatory compliance testing required
before a NIC can have this enabled - checking for centre frequency,
for drift, for synth spurs, for distortion and spectral mask compliance.
There's likely a lot of other things that need testing so please don't
treat this as an exhaustive, authoritative list. There's a perfectly good
process out there to get a NIC certified by your regulatory domain, please
go and engage someone to do that for you and pay the relevant fees.
If a company wishes to grab this work and certify existing 802.11n NICs
for work in these bands then please be my guest. The AR9280 works fine
on the correct fractional synth channels (49x2 and 49x7Mhz) so you don't
need to get certification for that. But the 500KHz offset hack may have
the above issues (spur, distortion, accuracy, etc) so you will need to
get the NIC recertified.
Please note that it's also CARD dependent. Just because the RF synth
will behave correctly doesn't at all mean that the card design will also
behave correctly. So no, I won't enable this by default if someone
verifies a specific AR5416/AR9280 NIC works. Please don't ask.
Tested:
I used the following NICs to do basic interoperability testing at
half and quarter rates. However, I only did very minimal spectrum
analyser testing (mostly "am I about to blow things up" testing;
not "certification ready" testing):
* AR5212 + AR5112 synth
* AR5413 + AR5413 synth
* AR5416 + AR5113 synth
* AR9280
|
| 240984 |
27-Sep-2012 |
adrian |
Track the last ANI TX/RX sample correctly.
This doesn't specifically fix the issue(s) i'm seeing in this 2GHz
environment (where setting/increasing spur immunity causes OFDM restart
errors to skyrocket through the roof; but leaving it at 0 would leave
the environment cleaner..)
Pointy-hat-to: me, for committing this broken code in the first place.
|
| 240625 |
18-Sep-2012 |
adrian |
Add a couple of accessor inline functions for state that exists in net80211.
Obtained from: Qualcomm Atheros
|
| 240623 |
17-Sep-2012 |
adrian |
Rename AH_MIMO_MAX_CHAINS to AH_MAX_CHAINS, for compatibility with
internal atheros HAL code.
|
| 240471 |
13-Sep-2012 |
adrian |
Don't use AR_PHY_MODE to setup half/quarter rate.
I'm not sure where in the deep, distant past I found the AR_PHY_MODE
registers for half/quarter rate mode, but unfortunately that doesn't
seem to work "right" for non-AR9280 chips.
Specifically:
* don't touch AR_PHY_MODE
* set the PLL bits when configuring half/quarter rate
I've verified this on the AR9280 (5ghz fast clock) and the AR5416.
The AR9280 works in both half/quarter rate; the AR5416 unfortunately
only currently works at half rate. It fails to calibrate on quarter rate.
|
| 240449 |
13-Sep-2012 |
adrian |
Enable fractional 5G mode on half/quarter rate channels.
Obtained from: Linux ath9k
|
| 240448 |
13-Sep-2012 |
adrian |
Flip on half/quarter rate support.
No, this isn't HT/5 and HT/10 support. This is the 11a half/quarter
rate support primarily used by the 4.9GHz and GSM band regulatory
domains.
This is definitely a work in progress.
TODO:
* everything in the last commit;
* lots more interoperability testing with the AR5212 half/quarter rate
support for the relevant chips;
* Do some interop testing on half/quarter rate support between _all_
the 11n chips - AR5416, AR9160, AR9280 (and AR9285/AR9287 when 2GHz
half/quarter rate support is coded up.)
|
| 240447 |
13-Sep-2012 |
adrian |
Introduce an AR5416 flavour of the IFS and mac usec/timing configuration
used when running the chips in half/quarter rate.
This sets up some default parameters which are then overridden by the
driver (which manually configures things like slot timing at interface
start time.)
Although this is a copy-and-modify from the AR5212 HAL, I did peek
at the reference HAL and the ath9k driver to see what they did.
Ath9k in particular doesn't hard-code this - instead, their version
of ar5416InitUserSettings() does all of the relevant math.
TODO:
* do the math, not hard code things!
* fix the mac clock calculation for the AR9287; since it runs the
MAC clock at a higher rate, requiring all the duration calculations
to change;
* Do a whole lot more validation for half/quarter rates.
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 240446 |
13-Sep-2012 |
adrian |
Call the ar5212SetCoverageClass() function for now.
Some of the math is a little wrong thanks to clocks in 11a mode running
at 44MHz when in fast clock mode (rather than 40MHz, which the chips
before AR9280 ran 11a in). That'll have to be addressed in a future commit.
|
| 240445 |
13-Sep-2012 |
adrian |
Add register defintions for the AR5416 TX/RX latency fields.
Obtained from: Qualcomm Atheros
|
| 240444 |
13-Sep-2012 |
adrian |
Compensate for half/quarter rate differences in MAC clock speed.
This fixes the incorrect slot (and likely ACK/RTS timeout) values
which I see when enabling half/quarter rate support on the AR9280.
The resulting math matches the expected calculated default values.
|
| 240001 |
02-Sep-2012 |
adrian |
AR5212 radar pulse fixes.
Fix the strong signal diversity capability setting - I had totally
messed up the indentation.
Set the default values to match what's in the .ini for now, rather than
what values I had previously gleaned from places. This seems to work
quite well for the early AR5212 NICs I have. Of course, later NICs
have different PHYs and the radar configuration is very card/board
dependent..
Tested:
* ath1: AR5212 mac 5.3 RF5111 phy 4.1
ath1: 2GHz radio: 0x0023; 5GHz radio: 0x0017
This detects 1, 5, 25, 50, 75, 100uS pulses reliably (with no interference.)
However, 10uS pulses don't detect reliably. That may be around the
transition between short and long pulses so some further tuning may
improve things.
|
| 239966 |
01-Sep-2012 |
adrian |
Fix the PHY / CRC error bug in the AR5212 HAL, which apparently also pops
up on (at least) the AR5413.
The 30 second summary - if a CRC error frame comes in during PHY error
processing, that CRC bit will be set for all subsequent frames until
a non-CRC error frame is processed.
So to allow for accurate PHY error processing (Radar, and ANI on the AR5212
HAL chips) just tag the frame as being both CRC and PHY - let the driver
decide what to do with it.
PR: kern/169362
|
| 239890 |
30-Aug-2012 |
adrian |
Migrate the AR9285 diversity configuration LNA configuration to use
some HAL definitions rather than local definitions.
The original source (ath9k) pulled this stuff from the QCA driver and
removed the HAL_* prefix. I'm just restoring the correct order of things.
Obtained from: Qualcomm Atheros
|
| 239803 |
29-Aug-2012 |
adrian |
Set the HAL combined antenna diversity capability if the AR9285
EEPROM settings allow it.
|
| 239802 |
29-Aug-2012 |
adrian |
Add a new capability bit - whether the hardware supports AR9285 style
combined diversity.
|
| 239801 |
29-Aug-2012 |
adrian |
Add AR5413 radar parameters and strong signal diversity capability.
This is a re-implementation based on the reference carrier code
for the AR5413.
Tested:
* Pulse detection for AR5212 and AR5413, to ensure the
correct behaviour for both chips
PR: kern/170904
Obtained from: Qualcomm Atheros
|
| 239800 |
29-Aug-2012 |
adrian |
Add a (temporarily located) definition.
|
| 239753 |
27-Aug-2012 |
adrian |
Ensure that all firstep values are available in ANI.
The comparison assumes maxFirstepLevel is a count, rather than a maximum
value. The array is 3 entries in size however 'maxFirstepLevel' is 2.
This bug also exists in the AR5212 HAL.
|
| 239752 |
27-Aug-2012 |
adrian |
Fix the debugging output to correctly log CCK errors.
|
| 239704 |
26-Aug-2012 |
adrian |
Move this magic check to only occur if no eeprom data is given.
Tested on:
* AP99 (AR7241+AR9287)
|
| 239703 |
26-Aug-2012 |
adrian |
Add EEPROM data hooks for the AR9287.
Tested:
* AP99 Reference board (AR7241 + AR9287)
|
| 239657 |
24-Aug-2012 |
adrian |
Correctly handle the "pe_enabled" flag - both when configuring DFS and
fetching the current DFS configuration.
PR: kern/170904
|
| 239643 |
24-Aug-2012 |
adrian |
Add default values for the NumTxMaps capability.
|
| 239642 |
24-Aug-2012 |
adrian |
Add the method to fetch the default DFS parameters for the AR5212 PHY.
I need to check whether new parameters were added for the AR5413 NIC.
PR: kern/170904
|
| 239638 |
24-Aug-2012 |
adrian |
Implement an API to fetch the default DFS parameters for the given chip.
The only chip this is currently implemented for is the AR5416 HAL family.
A follow-up commit will add AR5212 support.
PR: kern/170904
|
| 239637 |
24-Aug-2012 |
adrian |
Bring over some new EEPROM regulatory domain flags.
Obtained from: Qualcomm Atheros
|
| 239635 |
24-Aug-2012 |
adrian |
Oops, another copy/paste issue.
|
| 239634 |
24-Aug-2012 |
adrian |
Add ath_hal_get_curmode() - this is used by the Osprey HAL.
Obtained from: Qualcomm Atheros
|
| 239633 |
24-Aug-2012 |
adrian |
Add rfkill HAL accessor methods.
|
| 239632 |
24-Aug-2012 |
adrian |
Oops, fix copy/paste silliness.
|
| 239631 |
24-Aug-2012 |
adrian |
Add some more capabilities (unused at the present.)
Obtained from: Qualcomm Atheros
|
| 239630 |
24-Aug-2012 |
adrian |
Add the MFP capability to ath_hal_getcapability().
Obtained from: Qualcomm Atheros
|
| 239629 |
24-Aug-2012 |
adrian |
Add some more diagnostic codes.
Obtained from: Qualcomm Atheros
|
| 239628 |
24-Aug-2012 |
adrian |
Wrap this a little so it's slightly easier on the eyes.
|
| 239627 |
24-Aug-2012 |
adrian |
Add some new flags:
* mfp support;
* 4.9ghz support in the HAL;
* device type - specifically, the bus type and whether it's a HB63
NIC (which requires some subtle chainmask handling differences
in the AR5416 HAL.)
Obtained from: Qualcomm Atheros
|
| 239606 |
23-Aug-2012 |
adrian |
Add a placeholder and typedefs for MFP (management frame protection.)
Obtained from: Qualcomm Atheros
|
| 239605 |
23-Aug-2012 |
adrian |
Add some more interrupt handling bits.
Obtained from: Qualcomm Atheros
|
| 239604 |
23-Aug-2012 |
adrian |
Add AR9380 devid HAL definitions and probe/attach strings.
Obtained from: Device IDs are from Qualcomm Atheros
|
| 239603 |
23-Aug-2012 |
adrian |
Add chipset names.
|
| 239381 |
19-Aug-2012 |
adrian |
Extend the TX descriptor debug printing to be properly aware of
EDMA code.
* create a new TX EDMA descriptor struct to represent TX EDMA descriptors
when doing debugging;
* implement an EDMA printing function which:
+ hardcodes the TX map size to 4 for now;
+ correctly prints out the number of segments - there's one descriptor
for up to 4 buffers (segments), not one for each segment;
+ print out 4 DS buffer and len pointers;
+ print out the correct number of DWORDs in the TX descriptor.
TODO:
* Remove all of the hard-coded stuff. Ew.
|
| 239289 |
15-Aug-2012 |
adrian |
Bump up the rate control table size to incorporate 3 stream entries.
|
| 239288 |
15-Aug-2012 |
adrian |
Remove this comment, it's no longer relevant.
|
| 239287 |
15-Aug-2012 |
adrian |
Extend the duration calculations to work with three and four stream
rates.
|
| 239134 |
07-Aug-2012 |
adrian |
Commit device IDs for the (eventually upcoming) AR9380 HAL.
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 239053 |
05-Aug-2012 |
adrian |
Migrate the 802.11n ath_hal_chaintxdesc() API to use a buffer/segment
array, similar to what filltxdesc() uses.
This removes the last reference to ds_data in the TX path outside of
debugging statements. These need to be adjusted/fixed.
Tested:
* AR9280 STA/AP with iperf TCP traffic
|
| 239051 |
05-Aug-2012 |
adrian |
Migrate the ath_hal_filltxdesc() API to take a list of buffer/seglen values.
The existing API only exposes 'seglen' (the current buffer (segment) length)
with the data buffer pointer set in 'ds_data'. This is fine for the legacy
DMA engine but it won't work for the EDMA engines.
The EDMA engine has a significantly different TX descriptor layout.
* The legacy DMA engine had a ds_data pointer at the same offset in the
descriptor for both TX and RX buffers;
* The EDMA engine has no ds_data for RX - the data is DMAed after the
descriptor;
* The EDMA engine has support for 4 TX buffer/segment pairs in the TX
DMA descriptor;
* The EDMA TX completion is in a different FIFO, and the driver will
'link' the status completion entry to a QCU by a "QCU ID".
I don't know why it's just not filled in by the hardware, alas.
So given that, here are the changes:
* Instead of directly fondling 'ds_data' in ath_desc, change the
ath_hal_filltxdesc() to take an array of buffer pointers as well
as segment len pointers;
* The EDMA TX completion status wants a descriptor and queue id.
This (for now) uses bf_state.bfs_txq and will extract the hardware QCU
ID from that.
* .. and this is ugly and wasteful; it should change to just store
the QCU in the bf_state and save 3/7 bytes in the process.
Now, the weird crap:
* The aggregate TX path was using bf_state->bfs_txq for the TXQ, rather than
taking a function argument. I've tidied that up.
* The multicast queue frames get put on a software TXQ and then that is
appended to the hardware CABQ when appropriate. So for now, make sure
that bf_state->bfs_txq points at the CABQ when adding frames to the
multicast queue.
* .. but the multicast queue TX path for now doesn't use the software
queue and instead
(a) directly sets up the descriptor contents at that point;
(b) the frames on the vap->avp_mcastq are then just appended wholesale
to the CABQ.
So for now, I don't have to worry about making the multicast path
work with aggregation or the per-TID software queue. Phew.
What's left to do:
* I need to modify the 11n ath_hal_chaintxdesc() API to do the same.
I'll do that in a subsequent commit.
* Remove bf_state.bfs_txq entirely and store the QCU as appropriate.
* .. then do the runtime "is this going on the right HWQ?" checks using
that, rather than comparing pointer values.
Tested on:
* AR9280 STA/AP
* AR5416 STA/AP
|
| 238858 |
28-Jul-2012 |
adrian |
Flesh out the multi-rate retry capability.
The existing method for testing for MRR is to call the "SetupXTXDesc"
HAL method and see if it returns AH_TRUE or AH_FALSE. This capability
explicitly lists what number of multi-rate attempts are possible.
"1" means "one rate attempt supported".
|
| 238857 |
28-Jul-2012 |
adrian |
Commit missing #define from a previous check-in.
The AR9300 and later have an 8-deep TX FIFO for each hardware queue.
|
| 238843 |
27-Jul-2012 |
adrian |
Tidy up the TX status fields a little and add a couple new flags.
* shuffle things around so things fall on natural padding boundaries;
* add a couple of new flags to specify LDPC and whether to switch to the
low power RX chain configuration after this TX has completed.
Obtained from: Qualcomm Atheros
|
| 238842 |
27-Jul-2012 |
adrian |
Add STBC TX support for AR5416 HAL chips.
Specifically, however:
* AR9280 and later support 1-stream STBC RX;
* AR9280 and AR9287 support 1-stream STBC TX.
The STBC support isn't announced (yet) via net80211 and it isn't at all
chosen by the rate control code, so there's no real consumer of this
yet.
Obtained from: Qualcomm Atheros
|
| 238841 |
27-Jul-2012 |
adrian |
Add a STBC TX flag.
Obtained from: Qualcomm Atheros
|
| 238840 |
27-Jul-2012 |
adrian |
Add some comments about what the two fields mean.
|
| 238839 |
27-Jul-2012 |
adrian |
Introduce a couple more fields in the rate scenario setup as part of
(future) TPC support in the AR9300 HAL.
This is effectively a no-op for the moment as (a) TPC isn't really
supported, (b) the AR9300 HAL isn't yet public, and (c) the existing
HAL code doesn't use these fields.
Obtained from: Qualcomm Atheros
|
| 238838 |
27-Jul-2012 |
adrian |
Bring this API in line with what the reference driver and Linux ath9k
was doing.
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 238731 |
24-Jul-2012 |
adrian |
Add a new HAL method - the AR93xx and later NICs have a separate
TX descriptor ring for TX status completion. This API call will pass
the allocated buffer details to the HAL.
|
| 238607 |
19-Jul-2012 |
adrian |
Break out the TX descriptor link field into HAL methods.
The DMA FIFO chips (AR93xx and later) differ slightly to th elegacy
chips:
* The RX DMA descriptors don't have a ds_link field;
* The TX DMA descriptors have a ds_link field however at a different
offset.
This is a reimplementation based on what the reference driver and ath9k
does.
A subsequent commit will enable it in the TX and beacon paths.
Obtained from: Linux ath9k, Qualcomm Atheros
|
| 238349 |
10-Jul-2012 |
adrian |
Commit missing flags for the high/low priority (HP/LP) RX queues.
Noticed by: everyone
|
| 238333 |
10-Jul-2012 |
adrian |
Reorder these so they match the capability enum order.
|
| 238314 |
10-Jul-2012 |
adrian |
Add some AR9300 HAL descriptor definition changes.
* Add a couple of RX errors;
* Add the spectral scan PHY error code;
* extend the RX flags to be a 16 bit field, rather than an 8 bit field;
* Add a new RX flag.
Obtained from: Qualcomm Atheros
|
| 238280 |
09-Jul-2012 |
adrian |
Introduce the EDMA related HAL capabilities.
Whilst here, fix a typo in a previous commit.
Obtained from: Qualcomm Atheros
|
| 238278 |
09-Jul-2012 |
adrian |
Extend the RX HAL API to include the RX queue identifier.
The AR93xx and later chips support two RX FIFO queues - a high and low
priority queue.
For legacy chips, just assume the queues are high priority.
This is inspired by the reference driver but is a reimplementation of
the API and code.
|
| 238276 |
09-Jul-2012 |
adrian |
Extend the debugging flags to include some AR9300 HAL related options.
Obtained from: Qualcomm Atheros
|
| 237957 |
02-Jul-2012 |
adrian |
.. And fix another typo. Grr.
|
| 237956 |
02-Jul-2012 |
adrian |
Fix another typo.
|
| 237955 |
02-Jul-2012 |
adrian |
Fix typo.
|
| 237953 |
02-Jul-2012 |
adrian |
Bring over some further HAL capabilities from the Atheros HAL, as well
as an EDMA check function.
For the AR9003 and later NICs, different TX/RX DMA and descriptor handling
code will be conditional on the EDMA check.
Obtained from: Qualcomm Atheros
|
| 237874 |
01-Jul-2012 |
adrian |
Add in some further changes from the AR9300 HAL:
* Add a new ANI variable, for AR9003 and later chips;
* The AR9003 and later series chips support two RX queues now, so start
down the road of supporting that;
* Add some new TX queue types - uAPSD is possible on earlier chips,
but PAPRD is relevant to AR9003 and later.
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 237868 |
01-Jul-2012 |
adrian |
Migrate the MAC/BB hang structures out from ar5416_misc.h into the HAL.
The ar9300 HAL also uses these types, so it makes no sense to duplicate
them.
|
| 237866 |
01-Jul-2012 |
adrian |
Bring over capabilities for the AR9300 and later HAL.
|
| 237864 |
01-Jul-2012 |
adrian |
Fix the HAL debugging to only use one bit to mark a message as unmaskable.
Whilst I'm here, remove the duplication of the #define.
|
| 237626 |
27-Jun-2012 |
adrian |
Fix a subtle corner case surrounding the handling of OFDM restart along
with AMPDU aggregate delimiters.
If there's an OFDM restart during an aggregate, the hardware ACKs
the previous frame, but communicates the RXed frame to the hardware
as having had CRC delimiter error + OFDM_RESTART phy error.
The frame however didn't have a CRC error and since the hardware ACKed
the aggregate to the sender, it thinks the frame was received.
Since I have no idea how often this occurs in the real world, add a
debug statement so trigger whenever this occurs. I'd appreciate an
email if someone finds this particular situation is triggered.
|
| 237622 |
27-Jun-2012 |
adrian |
Bring over some new typedefs as part of the AR9300 HAL import.
|
| 237621 |
27-Jun-2012 |
adrian |
Remove duplicate entries.
|
| 237611 |
26-Jun-2012 |
adrian |
Bring over the initial 802.11n bluetooth coexistence support code.
The Linux ath9k btcoex code is based off of this code.
Note this doesn't actually implement functional btcoex; there's some
driver glue and a whole lot of verification that is required.
On the other hand, I do have the AR9285+BT and AR9287+BT NICs which
this code supports..
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 237521 |
24-Jun-2012 |
adrian |
On second thought, let's just set both CRC and PHY errors together on
frames that have it and let the upper layer sort it out.
PR: kern/169362
|
| 237519 |
24-Jun-2012 |
adrian |
Sometimes the AR5416 sends back radar PHY errors with both the PHY error
and the CRC error bits set. The radar payload is correct.
When this happens, the stack doesn't see them PHY error frames and
isn't interpreted as a PHY error. So, no radar detection and no radiotap
PHY error handling.
Now, this may introduce some weird issues if the MAC sends up some other
combination of CRC error + PHY error frames; this commit would break that
and mark them as PHY errors instead of CRC errors.
I may tinker with this a little more to pass radar/early radar/spectral
frames up as PHY errors if the CRC bit is set, to restore the previous
behaviour (where if CRC is set on a PHY error frame, it's marked as a CRC
error rather than PHY error.)
Tested on: AR5416, over the air, to a USRP N200 which is generating a
large number of a variety of radar pulses.
TODO: Test on AR9130, AR9160, AR9280 (and maybe radar pulses on
2GHz on AR9285/AR9287.)
PR: kern/169362
|
| 237184 |
17-Jun-2012 |
adrian |
AR9287 tidyups:
* Add an OS_A_REG_WRITE() routine - analog writes require a 100usec delay
on AR9280 and later, so create a method to do it.
* Use it for the AR9287 analog writes.
* Re-indent and style(9) the code.
|
| 237183 |
17-Jun-2012 |
adrian |
Add an disabled workaround for the AR9285SE.
This just requires a little HAL change (add a new config parameter) and
some glue in if_ath_pci.c, however I'm leaving this up for someone else
to do.
Obtained from: Qualcomm Atheros
|
| 237182 |
17-Jun-2012 |
adrian |
Bring over the AR9285 specific PCIe suspend/resume/ASPM workarounds.
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 237153 |
16-Jun-2012 |
adrian |
Shuffle some more fields in ath_buf so it's not too big.
This shaves off 20 bytes - from 288 bytes to 268 bytes.
However, it's still too big.
|
| 236039 |
26-May-2012 |
adrian |
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
|
| 236017 |
25-May-2012 |
adrian |
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
|
| 236009 |
25-May-2012 |
adrian |
* 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
|
| 235972 |
25-May-2012 |
adrian |
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.
|
| 235957 |
25-May-2012 |
adrian |
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).
|
| 235206 |
09-May-2012 |
adrian |
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..
|
| 234873 |
01-May-2012 |
adrian |
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.
|
| 234774 |
28-Apr-2012 |
adrian |
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.
|
| 234768 |
28-Apr-2012 |
adrian |
Although not strictly needed, quieten a compiler warning by a user.
|
| 234752 |
28-Apr-2012 |
adrian |
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.
|
| 234750 |
28-Apr-2012 |
adrian |
Fetch the channel survey code from the HAL.
This information is currently not being populated by any of the HAL
modules.
|
| 234749 |
28-Apr-2012 |
adrian |
Extend the HAL channel survey statistics:
* include ext_chan_busy;
* include ofdm/cck phy error counts, which aren't yet implemented.
|
| 234747 |
28-Apr-2012 |
adrian |
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
|
| 234692 |
26-Apr-2012 |
adrian |
Add the BT register definitions for AR9285/AR9287 BT coexistence.
Obtained from: Linux ath9k
|
| 234664 |
25-Apr-2012 |
adrian |
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.
|
| 234510 |
20-Apr-2012 |
adrian |
.. oops.
|
| 234508 |
20-Apr-2012 |
adrian |
"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.
|
| 234450 |
19-Apr-2012 |
adrian |
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.
|
| 234269 |
14-Apr-2012 |
adrian |
Both linux ath9k and the reference driver initialises the PLL here
during chip wakeup.
Obtained from: Linux ath9k, Atheros
|
| 234088 |
10-Apr-2012 |
adrian |
Squirrel away the SYNC interrupt in case we're doing interrupt debugging.
|
| 233900 |
04-Apr-2012 |
adrian |
Track and optionally log the actual sync interrupt cause.
These are involved in tracking host interface issues (ie, PCI/PCIe/AHB
interface.)
|
| 233895 |
04-Apr-2012 |
adrian |
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.
|
| 233887 |
04-Apr-2012 |
adrian |
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.
|
| 233885 |
04-Apr-2012 |
adrian |
Disable a specific Merlin hardware workaround which may cause hangs on some
PCIe controllers.
Obtained from: Atheros / Linux
|
| 233329 |
22-Mar-2012 |
adrian |
Sprinkle some style(9) things around.
|
| 231927 |
20-Feb-2012 |
adrian |
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
|
| 231864 |
17-Feb-2012 |
adrian |
Fix the return type.
Submitted by: arundel
Found by: clang/llvm
|
| 231709 |
14-Feb-2012 |
adrian |
Fix the usefir128 config bit flipping.
|
| 231708 |
14-Feb-2012 |
adrian |
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.
|
| 231371 |
10-Feb-2012 |
adrian |
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.
|
| 231368 |
10-Feb-2012 |
adrian |
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.
|
| 230847 |
31-Jan-2012 |
adrian |
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.
|
| 230791 |
30-Jan-2012 |
adrian |
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.
|
| 230147 |
15-Jan-2012 |
adrian |
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.
|
| 229791 |
07-Jan-2012 |
adrian |
.. the AR5416 HAL code touches the MIMO parts in HAL_CHANNEL,
so this is also needed.
Pointed out by: bz
|
| 229790 |
07-Jan-2012 |
adrian |
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.)
|
| 228980 |
30-Dec-2011 |
dim |
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
|
| 228893 |
26-Dec-2011 |
adrian |
AR5416 has 14 GPIO pins, from 0->13.
|
| 228889 |
26-Dec-2011 |
adrian |
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.
|
| 228837 |
23-Dec-2011 |
adrian |
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
|
| 228836 |
23-Dec-2011 |
adrian |
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
|
| 228834 |
23-Dec-2011 |
adrian |
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.
|
| 228833 |
23-Dec-2011 |
adrian |
Remove unused #define's.
Pointy hat to: adrian, for not properly reading things when he copied
ar9285.h to ar9287.h.
|
| 228817 |
22-Dec-2011 |
adrian |
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
|
| 228800 |
22-Dec-2011 |
dim |
Revert r228786. We'll need to work around the warnings in another way.
Requested by: adrian
MFC after: 1 week
|
| 228799 |
22-Dec-2011 |
dim |
Revert r228785. We'll need to work around the warnings in another way.
Requested by: adrian
MFC after: 1 week
|
| 228786 |
21-Dec-2011 |
dim |
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
|
| 228785 |
21-Dec-2011 |
dim |
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
|
| 228517 |
15-Dec-2011 |
adrian |
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.
|
| 228515 |
15-Dec-2011 |
adrian |
Use the correct RF version probe routine.
Obtained from: Atheros
Sponsored by: Hobnob, Inc.
|
| 227741 |
19-Nov-2011 |
adrian |
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.
|
| 227468 |
12-Nov-2011 |
adrian |
Disable writing to the extension CYCPWR1 register.
This seems to make ANI behave better on the AR5416/AR5418.
Sponsored by: Hobnob, Inc.
|
| 227434 |
11-Nov-2011 |
adrian |
Correct device id comments.
|
| 227411 |
09-Nov-2011 |
adrian |
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.
|
| 227410 |
09-Nov-2011 |
adrian |
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
|
| 227408 |
09-Nov-2011 |
adrian |
Commit a missing fix - the AR_SREV_KIWI_10_OR_LATER() check.
|
| 227405 |
09-Nov-2011 |
adrian |
Even though the HAL doesn't currently support Kiwi 1.0/1.1,
be "more correct" about the Kiwi setup.
Obtained from: Atheros
|
| 227388 |
09-Nov-2011 |
adrian |
* 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
|
| 227387 |
09-Nov-2011 |
adrian |
Tidy up the AR9287 HAL a tiny bit - fix up AR9280 references.
|
| 227381 |
09-Nov-2011 |
adrian |
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.
|
| 227380 |
09-Nov-2011 |
adrian |
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.
|
| 227379 |
09-Nov-2011 |
adrian |
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.
|
| 227378 |
09-Nov-2011 |
adrian |
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.
|
| 227377 |
09-Nov-2011 |
adrian |
.. and add some ANI fixes missing from the last ANI commit.
Obtained from: Atheros
Sponsored by: Hobnob, Inc.
|
| 227376 |
09-Nov-2011 |
adrian |
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.
|
| 227375 |
09-Nov-2011 |
adrian |
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.
|
| 227374 |
09-Nov-2011 |
adrian |
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
|
| 227373 |
09-Nov-2011 |
adrian |
Add in some more PCI/PCIe differentiation.
|
| 227372 |
09-Nov-2011 |
adrian |
Try to make it more obvious when users are using the PCI or PCIe versions of
the 11n chips.
|
| 227365 |
08-Nov-2011 |
adrian |
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.
|
| 227080 |
04-Nov-2011 |
adrian |
Call the correct chipset power routine when disabling the AR5416 and later NICs.
|
| 226767 |
25-Oct-2011 |
adrian |
Add in some more 11n related HAL methods.
|
| 226765 |
25-Oct-2011 |
adrian |
The AR5413 datasheet specifies that AR_TxIntrReq should be set consistently
for all frames, so do so.
|
| 226764 |
25-Oct-2011 |
adrian |
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.
|
| 226762 |
25-Oct-2011 |
adrian |
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.
|
| 226761 |
25-Oct-2011 |
adrian |
Fix an incorrect flag.
Obtained from: Atheros
|
| 226760 |
25-Oct-2011 |
adrian |
Save and restore the association ID across interface resets.
Obtained from: Atheros
MFC after: 1 week
|
| 226759 |
25-Oct-2011 |
adrian |
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
|
| 226758 |
25-Oct-2011 |
adrian |
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.
|
| 226489 |
18-Oct-2011 |
adrian |
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
|
| 226488 |
18-Oct-2011 |
adrian |
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
|
| 226487 |
18-Oct-2011 |
adrian |
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.
|
| 225957 |
04-Oct-2011 |
adrian |
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.
|
| 225934 |
03-Oct-2011 |
adrian |
Port over the radar pulse decoding code common to the AR5416 and later chipsets.
Obtained from: Atheros
|
| 225926 |
02-Oct-2011 |
adrian |
Remove an unused variable.
|
| 225925 |
02-Oct-2011 |
adrian |
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.
|
| 225924 |
02-Oct-2011 |
adrian |
Document exactly what the RX interrupt mitigation timers do.
|
| 225922 |
02-Oct-2011 |
adrian |
For now (ie: until autosleep support is fully fleshed out), always clear
all of the RX status fields when initialising a new RX descriptor.
|
| 225921 |
02-Oct-2011 |
adrian |
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.
|
| 225883 |
30-Sep-2011 |
adrian |
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.
|
| 225820 |
28-Sep-2011 |
adrian |
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
|
| 225819 |
28-Sep-2011 |
adrian |
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.
|
| 225444 |
08-Sep-2011 |
adrian |
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)
|
| 225431 |
07-Sep-2011 |
adrian |
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)
|
| 225421 |
06-Sep-2011 |
adrian |
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)
|
| 225420 |
06-Sep-2011 |
adrian |
Fix the addac serial load register write for AR5416.
Obtained from: Linux, Atheros
Approved by: re (kib)
|
| 225125 |
24-Aug-2011 |
adrian |
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)
|
| 225111 |
23-Aug-2011 |
adrian |
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)
|
| 224719 |
08-Aug-2011 |
adrian |
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
|
| 224718 |
08-Aug-2011 |
adrian |
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)
|
| 224716 |
08-Aug-2011 |
adrian |
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)
|
| 224709 |
08-Aug-2011 |
adrian |
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)
|
| 224644 |
04-Aug-2011 |
adrian |
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@
|
| 224634 |
03-Aug-2011 |
adrian |
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)
|
| 224633 |
03-Aug-2011 |
adrian |
* 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)
|
| 224624 |
03-Aug-2011 |
adrian |
Remove the EEPROM minor >= 19 check for txgaintype; that's only needed for
Merlin / v14 eeprom formats.
Approved by: re (kib, blanket)
|
| 224539 |
31-Jul-2011 |
adrian |
Add extra flags for the radar event API.
(They're not used by any public code at the current time.)
Approved by: re (kib)
|
| 224538 |
31-Jul-2011 |
adrian |
Add some more phyerr bits.
Obtained from: Atheros
Approved by: re (kib)
|
| 224519 |
30-Jul-2011 |
adrian |
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)
|
| 224518 |
30-Jul-2011 |
adrian |
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)
|
| 224517 |
30-Jul-2011 |
adrian |
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)
|
| 224515 |
30-Jul-2011 |
adrian |
Fix the initial calibration sample count when doing ADC calibrations.
Obtained from: Atheros
Approved by: re (kib)
|
| 224514 |
30-Jul-2011 |
adrian |
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)
|
| 224512 |
30-Jul-2011 |
adrian |
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)
|
| 224510 |
30-Jul-2011 |
adrian |
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)
|
| 224509 |
30-Jul-2011 |
adrian |
Fix the AR9280 initial AGC calibration code.
It looks like this was mixed up with the AR9285 calibration code.
This code is now more in line with what Linux ath9k and Atheros
reference drivers do.
Obtained from: Atheros
Approved by: re (kib)
|
| 224244 |
21-Jul-2011 |
adrian |
Modify the radar API a little to be easier to "change" via run-time
tools.
* introduce pe_enabled, which (will) indicate whether the radar
detection stuff is enabled or not. Right now it's incorrectly
set, based on something previously written. I'll sort it out
later.
* Don't set HAL_PHYERR_PARAM_ENABLE in pe_relstep to say whether
radar detection is on.
* Return whether blockradar, fir128 and enmaxrssi is enabled.
* Change some of the phyerr params to be integers rather than
HAL_BOOL so they can be set to the NOPARAM value when the
setup function is called. This is in line with other radar
parameters.
* Add new configuration parameters for fir128, blockradar and
enmaxrssi, rather than defaulting to off, on and on respectively.
Approved by: re (kib)
|
| 224243 |
21-Jul-2011 |
adrian |
Break out the PLL setup into (mostly) per-chip methods, rather than
polluting the AR5416 code with later chipset support.
Note: ar9280InitPLL() supports Merlin (AR9280) and later (AR9285, AR9287.)
Submitted by: ssgriffonuser@gmail.com
Approved by: re (kib)
|
| 224242 |
21-Jul-2011 |
adrian |
This re-enables HT40 channels for use when DFS is enabled.
These should be disabled for the AR5416 in hostap/mesh/ibss mode,
as the AR5416 doesn't have support for radar detection on the
ext channel of a HT40 setup. Later chips do.
Approved by: re (kib)
|
| 224226 |
20-Jul-2011 |
adrian |
These two are ath_hal regulatory domain updates from the Atheros
reference driver.
* Australia should use FCC3_WORLD
* Add some new SKUs; these are just the EEPROM values and haven't been
fully defined yet. As such they won't affect anything.
Obtained from: Atheros
Approved by: re (kib)
|
| 223615 |
28-Jun-2011 |
adrian |
Make sure the extended regdomain word is initialised.
As with the AR9285, the AR9287 has a default word of 0x1F which means
all the various bits in that field are set on by default.
|
| 223524 |
25-Jun-2011 |
adrian |
Small fix to bring the non-debug definitions of HALDEBUG/HALDEBUG_G in line
with the debug definitions.
|
| 223474 |
23-Jun-2011 |
adrian |
add missing #define for the non-debug case.
|
| 223466 |
23-Jun-2011 |
adrian |
Re-introduce a global ath_hal_debug again for now, whilst I figure out what
to do about the few cases where the HAL state isn't available (regdomain)
or isn't yet setup (probe/attach.)
The global ath_hal_debug now affects all instances of the HAL.
This also restores the ability for probe/attach debugging to work; as
the sysctl tree may not be attached at that point. Users can just set
the global "hw.ath.hal.debug" to a suitable value to enable probe/attach
related debugging.
|
| 223465 |
23-Jun-2011 |
adrian |
Fix indenting issues introduced by the previous commit.
|
| 223459 |
23-Jun-2011 |
adrian |
Break out most of the HAL related tweaks into a per-HAL instance,
rather than global variables.
This specifically allows for debugging to be enabled per-NIC, rather
than globally.
Since the ath driver doesn't know about AH_DEBUG, and to keep the ABI
consistent regardless of whether AH_DEBUG is enabled or not, enable the
debug parameter always but only conditionally compile in the debug
methods if needed.
The ALQ support is currently still global pending some brainstorming.
Submitted by: ssgriffonuser@gmail.com
Reviewed by: adrian, bschmidt
|
| 222821 |
07-Jun-2011 |
adrian |
Since HAL_PHYERR_* is used in the radar code, always include ah_desc.h.
|
| 222815 |
07-Jun-2011 |
adrian |
Flesh out a new HAL method to fetch the radar PHY error frame information.
For the AR5211/AR5212, this is apparently a one byte pulse duration
counter value. It is only coded up here for the AR5212 as I don't have
any AR5211-series hardware to test it on.
This information was extracted from the Madwifi DFS branch along with
some local additions.
Please note - all this does is extract out the radar event duration,
it in no way reflects the presence of a radar. Further code is needed
to take a set of radar events and filter them to extract out correct
radar pulse trains (and ignore other events.)
For further information, please see:
http://wiki.freebsd.org/dev/ath_hal%284%29/RadarDetection
This includes references to the relevant patents which describe what
is going on.
Obtained from: Madwifi
|
| 222644 |
03-Jun-2011 |
adrian |
Bring over the relevant registers to use when implementing the quiet time
portion of 802.11h.
The AR5212 code has been brought over as a reference, it's currently
untested.
Obtained from: Atheros
|
| 222584 |
01-Jun-2011 |
adrian |
Add some missing DFS chipset functionality to the FreeBSD HAL.
Please note - this doesn't in any way constitute a full DFS
implementation, it merely adds the relevant capability bits and
radar detection threshold register access.
The particulars:
* Add new capability bits outlining what the DFS capabilities
are of the various chipsets.
* Add HAL methods to set and get the radar related register values.
* Add AR5212 and AR5416+ DFS radar related register value
routines.
* Add a missing HAL phy error code that's related to radar event
processing.
* Add HAL_PHYERR_PARAM, a data type that encapsulates the radar
register values.
The AR5212 routines are just for completeness. The AR5416 routines
are a super-set of those; I may later on do a drive-by pass to
tidy up duplicate code.
Obtained from: Linux, Atheros
|
| 222432 |
29-May-2011 |
adrian |
Teach if_ath about devices which have short-GI in 20MHz channel modes.
This has been disabled until now because there hasn't been any supported
device which has this feature. Since the AR9287 is the first device to
support it, and since now the HAL has functional AR9287+11n support,
flip this on.
|
| 222424 |
28-May-2011 |
adrian |
Fix AR9287 operation when >1 TX chain is enabled.
I didn't pick this up with the initial commit because I was only testing
with 11bg.
|
| 222324 |
26-May-2011 |
adrian |
Fix a macro name - it's currently unused in this file however, but
keep it consistent with ar9280.c.
|
| 222323 |
26-May-2011 |
adrian |
Revert this erroneous commit and re-disable the AR9285 combined antenna
diversity.
|
| 222316 |
26-May-2011 |
adrian |
Remove the three-chain scaled power check for the AR9287 - it isn't
needed.
|
| 222315 |
26-May-2011 |
adrian |
Make sure only two chains are calibrated for the AR9287.
|
| 222314 |
26-May-2011 |
adrian |
Add some open-loop TX power debugging for AR9287.
|
| 222312 |
26-May-2011 |
adrian |
Bring over the AR5416 per-rate TX power code, modified to use the
AR9287 EEPROM layout.
The AR9287 only supports 2ghz, so I've removed the 5ghz code (but left
the 5ghz edge flags in there for now) and hard-coded the 2ghz-only
path.
Whilst I'm there, fix a typo (ar9285->ar9287.)
This meets basic TX throughput testing - iperf TX tests == 27-28mbit in 11g,
matching the rest of my 11g kit.
|
| 222310 |
26-May-2011 |
adrian |
Flesh out ar9287SetTransmitPower() based on the AR9285 routine.
Hard-code the per-rate TX power at 5dBm for now so testing can be done.
This passes initial TX testing in 11g mode (but, obviously, at 5dBm.)
|
| 222308 |
26-May-2011 |
adrian |
Flesh out the TX power calibration for the AR9287.
I'm assuming for now that the AR9287 is only open-loop TX power control
(as mine is) so I've hard-coded the attach path to fail if the NIC is
not open-loop.
This greatly simplifies the TX calibration path and the amount of code
which needs to be ported over.
This still isn't complete - the rate calculation code still needs to be
ported and it all needs to be glued together.
Obtained from: Linux ath9k
|
| 222305 |
26-May-2011 |
adrian |
Add the AR9287 chip identification string.
|
| 222303 |
26-May-2011 |
adrian |
Fix a bad merge from a previous commit.
|
| 222302 |
26-May-2011 |
adrian |
Merlin -> Kiwi
|
| 222301 |
26-May-2011 |
adrian |
Bring over my AR9287 work in progress.
It isn't linked into the build because it's missing the TX power
and PDADC programming code.
This code is mostly based on the ath9k codebase, compared against
the Atheros codebase as appropriate.
What's implemented:
* probe/attach
* EEPROM board value programming
* RX initial calibration
* radio channel programming
* general MAC / baseband setup
* async fifo setup
* open-loop tx power calibration
What's missing before it can be enabled by default:
* TX power / calibration setting code
* closed-loop tx power calibration routines
* TSF2 handling
* generic timer support from ath9k
Obtained from: Atheros, ath9k
|
| 222300 |
26-May-2011 |
adrian |
AR9287 prep work:
* Add PCI/PCIE devids
* Add AR9287/Kiwi version check macros
* AR_SREV_9287 -> AR_SREV_KIWI
Obtained from: Atheros, ath9k
|
| 222299 |
26-May-2011 |
adrian |
Add temp sense to the EEPROM variable list;
Export the temperature sense variables to ah_eeprom_9287.c
|
| 222277 |
25-May-2011 |
adrian |
The current ANI capability information uses a different set of
values for the commands, compared to the internal command values
(HAL_ANI_CMD.)
My eventual aim is to make the HAL_ANI_CMD internal enum match
the public API and then remove all this messiness.
This now allows HAL_CAP_INTMIT users to use a public HAL_CAP_INTMIT_
enum rather than magic constants.
The only magic constants currently used by if_ath are "enable" and
"present". Some local tools of mine allow for direct, manual fiddling
of the ANI variables and I'll convert these to use the public enum API
before I commit them.
|
| 222276 |
25-May-2011 |
adrian |
Tidy up the ANI API in preparation for looking to expose some more
of the ANI statistics and committing some tools which use these.
* Change HAL_ANI_* commands _back_ to be numerical, rather than a
bitmap;
* modify access to the ANI control bitmap to convert a command to
a bitmap;
* Fix the ANI noise immunity fiddling for CCK errors - it wasn't
checking whether noise immunity was disabled or not.
|
| 222265 |
24-May-2011 |
adrian |
The ANI control for the AR5416 and later chips was calling ar5212AniControl(),
which did AR5212 specific initialisation. This would cause some slight
silliness when enabling/disabling ANI.
Just to be completely correct - and to ensure the phy error mask/RX filter
register isn't incorrectly played with - make the ANI control function a
method, have it set appropriately for AR5212/AR5416, and call that from the
ANI control interface.
|
| 222241 |
24-May-2011 |
adrian |
Use the new per-series antenna and TPC definitions when setting ctl8->11.
This should hopefully make it clearer to developers what is going on
and when TPC is being hacked on, make it obvious why it isn't working for
series 1, 2, 3.
I won't flip on setting TX power for TX series 1, 2, 3 until I've done
some further testing with Kite to ensure it doesn't break anything.
(Before people ask - yes, TPC is only needed for 5ghz regdomains and
yes, Kite is a 2.4ghz only chip, but there are potential use cases
for 2ghz TPC. I just need to sit down and ensure it's supported and
functional.)
|
| 222240 |
24-May-2011 |
adrian |
Add in descriptions for TX descriptor fields ctl8-11 - these fields
control the antenna control bits for the four TX series and the
TPC settings for TX series 1, 2, 3.
The specifics:
* The TPC setting for TX series 0 is handled in ctl0.
* TPC is currently disabled, so the per-packet TX power is
set via the global per-rate TX power register, not per packet.
* The antenna control bits don't matter for AR5416 and later
so they should stay 0 (which they currently do); they may
be set for Kite but as there's no TX diversity supported
at the moment (it requires the NIC to be built with an
external antenna switch, matching how antenna diversity
is done on legacy NICs), so again keep them 0.
This is in preparation for supporting per-rate TPC on the
AR5416 and later. The Kite (and soon to come Kiwi) code
sets ctl8-11 to 0x0, which doesn't have any effect at
the moment. When TPC is enabled it would result in the
second, third and fourth TX series attmpts to be done with
a TX power of 0. This commit doesn't change that; it'll
be followed up with some commits to properly set the TPC
registers appropriately.
|
| 222157 |
21-May-2011 |
adrian |
The Merlin analog register bank is from 0x7800 -> 0x78fc; fix the code
to reflect this.
|
| 222054 |
18-May-2011 |
adrian |
This isn't needed any longer, it's defined in ah_internal.h.
|
| 222027 |
17-May-2011 |
adrian |
Fix case, introduced in my previous commit.
Pointy hat goes to: adrian, for having multiple build screens
open and checking the wrong one.
|
| 222021 |
17-May-2011 |
adrian |
Use the halMcastKeySrchSupport capability bit to selectively enable/disable
the multicast key search support for AR5212, AR5416 and later.
The general HAL routine ath_hal_getcapability() implement checking this
but it's overridden by a check in ar5212_misc:ar5212GetCapability().
This restores the later functionality in case it's found to be broken
in any of the 11n chipsets.
|
| 222020 |
17-May-2011 |
adrian |
Set this HAL capabilities flag correctly even though it isn't currently
being used.
|
| 221944 |
15-May-2011 |
adrian |
Fix NF calibration breakage introduced by me in a past commit.
Since the returned NF will be -ve, checking for <= 0 is not good
enough. For now, check whether it equals 0 or -1; a future commit
will tidy this mess up and have it return HAL_BOOL instead.
|
| 221897 |
14-May-2011 |
adrian |
Fix the Merlin 5ghz fast-clock EEPROM fetch to return the correct value.
The eeprom Get method should return HAL_OK if fastclock is enabled in the
EEPROM. It was returning the opposite of what it should have.
Submitted by: Matthew Fleming <mdf356@gmail.com>
|
| 221896 |
14-May-2011 |
adrian |
Fix the eeprom set API method to return HAL_STATUS.
The code assumed it could return HAL_OK, HAL_EINVAL and other
HAL_STATUS types; so it shouldn't be declared as returning HAL_BOOL.
This commit was brought to you by the Clang compiler.
Submitted by: Matthew Fleming <mdf356@gmail.com>
|
| 221888 |
14-May-2011 |
adrian |
Import initial EEPROM code for Kite (AR9287).
I've tested this locally and it does indeed read and attach to an AR9287
EEPROM. But a lot more code needs to be ported over to the HAL before
the AR9287 is functional.
I'm importing this separate from the rest of the codebase (and unlinked from
the build for now) in case someone wishes to begin fiddling with porting
the rest of the code over from Linux ath9k.
Obtained from: Linux ath9k
|
| 221878 |
14-May-2011 |
adrian |
When disabling RIFS for Sowl (AR9160) and Howl (AR9130), make sure RIFS
is totally disabled.
The Atheros HAL code does this for Sowl/Howl but not for Owl (AR5416) where
RIFS is disabled by default.
This seems to quieten the occasional baseband hang I've been seeing with
the AR9160 in STA mode under constant heavy traffic load.
Obtained from: Atheros
|
| 221876 |
14-May-2011 |
adrian |
Major fix: when doing open-loop TX power calibration, adjust
the correct CCK rates rather than adjusting the first handful.
This may have affected some AR9280 based NICs.
Minor fix: merlin check update
|
| 221875 |
14-May-2011 |
adrian |
Fixes from the Atheros HAL - formatting; update Merlin checks to be consistent.
Nothing functional should change with this commit.
|
| 221868 |
14-May-2011 |
adrian |
Even though initial calibrations aren't done (yet), add this so we're
consistent with the Atheros HAL.
|
| 221837 |
13-May-2011 |
adrian |
Only do open loop power control and temperature compensation
for the AR9280 based NICs if it's actually enabled.
Some of the OLC code was erroneously called during setup
and calibration. This may have caused some incorrect behaviour.
|
| 221834 |
13-May-2011 |
adrian |
Remove duplicate code - add a function which calculates the ratesArray[]
table which contains the per-rate target TX power.
This code is shared between the v14 eeprom board setup (AR5416, AR9160,
AR9280) and will also be used by the upcoming Kite (AR9287) support.
|
| 221833 |
13-May-2011 |
adrian |
Some diversity changes relating to AR9285.
* grab the main, alt and selected LNA config
* add some optional / disabled logging code
* add a check to reject packets with an invalid main rssi too,
in case the alt is the active receive chain and main is -ve.
Note: The software-controlled combined diversity code is still disabled.
|
| 221806 |
12-May-2011 |
adrian |
Break out the AR9285 analog registers from ar5416/ar5416phy.h and put
them in a new header file, ar9002/ar9285_an.h.
Shuffle the AR9280 analog registers in ar5416/ar541phy.h into a contiguous
spot.
|
| 221801 |
12-May-2011 |
adrian |
Fix the half/quater rate PLL setup for AR5416, AR9160 and
(beta?) AR9280 chips.
Note: This doesn't "fix" half/quarter rate support for these
chips; it merely fixes an oversight.
Obtained from: Atheros
|
| 221800 |
12-May-2011 |
adrian |
Fixes from Atheros:
* If AR9130, give the chip extra time to reset
* If AR5416, don't shutdown the chip during reset
|
| 221779 |
11-May-2011 |
adrian |
Make the NF calibration logic (hopefully!) more resistive to noisy
environments.
In setups where NF calibration can take a while, don't load the CCA
and kick off a new NF calibration if the previous one hasn't yet
completed. This shouldn't happen unless the environment is noisy but
those exist (hi phk!).
Here, if the previous NF hasn't completed when ar5416LoadNf() is run
(which reads the NF), it skips updating the history buffer, loading
the NF CCA array and kicking off the next NF cal. It's hoped it'll
occur in the next long calibration interval.
Obtained from: Atheros, ath9k, my local HAL
|
| 221778 |
11-May-2011 |
adrian |
Always log if the NF CCA load fails; so users with debugging enabled
can see they're likely in a very noisy environment.
|
| 221777 |
11-May-2011 |
adrian |
Make sure the chip is awake before writing to it to finally detach
it.
Obtained from: Atheros
|
| 221776 |
11-May-2011 |
adrian |
Add a new flag - HAL_DEBUG_UNMASKABLE - which always logs a debug message
(when debug is enabled) no matter what.
|
| 221775 |
11-May-2011 |
adrian |
Remove unused variable
|
| 221773 |
11-May-2011 |
adrian |
Remove the initial NF completion check.
This is taking quite a while for some people in some situations
(eg AR5418 in phk's Abusive Radio Environment).
Instead, the rest of the calibration related code should
ensure that a NF calibration has occured before reading NF
values and kicking off another NF calibration.
The channel should also likely be marked as "noisy" (CWINT)
if the NF calibration takes too long.
|
| 221772 |
11-May-2011 |
adrian |
Remove a now unneeded comment..
|
| 221766 |
11-May-2011 |
adrian |
Restore the RSSI threshold after writing the board values.
This would be overwritten by the board initvals written in ah->writeIni().
|
| 221722 |
10-May-2011 |
adrian |
AR9285 (Kite) fixes.
* Correct some of the silicon revision checks to match what
the Atheros HAL does. (See [1] below.)
* Move the PA cal and init cal method assignment to -after-
the mac version/revision IDs are stored. The AR9285 init
cal was never being called.
* Enable ANI.
Note Kite 1.0 and 1.1 were prototypes that shouldn't be seen
in the wild. Linux ath9k simply removed the prototype code from
their codebase. I'm going to leave it in there for now but
make it conditionally compilable in the future.
Obtained from: Atheros
|
| 221702 |
09-May-2011 |
adrian |
Disable diversity combining support until I can get a firm answer
from Atheros as to what/when this is supposed to be enabled.
Using the default RX fast diversity settings seems to help quite
a bit.
Whilst I'm here, change the prototype to return HAL_BOOL rather than int.
|
| 221701 |
09-May-2011 |
adrian |
Fix a regression I introduced - only swap analog chains if the RX chainmask
is 0x5.
|
| 221700 |
09-May-2011 |
adrian |
Disable TX STBC - it isn't used for now, but it isn't supported on Kite.
|
| 221694 |
09-May-2011 |
adrian |
Import some initial Kite fixed diversity code from Atheros.
For now, the diversity settings are controlled by 'txantenna',
-not- rxantenna. This is because the earlier chipsets had
controllable TX diversity; the RX antenna setting twiddles
the default antenna register. I'll try sort that stuff out at
some point.
Call the antenna switch function from the board setup function
so scans, channel changes, mode changes, etc don't set the
diversity back to a default state too far from what's intended.
Things to todo:
* Squirrel away the last antenna diversity/combining parameters
and restore them during board setup if HAL_ANT_VARIABLE is
defined. That way scans, etc don't reset the diversity settings.
* Add some more public facing statistics, rather than what's
simply logged under HAL_DEBUG_DIVERSITY.
For now, the fixed antenna settings behave better than variable
settings for me. I have some further fiddling to do..
Obtained from: Atheros
|
| 221693 |
09-May-2011 |
adrian |
Remove an un-needed PA cal call here.
|
| 221667 |
08-May-2011 |
adrian |
Fix the 5ghz fast clock logic.
The macro which I incorrectly copied into ah_internal.h assumed
that it'd be called with an AR_SREV_MERLIN_20() check to ensure
it was only enabled for Merlin (AR9280) silicon revision 2.0 or
later.
Trouble is, the 5GHz fast clock EEPROM flag is only valid for
EEPROM revision 16 or greater; it's assumed to be enabled
by default for Merlin rev >= 2.0. This meant it'd be incorrectly
set for AR5416 and AR9160 in 5GHz mode.
This would have affected non-default clock timings such as SIFS,
ACK and slot time. The incorrect slot time was very likely wrong
for 5ghz mode.
|
| 221666 |
08-May-2011 |
adrian |
* Add AR_SREV_KITE macro for later use
* Modify AR_SREV_MERLIN_20() to match the Atheros/Linux ath9k behaviour -
its supposed to match Merlin 2.0 and later Merlin chips.
AR_SREV_MERLIN_20_OR_LATER() matches AR9280 2.0 and later chips
(AR9285, AR9287, etc.)
|
| 221622 |
08-May-2011 |
adrian |
These EEPROM bits actually defined whether HT/20 and HT/40 support
for the given channel is available.
It isn't used yet; ar5416GetWirelessModes() needs to be taught
about this rather than assuming HT20/HT40 is available.
|
| 221620 |
08-May-2011 |
adrian |
Fiddle with the PLL initialisation order to match ath9k/Atheros HAL.
This seems to make the AR9160 behave better during heavy scanning,
where before it'd hang and require a hard reset to recover.
Obtained From: Linux ath9k, Atheros
|
| 221618 |
08-May-2011 |
adrian |
Properly indent the WAR code i pasted in from ath9k a few months
ago.
|
| 221617 |
08-May-2011 |
adrian |
* Add in a comment about ar5416InitUserSettings() potentially
modifying AR_DIAG_SW.
There's a hardware workaround which sets disabling some errors
early at startup and clears said bits before the PCU begins
receiving - it does this to avoid RX descriptor status errors.
It's possible these bits aren't being completely properly twiddled
in all instances; but in particular if the diag_reg HAL variable
is set it won't be setting these bits correctly. I'll review this
at some point.
* Disable multicast search on mac address and key id - the driver
doesn't use it at the moment and thus adhoc may be broken for
merlin and later.
* Change this to be for Merlin 1.0 (which from what I understand
wasn't ever publicly released) to be more correct.
|
| 221616 |
08-May-2011 |
adrian |
Fiddle with the AR5416 1.0 chainmask setup.
Apparently all three RX chains need to be enabled before initial calibration
is done, even if only two are configured.
Reorder the alt chain swap bit to match what the Atheros HAL is doing.
Obtained From: ath9k, Atheros
|
| 221608 |
07-May-2011 |
adrian |
Fix the IS_5416 checks to actually work correctly.
I've verified that my AR5416 revision 2.2 (minor revision 0x0A) now
matches the correct checks.
|
| 221603 |
07-May-2011 |
adrian |
Do a HAL capabilities sync pass based on the Atheros HAL.
* Shuffle some of the capability numbers around to match the
Atheros HAL capability IDs, just for consistency.
* Add some new capabilities to FreeBSD from the Atheros
HAL which will be be shortly used when new chipsets are added
(HAL SGI-20 support is for Kiwi/AR9287 support); for
TX aggregation (MBSSID aggregate support, WDS aggregation
support); CST/GTT support for carrier sense/TX timeout.
|
| 221600 |
07-May-2011 |
adrian |
Update the ext channel cycpwr threshold 1 register for the extension
channel when the channel is HT/40.
The new ANI code (primarily for the AR9300/AR9400) in ath9k sets this
register but the ANI code for the previous 11n chips didn't set this.
Unlike ath9k, only set this for HT/40 channels.
Obtained From: ath9k
|
| 221596 |
07-May-2011 |
adrian |
Read in the extended regulatory domain flags so future code can use them.
These describe FCC/Japan channel and DFS behaviour.
The AR9285 and later chips don't set these bits in the eeprom, the correct
behaviour is to just assume all five bits are enabled.
|
| 221582 |
07-May-2011 |
adrian |
Instead of returning an unknown mac/bb signature, just return 0.
|
| 221581 |
07-May-2011 |
adrian |
Add some comments about which HAL capabilities are currently FreeBSD
specific.
The Atheros HAL and FreeBSD HAL share the same capabilities up
until HAL_CAP_11D, where things begin to diverge.
I'll look at tidying these up soon.
Obtained from: Atheros
|
| 221580 |
07-May-2011 |
adrian |
Some BB hang changes:
* Add Howl (ar9130) to the list of chips that have DFS/BB/MAC hangs
* Don't treat unknown BB hangs as fatal; ath9k/Atheros HAL don't
treat it as such.
* Add HAL_DEBUG_DFS to the debug fields in ath_hal/ah_debug.h
The BB hang check simply loops over an observation register checking
for a stuck state engine, but it can happen under high traffic
conditions. Ath9k and the Atheros HAL simply log a debug message and
continue.
Private to FreeBSD:
* Add HAL_DEBUG_HANG to the debug fields
* Change the hang debugging to HAL_DEBUG_HANG rather than HAL_DEBUG_DFS
like in the Atheros HAL.
Obtained from: Atheros
|
| 221574 |
07-May-2011 |
adrian |
Change AR_SREV_OWL_{X}_OR_LATER to AR_SREV_5416_{X}_OR_LATER.
For now, these are equivalent macros. AR_SREV_OWL{X}_OR_LATER
will later change to exclude Howl (AR9130) in line with what
the Atheros HAL does.
This should not functionally change anything.
Obtained from: Atheros
|
| 221573 |
07-May-2011 |
adrian |
Fix the OWL revision checks.
A quick story, which is partially documented in the commit.
The silicon revision in Linux ath9k and the Atheros HAL use an
AR_SREV_REVISION mask of 0x07.
FreeBSD's HAL uses the AR5212 AR_SREV_REVISION mask of 0x0F.
Thus the OWL silicon revisions were coming through as 0xA, 0xB,
0xC, rather than 0x0, 0x1 and 0x2.
My ath9k-sourced AR_SREV_OWL_<X> macros were thus using the wrong
silicon revision values and wouldn't correctly match.
This commit does a few things:
* Change the AR_SREV_OWL_<x> macros to use the AR_SREV_REVISION_OWL_*
values, not AR_XSREV_REVISION_OWL macros;
* Disable AR_XSREV_REVISION_OWL_* values;
* Modify the IS_5416 to properly check the MAC is OWL, rather than
potentially matching on non-OWL revisions (which shouldn't happen
unless there's a silicon revision of higher than 0x9 in a later
chip..)
* Add a couple more macros from the Atheros HAL for compatibility.
The main difference now is that the Atheros HAL defines
AR_SREV_OWL_{20,22}_OR_LATER subtly differently - it fails on all HOWL
silicon. The AR_SREV_5416_*_OR_LATER macros match on the relevant OWL
version -and- all HOWL versions, along with subsequent versions.
A subsequent commit is going to migrate the uses of AR_SREV_OWL_X_OR_LATER
to AR_SREV_5416_X_OR_LATER to match what's going on in the Atheros HAL.
There's only two uses of AR_SREV_OWL_X_OR_LATER which currently don't
apply to FreeBSD but it may do in the future.
Yes, it's all confusing!
|
| 221535 |
06-May-2011 |
adrian |
Add a function which enables or disables RX RIFS searching, and migrate
the code which does this into it.
|
| 221488 |
05-May-2011 |
adrian |
Don't perform NF calibration for radio chains which aren't in use:
Quoting the ath9k commit message:
At present the noise floor calibration is processed in supported
control and extension chains rather than required chains.
Unnccesarily doing nfcal in all supported chains leads to
invalid nf readings on extn chains and these invalid values
got updated into history buffer. While loading those values
from history buffer is moving the chip to deaf state.
This issue was observed in AR9002/AR9003 chips while doing
associate/dissociate in HT40 mode and interface up/down
in iterative manner. After some iterations, the chip was moved
to deaf state. Somehow the pci devices are recovered by poll work
after chip reset. Raading the nf values in all supported extension chains
when the hw is not yet configured in HT40 mode results invalid values.
Reference: https://patchwork.kernel.org/patch/753862/
Obtained from: Linux ath9k
|
| 221483 |
05-May-2011 |
adrian |
Another Howl (AR9130) fix.
I haven't seen a 5ghz AR9130 based board yet though!
Obtained from: Atheros
|
| 221480 |
05-May-2011 |
adrian |
Fix up the chipset checks for the AR5416 and later silicon.
The checks should function as follows:
* AR_SREV_<silicon> : check macVersion matches that version id
* AR_SREV_<silicon>_<revision> : check macVersion and macRevision match
the version / revision respectively
* AR_SREV_<silicon>_<revision>_OR_LATER: check that
+ if the chip silicon version == macVersion, enforce revision >= macRevision
+ if the chip silicon version > macVersion, allow it.
For example, AR_SREV_MERLIN() only matches AR9280 (any revision),
AR_SREV_MERLIN_10() would only match AR9280 version 1.0, but
AR_SREV_MERLIN_20_OR_LATER() matches AR9280 version >= 2.0 _AND_
any subsequent MAC (So AR9285, AR9287, etc.)
The specific fixes which may impact users:
* if there is Merlin hardware > revision 2.0, it'll now be correctly
matched by AR_SREV_MERLIN_20_OR_LATER() - the older code simply
would match on either Merlin 2.0 or a subsequent MAC (AR9285, AR9287, etc.)
* Kite version 1.1/1.2 should now correctly match. As these macros
are used in the AR9285 reset/attach path, and it's assumed that the
hardware is kite anyway, the behaviour shouldn't change. It'll only
change if these macros are used in other codepaths shared with
older silicon.
Obtained from: Linux ath9k, Atheros
|
| 221479 |
05-May-2011 |
adrian |
Import some HOWL (AR9130) related fixes from Atheros.
Obtained from: Atheros
|
| 221427 |
04-May-2011 |
adrian |
Remove this useless bit of code for Kite. The RIFS register value is overriden
by the initvals, so disabling RIFS before calling writeIni() effectively does
nothing.
|
| 221206 |
29-Apr-2011 |
adrian |
Remove some holdovers from the AR5212 origin of this code.
These aren't relevant here.
|
| 221163 |
28-Apr-2011 |
adrian |
Introduce AR9130 (HOWL) WMAC support to the FreeBSD HAL.
The AR9130 is an AR9160/AR5416 family WMAC which is glued directly
to the AR913x SoC peripheral bus (APB) rather than via a PCI/PCIe
bridge.
The specifics:
* A new build option is required to use the AR9130 - AH_SUPPORT_AR9130.
This is needed due to the different location the RTC registers live
with this chip; hopefully this will be undone in the future.
This does currently mean that enabling this option will break non-AR9130
builds, so don't enable it unless you're specifically building an image
for the AR913x SoC.
* Add the new probe, attach, EEPROM and PLL methods specific to Howl.
* Add a work-around to ah_eeprom_v14.c which disables some of the checks
for endian-ness and magic in the EEPROM image if an eepromdata block
is provided. This'll be fixed at a later stage by porting the ath9k
probe code and making sure it doesn't break in other setups (which
my previous attempt at this did.)
* Sprinkle Howl modifications throughput the interrupt path - it doesn't
implement the SYNC interrupt registers, so ignore those.
* Sprinkle Howl chip powerup/down throughout the reset path; the RTC methods
were
* Sprinkle some other Howl workarounds in the reset path.
* Hard-code an alternative setup for the AR_CFG register for Howl, that
sets up things suitable for Big-Endian MIPS (which is the only platform
this chip is glued to.)
This has been tested on the AR913x based TP-Link WR-1043nd mode, in
legacy, HT/20 and HT/40 modes.
Caveats:
* 2ghz has only been tested. I've not seen any 5ghz radios glued to this
chipset so I can't test it.
* AR5416_INTERRUPT_MITIGATION is not supported on the AR9130. At least,
it isn't implemented in ath9k. Please don't enable this.
* This hasn't been tested in MBSS mode or in RX/TX block-aggregation mode.
|
| 221019 |
25-Apr-2011 |
adrian |
Wrap the MIMO stuff in #ifdef AH_SUPPORT_AR5416, as the channel
state doesn't have MIMO stuff in it by default.
|
| 220990 |
24-Apr-2011 |
adrian |
Break out the PLL setup into an overridable method.
The only method right now is ar5416InitPLL() which handles multiple
chipsets; this can now be overridden by newer chipset HAL code.
|
| 220989 |
24-Apr-2011 |
adrian |
Use the refactored ar5416WriteTxPowerRateRegisters() call in the ar9285 code.
|
| 220988 |
24-Apr-2011 |
adrian |
Eliminate code duplication between AR5416/AR9160/AR9280 and AR9285.
Writing the TX power registers is the same between all of these chips
and later NICs (AR9287, AR9271 USB, etc.) so this will reduce code
duplication when those NICs are added to the HAL.
|
| 220966 |
23-Apr-2011 |
adrian |
Fix a corner-case of interrupt handling which resulted in potentially
spurious (and fatal) interrupt errors.
One user reported seeing this:
Apr 22 18:04:24 ceres kernel: ar5416GetPendingInterrupts: fatal error,
ISR_RAC 0x0 SYNC_CAUSE 0x2000
SYNC_CAUSE of 0x2000 is AR_INTR_SYNC_LOCAL_TIMEOUT which is a bus timeout;
this shouldn't cause HAL_INT_FATAL to be set.
After checking out ath9k, ath9k_ar9002_hw_get_isr() clears (*masked)
before continuing, regardless of whether any bits in the ISR registers
are set. So if AR_INTR_SYNC_CAUSE is set to something that isn't
treated as fatal, and AR_ISR isn't read or is read and is 0, then
(*masked) wouldn't be cleared. Thus any of the existing bits set
that were passed in would be preserved in the output.
The caller in if_ath - ath_intr() - wasn't setting the masked value
to 0 before calling ath_hal_getisr(), so anything that was present
in that uninitialised variable would be preserved in the case above
of AR_ISR=0, AR_INTR_SYNC_CAUSE != 0; and if the HAL_INT_FATAL bit
was set, a fatal condition would be interpreted and the chip was
reset.
This patch does the following:
* ath_intr() - set masked to 0 before calling ath_hal_getisr();
* ar5416GetPendingInterrupts() - clear (*masked) before processing
continues; so if the interrupt source is AR_INTR_SYNC_CAUSE
and it isn't fatal, the hardware isn't reset via returning
HAL_INT_FATAL.
This doesn't fix any underlying errors which trigger
AR_INTR_SYNC_LOCAL_TIMEOUT - which is a bus timeout of some
sort - so that likely should be further investigated.
|
| 220955 |
22-Apr-2011 |
adrian |
Fix the merlin LNA configuration code - these are bit flags, not raw values to be
written into the registers.
|
| 220947 |
22-Apr-2011 |
adrian |
The second regdomain word is a set of bitflags describing
regulatory domain behaviour. Document what the v14 EEPROM
flags are.
|
| 220946 |
22-Apr-2011 |
adrian |
Bring over a pdadc calibration fix from ath9k - unused power detector
gain values should be 58, not the previous values.
Obtained From: linux ath9k
|
| 220779 |
18-Apr-2011 |
adrian |
Rework the Global TX timeout handling to look more like ath9k.
It correctly now sets the AR_IMR BCNMISC register, along with
the GTT register in AR_IMR_S2.
|
| 220772 |
18-Apr-2011 |
adrian |
Add global TX timeout handling.
The global TX timeout counter increments whenever a frame is ready
to be transmitted and the medium is busy.
|
| 220738 |
17-Apr-2011 |
adrian |
Mark the PHY as inactive before the chip is reset.
It's also marked inactive by the initvals, and enabled after
the baseband/PLL has been configured, but before the RF
registers have been programmed.
The origin and reason for this particular change is currently unknown.
Obtained from: Linux ath9k
|
| 220722 |
16-Apr-2011 |
adrian |
Don't do Kite antenna switch selection this way (for now); antenna
diversity is done elsewhere now.
|
| 220718 |
16-Apr-2011 |
adrian |
Disable classic-style fast diversity on the AR5416 and later.
Antenna diversity on the >= AR5416 is implemented differently than the
AR5212 and previous chips. So for now, and not to confuse things, just
disable it for now.
|
| 220713 |
16-Apr-2011 |
adrian |
Remove some duplicate code from the AR9285 TX power configuration path.
|
| 220600 |
13-Apr-2011 |
adrian |
Add in the last bit of the HAL support for Kite diversity.
* add a new method, specifically for doing per-RX packet
antenna diversity
* set that HAL method only if it's Kite and a Kite chip that
does diversity.
|
| 220599 |
13-Apr-2011 |
adrian |
More kite diversity related changes.
* add a diversity flag to the HAL debugging section
* add a check to make sure the kite diversity code doesn't run
on boards that don't require it, as not all Kite chips will
implement it.
* add some debug statements when the diversity code makes
changes to the antenna diversity/combining setup.
|
| 220598 |
13-Apr-2011 |
adrian |
Change this to be less noisy.
|
| 220593 |
13-Apr-2011 |
adrian |
Bring over the antenna diversity logic support for Kite.
Again, this is just the code ported from ath9k and included in the build,
it isn't yet enabled.
|
| 220590 |
13-Apr-2011 |
adrian |
Port over a TX gain fix from ath9k specific to the AR9285 (Kite) and AR9271.
Note: this HAL currently only supports the AR9285.
From Linux ath9k:
The problem is that when the attenuation is increased,
the rate will start to drop from MCS7 -> MCS6, and finally
will see MCS1 -> CCK_11Mbps. When the rate is changed b/w
CCK and OFDM, it will use register desired_scale to calculate
how much tx gain need to change.
The output power with the same tx gain for CCK and OFDM modulated
signals are different. This difference is constant for AR9280
but not AR9285/AR9271. It has different PA architecture
a constant. So it should be calibrated against this PA
characteristic.
The driver has to read the calibrated values from EEPROM and set
the tx power registers accordingly.
|
| 220589 |
13-Apr-2011 |
adrian |
Add new fields to the v4k EEPROM modal header.
|
| 220588 |
13-Apr-2011 |
adrian |
Add OS_REG_RMW, which mirrors ath9k's REG_RMW.
This macro does a read-modify-write pass with register bits to set and clear.
|
| 220587 |
13-Apr-2011 |
adrian |
Add the initial AR9285 PHY glue for supporting antenna diversity.
This code isn't currently used anywhere; it's just linked into the build.
|
| 220539 |
11-Apr-2011 |
adrian |
De-dup the ar5416 rates array definition.
|
| 220444 |
08-Apr-2011 |
adrian |
Fix the completely wrong types I used in the previous commit.
|
| 220443 |
08-Apr-2011 |
adrian |
Begin fleshing out a public HAL routine to export the per-chain
ctl/ext noise floor values.
This routine doesn't check to see whether the radio is MIMO
capable - instead, it simply returns either the raw values,
the "nominal" values if the raw values aren't yet available
or are invalid, or '0' values if there's no valid channel/
no valid MIMO values.
Callers are expected to verify the radio is a MIMO radio
(which for now means it's an 11n chipset, there are non-11n
MIMO chipsets out there but I don't think we support them,
at least in MIMO mode) before exporting the MIMO values.
|
| 220442 |
08-Apr-2011 |
adrian |
Export the per-chain ctl/ext noise floor values, raw and uncut, to the
upper-level HAL.
Right now the per-chain noise floor values aren't used anywhere in
the upper-level HAL, so the driver currently has no real reference
to compare the per-chain RSSI values to.
This is needed before per-chain RSSI values (for ctl and ext radios)
are can be thrown upstairs to the net80211 code.
|
| 220438 |
08-Apr-2011 |
adrian |
Extend the RX descriptor block to include two more EVM words.
This will be needed for later AR93xx/AR94xx 3-stream devices.
|
| 220423 |
07-Apr-2011 |
adrian |
Add some more OS_MARK probes to the RX DMA setup/teardown code path.
I'm trying to debug the RX DMA path and help the ath9k guys with
"RX dma abort stuck" issue that both our drivers have.
|
| 220360 |
05-Apr-2011 |
adrian |
The xpaBiasLvlFreq[] fields in the modal header also need swapping
when the EEPROM contents are byte-swapped.
|
| 220325 |
04-Apr-2011 |
adrian |
Commit missing bits from the last commit:
* add the hal capability flag
* make sure its disabled for the ar9280/ar9285.
|
| 220324 |
04-Apr-2011 |
adrian |
Add a HAL capability bit for supporting self-linked RX descriptors and disable it for the 11n chipsets.
From the ath9k source:
==
11N: we can no longer afford to self link the last descriptor.
MAC acknowledges BA status as long as it copies frames to host
buffer (or rx fifo). This can incorrectly acknowledge packets
to a sender if last desc is self-linked.
==
Since this is useful for pre-AR5416 chips that communicate PHY errors
via error frames rather than by on-chip counters, leave the support
in there, but disable it for AR5416 and later.
|
| 220323 |
04-Apr-2011 |
adrian |
At least set the coverage class value here; worry about populating the
register values at a later date.
|
| 220302 |
03-Apr-2011 |
adrian |
I missed committing this last time - it's needed for the 5ghz fast clock calculation.
|
| 220298 |
03-Apr-2011 |
adrian |
Add in the clock timing calculation when Merlin is using the 5ghz fast clock.
This is a 44mhz clock, not a 40mhz clock like normal for 5ghz operation.
|
| 220294 |
03-Apr-2011 |
adrian |
Import a fix from the ath9k - reduce the TX FIFO size for Kite (AR9285.)
|
| 220293 |
03-Apr-2011 |
adrian |
Add an explanation of the inivals
|
| 220259 |
02-Apr-2011 |
adrian |
From ath9k - clear the RX descriptor status before recycling it.
|
| 220258 |
02-Apr-2011 |
adrian |
Add some more debugging
|
| 220188 |
31-Mar-2011 |
adrian |
Introduce AH_AR5416_INTERRUPT_MITIGATION which enables interrupt mitigation for
the AR5416 and later. Rename the older HAL option to use this.
|
| 220035 |
26-Mar-2011 |
adrian |
.. And another missed commit - add the PSPOLL capability.
|
| 220034 |
26-Mar-2011 |
adrian |
This was missing from the previous HAL commit - it fixes a typo and
introduces the PS-POLL hardware support.
|
| 220027 |
26-Mar-2011 |
adrian |
Introduce hardware PS-POLL support in the HAL.
Linux ath9k only enables this for AR9280 and later NICs; so
create a capability for it so it isn't enabled for earlier
NICs.
Enabling hardware PS-POLL support will come in a later commit
and will be disabled by default.
|
| 220025 |
26-Mar-2011 |
adrian |
Put these two back to mirror what ath9k does.
Even though they map to setting the error filter register,
ath9k also writes them untouched to AR_RX_FILTER.
The Force-BSSID match bit can stay high, as it maps to a
misc mode register setting rather than an RX filter bit.
|
| 220022 |
26-Mar-2011 |
adrian |
Shuffle around the HAL_RX_FILTER bits to be slightly more sensible.
The phyerr, radar and bssid-match bits aren't real bits, they map
to enabling bits in other registers. Move those out of the way of
valid RX filter bits.
Add a few new fields from ath9k - compba, ps-poll, mcast-bcast-all.
|
| 219984 |
25-Mar-2011 |
adrian |
I broke periodic adc calibrations - so restore them to working order.
|
| 219980 |
25-Mar-2011 |
adrian |
After discussion with Felix Fietkau (nbd) about the ath9k Merlin LNA bit
settings, it seems that our defines are backwards and don't match what
is in the EEPROM documentation or internal driver.
The ath9k code used to have a bitfield here, rather than a uint8_t, and
there were #defines used to swap the order based on the endian of the
platform - this wasn't because of nybble or bit ordering of the
underlying host but because of what the compiler was doing.
This may be the reason for the backwards field numbers, as ath9k had
similar issues.
|
| 219979 |
25-Mar-2011 |
adrian |
Flip ANI on for the AR5416 and later chips. I haven't verified it on
the AR9285 so I'll leave it off for that.
Ath9k sources indiciate that one of the ANI modes interferes with
RIFS detection, so match ath9k and disable that.
|
| 219978 |
25-Mar-2011 |
adrian |
The right commit - add a couple more AR_PCU_MISC_MODE2 register bits -
SOWL specific.
|
| 219977 |
25-Mar-2011 |
adrian |
oops, commited the wrong file change.
|
| 219976 |
25-Mar-2011 |
adrian |
Add some more AR_PCU_MISC_MODE2 register settings - these are SOWL or later.
|
| 219975 |
25-Mar-2011 |
adrian |
Bring over interrupt mitigation changes from ath9k.
* The existing interrupt mitigation code didn't mitigate anything - the
per-packet TX/RX interrupts are still occuring. It's possible this
worked for the AR5416 but not any later chipsets; I'll investigate and
update as needed.
* Set both the RX and TX threshold registers whilst I'm at it.
This is verified to work on the AR9220 and AR9160. I'm leaving it off
by default in case it's truely broken, but I need to have it enabled
when doing 11n testing or interrupt loads exceed 10,000 interrupts/sec.
|
| 219942 |
23-Mar-2011 |
adrian |
Make the ar2133ForceBias() call controllable at runtime.
At least one AR5416 user has reported measurable throughput drops
with this option. For now, disable it and make it a run-time
twiddle. It won't take affect until the next radio programming
trip though (eg channel scan, channel change.)
|
| 219894 |
23-Mar-2011 |
adrian |
The AR5416+ chips all have MIB counters (which the AR5416 ANI code assumes)
so there's no need to enable the RX of invalid frames just to do ANI.
The if_ath code and AR5212 ANI code setup the RX filter bits to enable
receiving OFDM/CCK errors if the device doesn't have the hardware
MIB counters. It isn't initialising it for the AR5416+ because all of
those chips have hardware MIB counters.
This fixes the odd (and performance affecting!) situation where if ani
is enabled (via sysctl dev.ath.X.intmit) then suddenly there's be a very
large volume of phy errors - which is good to track, but not what was
intended. Since each PHY error is a received (0 length) frame, it can
significantly tie up the RX side of things.
|
| 219863 |
22-Mar-2011 |
adrian |
Bring over an XPA (external power amplifer) bias fix for the AR9160.
This fix modifies the const addac initval array, rather than modifying
a local copy. It means that running >1 AR9160 on a board may prove to
be unpredictable.
The AR5416 init path also does something similar, so supporting
>1 AR5416 of different revisions could cause problems.
The later fix will be to create a private copy of the Addac data
for the AR5416, AR9160 (and AR9100 when it's merged in) and then
modify that as needed.
Obtained From: Linux ath9k
|
| 219862 |
22-Mar-2011 |
adrian |
Fix OFDM ANI statistics gathering for the AR5416 and later chips.
I found this when trying to figure out why the RX PHY error count
didn't match the OFDM error count ANI was using. It turns out
there was two problems:
* What this commit addresses - using the wrong mask for OFDM errors,
and
* The RX filter is set incorrectly after a channel scan (at least)
even if interference mitigation is enabled by default.
ANI is still disabled by default for the AR5416 and later chips.
|
| 219860 |
22-Mar-2011 |
adrian |
Set the "right" CCA register.
Obtained From: ath9k
|
| 219855 |
22-Mar-2011 |
adrian |
Break out the RF mode setup into ar5416SetRfMode(), mirroring what ath9k does.
|
| 219854 |
22-Mar-2011 |
adrian |
Do a bit of spring cleaning in the board setup code, just to
bring it in line with the rest of the register initialisation.
I've verified that the 2/5ghz board values written to the
chip match what was previously written.
|
| 219853 |
22-Mar-2011 |
adrian |
Bring over a few queue changes from ath9k:
* add pspoll/uapsd queue setup defaults;
* enable the exponential backoff window rather than the random
backoff window when doing TX contention management.
|
| 219852 |
22-Mar-2011 |
adrian |
Even though it's very unlikely the misc mode register setting at -attach-
would be a problem, make sure it isn't overwritten by whatever is in
there at cold reset.
This brings the > ar5416 init path treatment of AR_MISC_MODE.
|
| 219851 |
22-Mar-2011 |
adrian |
Remove the merlin delay workaround here, it isn't appropriate for
the analog bank writes as Merlin never does them.
|
| 219840 |
21-Mar-2011 |
adrian |
Back that commit out - something's broken, and I need to figure out
what/why.
|
| 219839 |
21-Mar-2011 |
adrian |
This CLKDRV workaround should only be for AR5416 v2.0/2.1;
the check was too strict and enabled it for all non AR5416-v2.2
chipsets - including later ones.
|
| 219802 |
20-Mar-2011 |
adrian |
Disable a check I added a while ago to ensure the initial NF cal completed.
Give it a good go (32 attempts) and then print out a warning that's
going to occur whether HAL debugging is enabled or not. Then don't
abort the radio setup; just continue merrily along.
This should fix the issue that users were having where scanning would
occasionally fail on the active channel, causing traffic to cease
until the radio scanned again.
|
| 219794 |
20-Mar-2011 |
adrian |
Cave in and disable the ADC DC gain/offset calibrations if they're
not needed.
These calibrations are only applicable if the chip operating mode
engages both interleaved RX ADCs (ie, it's compensating for the
differences in DC gain and DC offset -between- the two ADCs.)
Otherwise the chip reads values of 0x0 for the secondary ADC
(as I guess it's not enabled here) and thus writes potentially
bogus info into the chip.
I've tested this on the AR9160 and AR9280; both behave themselves
in 11g mode with these calibrations disabled.
|
| 219793 |
20-Mar-2011 |
adrian |
* Remove a not-needed check in the AR5416+ case
* Restore the chip default of the DCU backoff threshold to 0x2,
mirroring what ath9k does.
|
| 219792 |
20-Mar-2011 |
adrian |
Bring over a copy of the AR5212 TX queue reset and setup routines, in preparation
for fixing them based on the ath9k related TXQ fixes.
I've done this so people can go over the history of the diffs to the original
AR5212 routines (which AR5416 and later chips use) to see what's changed.
|
| 219790 |
20-Mar-2011 |
adrian |
Add a PSPOLL queue type, in preparation for (eventually) porting
over the TX queue setup code from ath9k for the AR5416 and later
chips.
|
| 219773 |
19-Mar-2011 |
adrian |
Add in the channel survey data structures. These will be filled out
by the HAL at some point in the future.
|
| 219772 |
19-Mar-2011 |
adrian |
Reserve a new diagnostic code for the channel survey code I'll add soon.
|
| 219771 |
19-Mar-2011 |
adrian |
Make sure that the AR_MISC_MODE value from the initvals are properly respected.
This commit really is "fix the OFDM duration calculation to match reality when
running in 802.11g mode."
The AR5212 init vals set AR_MISC_MODE to 0x0 and all the bits that can be set are
set through code.
The AR5416 and later initvals set AR_MISC_MODE to various other values (with
the AR5212 AR_MISC_MODE options cleared), which include AR_PCU_CCK_SIFS_MODE .
This adds 6uS to SIFS on non-CCK frames when transmitting.
This fixes the issue where _DATA_ 802.11g OFDM frames were being TX'ed with
the ACK duration set to 38uS, not 44uS as on the AR5212 (and other devices.)
The AR5212 TX pathway obeys the software-programmed duration field in the packet,
but the 11n TX pathway overrides that with a hardware-calculated duration. This
was getting it wrong because of the above AR_MISC_MODE setting. I've verified
that 11g data OFDM frames are now being TXed with the correct ACK+SIFS duration
programmed in.
|
| 219770 |
19-Mar-2011 |
adrian |
Use the HAL method rather than directly calling ar5212ResetTxQueue().
Since ath9k does some slightly different bit fiddling when setting up
the TX queues, it may that the TX queue setup/reset functions will need
overriding later on.
|
| 219767 |
19-Mar-2011 |
adrian |
Add debugging messages to the AR5416 ANI code that's found in the AR5212 ANI code.
|
| 219628 |
14-Mar-2011 |
adrian |
Fix typo that snuck in.
|
| 219627 |
14-Mar-2011 |
adrian |
Bring over the AR9285 board update code from ath9k.
This does a few things in particular:
* Abstracts out the gain control settings into a separate function;
* Configure antenna diversity, LNA and antenna gain parameters;
* Configure ob/db entries - the later v4k EEPROM modal revisions have
multiple OB/DB parameters which are used for some form of
calibration. Although the radio does have defaults for each,
the EEPROM can override them.
This resolves the AR2427 related issues I've been seeing and makes
it stable at all 11g rates for both TX and RX.
|
| 219605 |
13-Mar-2011 |
adrian |
Fix the nfarray offsets for the ar2133/ar5133 radio - (AR5416, AR9160, etc.)
The offsets didn't match the assumption that nfarray[] is ordered by the
chainmask bits and programmed via the register order in ar5416_cca_regs[].
This repairs that damage and ensures that chain 1 is programmed correctly.
(And extension channels will now be programmed correctly also.)
This fixes some of the stuck beacons I've been seeing on my AR9160/AR5416
setups - because Chain 1 would be programmed -80 or -85 dBm, which is
higher than the actual noise floor and thus convincing the radio that
indeed it can't ever transmit.
|
| 219586 |
13-Mar-2011 |
adrian |
Move out some of the shared eeprom board value calculation routines into ah.c
rather than duplicating them for the v14 (ar5416+) and v4k (ar9285) codebases.
Further chipsets (eg the AR9287) have yet another EEPROM format which will use
these routines to calculate things.
|
| 219585 |
13-Mar-2011 |
adrian |
* Add in some board settings debugging to log what's being written
to the TX closed-loop power control registers.
* Modify a couple of functions to take the register chain number,
rather than the regChainOffset value. This allows for the
register chain to be logged.
|
| 219481 |
11-Mar-2011 |
adrian |
Port over the AR9285 PA calibration and initial calibration code from
Linux ath9k.
The ath9k ar9002_hw_init_cal() isn't entirely clear about what
is supposed to be called for what chipsets, so I'm ignoring the
rest of it and just porting the AR9285 init cal path as-is and
leaving the rest alone. Subsequent commits may also tidy up the
Merlin (AR9285) and other chipset support.
Obtained from: Linux ath9k
|
| 219480 |
11-Mar-2011 |
adrian |
Introduce methods for the initial calibration and the new PA calibration
routines.
These are needed for the AR9285/AR2427 and AR9287 calibration routines
which will be introducecd in a later commit.
|
| 219479 |
11-Mar-2011 |
adrian |
Remove the ar9285FillVpdTable() and just use ar5416FillVpdTable().
|
| 219475 |
11-Mar-2011 |
adrian |
Bring over the same fix from the AR5416 PDADC calibration code.
The ath9k driver has a unified boundary/pdadc function, whereas
ours is split into two (one for each EEPROM type.) This is why
the AR9280 check is done here where we could safely assume it'll
always be AR9280 or later.
|
| 219474 |
11-Mar-2011 |
adrian |
Don't call ar5416SetTransmitPower() directly from ar5416SetTxPowerLimit();
this is incorrect for Kite (AR9285) and any future chipsets that
override the EEPROM related routines.
It meant that a direct call to set the TX power would call the v14 EEPROM
AR5416/AR9280 calibration routines, rather than the v4k EEPROM routines
for the AR9285. It thus read the incorrect values from the EEPROM and
programmed garbage PDADC and TX power values into the hardware.
|
| 219450 |
10-Mar-2011 |
adrian |
Kite is a 1x1 stream device.
|
| 219445 |
10-Mar-2011 |
adrian |
Now that the power curve adjustment code is in, disable the error check
I introduced earlier, and turn it into debugging output.
|
| 219444 |
10-Mar-2011 |
adrian |
Port over the v14 eeprom PDADC curve changes from ath9k.
It looks like these apply in both open and closed loop TX power control,
but the only merlin boards i have either have OL -or- a non-default power
offset, not both.
|
| 219443 |
10-Mar-2011 |
adrian |
Merlin fix - first pdadc gain index is 0 - minpwr/2 .
Obtained from: Linux ath9k
|
| 219442 |
10-Mar-2011 |
adrian |
Migrate the regulatory database definitions into separate header files
to both make things clearer, and to make it easier to write userland
code which pulls in these definitions without needing to pull in the
rest of the HAL.
This stuff should be deprecated at some point in the future once
the net80211 regulatory domain support encapsulates all of the
defintions here.
|
| 219441 |
10-Mar-2011 |
adrian |
Introduce the Merlin PWDCLKIND workaround.
This is something bus clock related from what I can gather. It is needed for
the AR9220 based Ubiquiti SR71-12 and SR71-15 Mini-PCI NICs.
(Note: those NICs don't work right now because of earlier changes to handle
power table offset correctly. That'll be resolved in a follow-up commit.)
|
| 219419 |
09-Mar-2011 |
adrian |
For chips that are full reset in ar5416ChipReset(), save and restore the TSF.
Merlin (ar9280) and later were full-reset if they're doing open-loop TX
power control but the TSF wasn't being saved/restored.
Add ar5212SetTsf64() which sets the 64 bit TSF appropriately.
|
| 219394 |
08-Mar-2011 |
adrian |
Break out the ath regulatory domain structures into a separate header file.
|
| 219393 |
08-Mar-2011 |
adrian |
Implement open-loop TX power control (OLC) for Merlin (AR9280) and
generally tidy up the TX power programming code.
Enforce that the TX power offset for Merlin is -5 dBm, rather than
any other value programmable in the EEPROM. This requires some
further code to be ported over from ath9k, so until that is done
and tested, fail to attach NICs whose TX power offset isn't -5
dBm.
This improves both legacy and HT transmission on my merlin board.
It allows for stable MCS TX up to MCS15.
Specifics:
* Refactor out a bunch of the TX power calibration code -
setting/obtaining the power detector / gain boundaries,
programming the PDADC
* Take the -5 dBm TX power offset into account on Merlin -
"0" in the per-rate TX power register means -5 dBm, not
0 dBm
* When doing OLC
* Enforce min (0) and max (AR5416_MAX_RATE_POWER) when fiddling
with the TX power, to avoid the TX power values from wrapping
when low.
* Implement the 1 dBm cck power offset when doing OLC
* Implement temperature compensation for 2.4ghz mode when doing OLC
* Implement an AR9280 specific TX power calibration routine which
includes the OLC twiddles, leaving the earlier chipset path
(AR5416, AR9160) alone
Whilst here, use these refactored routines for the AR9285 TX power
calibration/programming code and enforce correct overflow/underflow
handling when fiddling with TX power values.
Obtained from: linux ath9k
|
| 219318 |
06-Mar-2011 |
adrian |
Add an EEPROM op that extracts out the power table offset.
It defaults to -5 dBm for eeproms earlier than v21.
This apparently only applies to Merlin (AR9280) or later,
earlier 11n chipsets have a power table offset of 0.
All the code in ath9k which checks the power table offset
and takes it into account first ensures the chip is
Merlin or later.
|
| 219315 |
05-Mar-2011 |
adrian |
Change HALDEBUG() to be a macro that conditionally calls the debug output routine.
The earlier way of doing debugging would evaluate the function parameters
before calling the HALDEBUG. In the case of detailed register debugging
would mean a -lot- of unneeded register IO and other stuff was going on.
This method evaluates the ath_hal_debug variable before the function
parameters are evaluated, drastically reducing the amount of overhead
enabling HAL debugging during compilation.
|
| 219218 |
03-Mar-2011 |
adrian |
Port over ar5416OverrideIni() from ath9k ar5008_hw_override_ini().
* change the BB gating logic to explicitly define which chips are covered;
the ath9k method isn't as clear.
* don't disable the BB gating for now, the ar5416 initvals have it, and the
ar9160 initval sets it to 0x0. Figure out why before re-enabling this.
* migrate the Merlin (ar9280) applicable WAR from the Kite (ar9285) code
(which won't get called for Merlin!) and stuff it in here.
|
| 219217 |
03-Mar-2011 |
adrian |
* fix the ar5416 check macros to be slightly more correct;
* add some stubs for chipsets that we haven't yet obtained support for.
|
| 218923 |
21-Feb-2011 |
adrian |
Add a vocal warning to ath_hal_computetxtime() function is used for non-11n rates.
It's used to calculate:
* the initial per-rate entries for short/long preamble ACK durations;
* packet durations for TDMA slot decisions;
* RTS/CTS protection durations;
* updating the duration field in the 802.11 frame header
This way invalid durations will generate a warning, prompting for it to be
fixed.
|
| 218908 |
21-Feb-2011 |
adrian |
Modify the AR5416 11na rate table to use 24mb OFDM 11a for control traffic,
rather than MCS 0.
Using MCS0 for protecting 11a rates seems a bit silly.
|
| 218764 |
17-Feb-2011 |
adrian |
Add in ANI parameters for the AR9280. These aren't enabled by default
as they're likely not entirely correct, but they give people something
to toy with to compare behaviour/performance.
Disable the anti-noise part, as this apparently interferes with
RIFS. I haven't verified this.
|
| 218763 |
17-Feb-2011 |
adrian |
Add a new parameter to selectively enable/disable the ANI operations.
This was inspired by ath9k, which disables ANI anti-noise immunity
parameter tweaking (but leaves the rest of the ANI operations alone.)
|
| 218762 |
17-Feb-2011 |
adrian |
Call the right function.
|
| 218708 |
15-Feb-2011 |
adrian |
Disable flipping antennas for AR9280.
Flipping antennas when doing 11n would cause all kinds of strange issues.
Just don't do it for now and when it comes time to do it, don't do it here.
|
| 218690 |
14-Feb-2011 |
adrian |
bring this in line with what ath9k does.
|
| 218490 |
09-Feb-2011 |
adrian |
Expose the 4k transaction workaround hooks to the driver, but don't (yet)
fix the descriptor allocation.
|
| 218483 |
09-Feb-2011 |
adrian |
Fix the keycache behaviour for multicast keycache search.
The correct bit to set is 0x1 in the high MAC address byte, not 0x80.
The hardware isn't programmed with that bit (which is the multicast
adress bit.)
The linux ath9k keycache code uses that bit in the MAC as a "this is
a multicast key!" and doesn't set the AR_KEYTABLE_VALID bit.
This tells the hardware the MAC isn't to be used for unicast destination
matching but it can be used for multicast bssid traffic.
This fixes some encryption problems in station mode.
PR: kern/154598
|
| 218441 |
08-Feb-2011 |
adrian |
I missed this commit - enable 4k transaction support for the ar5416+ar9160.
|
| 218436 |
08-Feb-2011 |
adrian |
There's apparently a bug with Merlin (AR9280) and later chipsets where
putting descriptors (not buffers) across a 4k page boundary can cause issues.
I've not seen it in production myself but it apparently can cause problems.
So, in preparation for addressing this workaround, (re)-expose the particular
HAL capability bit which marks whether the chipset has support for cross-4k-
boundary transactions or not.
A subsequent commit will modify the descriptor allocation to avoid allocating
descriptor entries that straddle a 4k page boundary.
|
| 218420 |
07-Feb-2011 |
adrian |
Add in some AR9280 specific board configuration options.
* The existing radio config code was for the AR5416/AR9160 and missed out
on some of the AR9280 specific stuff. Include said stuff from ath9k.
* Refactor out the gain control settings into a new function, again pilfered
from ath9k.
* Use the analog register RMW macro when touching analog registers.
Obtained from: Linux ath9k
|
| 218419 |
07-Feb-2011 |
adrian |
Bring over some AR9280-specific v14 additions that exist in ath9k.
Obtained from: Linux ath9k
|
| 218416 |
07-Feb-2011 |
adrian |
Use analog delay macro for modifying an analog register.
|
| 218415 |
07-Feb-2011 |
adrian |
Add a new RMW macro for analog register writes which implements the needed
wait period between operations.
|
| 218409 |
07-Feb-2011 |
adrian |
Fix typo in SIFS setup
|
| 218354 |
05-Feb-2011 |
adrian |
Add a temporary workaround so the 11n rate scenario setup code sets a useful
TX chainmask.
since the upper layers don't (yet) know about the active TX/RX chainmasks,
it can't tell the rate scenario functions what to use. I'll eventually sort
this out; this restores functionality in the meantime.
|
| 218183 |
02-Feb-2011 |
adrian |
Call the correct ANI Attach routine.
|
| 218170 |
01-Feb-2011 |
adrian |
Just to be sure, make sure the MCS rates are allowed for TX.
Approved by: rpaulo@
|
| 218150 |
01-Feb-2011 |
adrian |
Add a new capability which reports the number of spatial streams a device supports.
The higher levels (net80211, if_ath, ath_rate) need this to make correct
choices about what MCS capabilities to advertise and what MCS rates are
able to be TXed.
In summary:
* AR5416 - 2/3 antennas, 2x2 streams
* AR9160 - 2/3 antennas, 2x2 streams
* AR9220 - 2 antennas, 2x2 sstraems
* AR9280 - 2 antennas, 2x2 streams
* AR9285 - 2 antennas but with antenna diversity, 1x1 stream
|
| 218131 |
31-Jan-2011 |
adrian |
Don't incorrectly set the burst duration setting in the TX descriptor.
After inspecting the ath9k source, it seems the AR5416 and later MACs
don't take an explicit RTS/CTS duration. A per-scenario (ie, what multi-
rate retry became) rts/cts control flag and packet duration is provided;
the hardware then apparently fills in whatever details are required.
The per-rate sp/lpack duration calculation just isn't used anywhere
in the ath9k TX packet length calculations.
The burst duration register controls something different; it seems to
be involved with RTS/CTS protection of 11n aggregate frames and is set
via a call to ar5416Set11nBurstDuration().
I've done some light testing with rts/cts protected frames and nothing
seems to break; but this may break said RTS/CTS and CTS-to-self protection.
|
| 218069 |
29-Jan-2011 |
adrian |
Avoid writing CCA threshold values for the EXT radios for non-HT40 channels.
|
| 218068 |
29-Jan-2011 |
adrian |
Bring over some NF calibration changes from ath9k.
Each different radio chipset has a different "good" range of CCA
(clear channel access) parameters where, if you write something
out of range, it's possible the radio will go deaf.
Also, since apparently occasionally reading the NF calibration
returns "wrong" values, so enforce those limits on what is being
written into the CCA register.
Write a default value if there's no history available.
This isn't the case right now but it may be later on when "off-channel"
scanning occurs without init'ing or changing the NF history buffer.
(As each channel may have a different noise floor; so scanning or
other off-channel activity shouldn't affect the NF history of
the current channel.)
|
| 218067 |
29-Jan-2011 |
adrian |
Fix some errors introduced w/ the last commit; fix setting RTS/CTS in the 11n rate scenario.
* I messed up a couple of things in if_athvar.h; so fix that.
* Undo some guesswork done in ar5416Set11nRateScenario() and introduce a
flags parameter which lets the caller set a few things. To begin with,
this includes whether to do RTS or CTS protection.
* If both RTS and CTS is set, only do RTS. Both RTS and CTS shouldn't be
set on a frame.
|
| 218066 |
29-Jan-2011 |
adrian |
Link in the 11n specific TX methods into the HAL.
|
| 218061 |
29-Jan-2011 |
adrian |
Add a check for the AR9285E; I have no idea what this is.
The only other changes in ath9k for the AR9285E revolve around sleep modes
which are not fully implemented here yet.
|
| 218012 |
28-Jan-2011 |
adrian |
Make space for the extended 802.11n MCS rate tables.
|
| 218011 |
28-Jan-2011 |
adrian |
Bring in some 802.11n packet duration calculation functions from a mix of Sam/Rui and linux ath9k .
This will eventually be used by rate control modules and by the TX
code for calculating packet duration when handling rts/cts protection.
Obtained from: sam@, rpaulo@, linux ath9k
|
| 217930 |
27-Jan-2011 |
adrian |
Initialise the chainmask from the EEPROM rather than the hard-coded defaults.
The defaults enabled three chains on the AR5416 even if the card has two
chains. This restores that and ensures that only the correct TX/RX
chainmasks are used.
When HT modes are enabled, all TX chains will be correctly enabled.
This should now enable analog chain swapping with 2-chain cards.
I'm not sure if this is needed for just the AR5416 or whether
it also applies to AR9160, AR9280 and AR9287 (later on); I'll have
to get clarification.
|
| 217925 |
27-Jan-2011 |
adrian |
Add missing getCapability call for AR5416.
|
| 217923 |
27-Jan-2011 |
adrian |
Make a note to re-check whether that particular check is needed.
|
| 217921 |
27-Jan-2011 |
adrian |
Writing to the analog registers on the AR9220 (Merlin PCI) seems to require a delay.
This, along with an initval change which will appear in a subsequent commit,
fixes bus panics that I have been seing with the AR9220 on a Routerstation Pro
(AR7161 MIPS board.)
Obtained from: Linux ath9k
PR: kern/154220
|
| 217882 |
26-Jan-2011 |
adrian |
Add ar5416RestoreChainMask() which will undo any AR5416 specific chainmask
overriding after calibration.
This will get set for other two chain radios, such as AR9280 and later on,
AR9287. It should however be a nul operation.
|
| 217881 |
26-Jan-2011 |
adrian |
Add an AR5416 workaround - force a different bias based on 2.4ghz channel frequency.
Obtained from: Linux ath9k
|
| 217879 |
26-Jan-2011 |
adrian |
Break out the chainmask init code into a new function - ar5416InitChainMasks() .
ath9k does a few different things here during config - if it's an early
AR5416 with two chains, it enables all three chains for calibration and
then restores the chainmask to the original values after initial
calibration has completed.
The reason behind this commit is to begin breaking out the chainmask
configuration for this specific reason; follow-up commits will add
the chainmask restore in the ar5416Reset() routine.
|
| 217878 |
26-Jan-2011 |
adrian |
* fix HAL_DEBUG_INTERRUPT to be a separate bit, it was overlapping with
something else
* add HAL_DEBUG_GPIO, for some GPIO related debugging I'm tinkering with
at the moment.
|
| 217814 |
25-Jan-2011 |
adrian |
* Re-format the v4k header to be consistent
* Re-do the structure size/component math to make sure the struct matches
the expected size
* Just to be clear that we care about bitmask ordering, revert my previous
change and instead define that macro if we're on big-endian.
|
| 217813 |
25-Jan-2011 |
adrian |
Bring over a fix from ath9k - zero some of the TX descriptors for Kite/AR9285.
Kite doesn't have per-chain control (it has one chain) or antenna control; so
don't try to set those descriptor entries.
|
| 217812 |
25-Jan-2011 |
adrian |
Rename this linux-ism __BIG_ENDIAN_BITFIELD macro to something suitable for FreeBSD.
Warner has pointed out that FreeBSD's bit orders follow byte orders.
|
| 217811 |
25-Jan-2011 |
adrian |
Commit updated AR9285 (Kite) v2 initvals from ath9k.
|
| 217809 |
25-Jan-2011 |
adrian |
Fix the Atheros V4K EEPROM definitions to match those in ath9k.
It turns out that the V4K eeprom definitions (used by the AR9285 and
its derivatives) is wrong. These values are at least causing issues
on my AR2427.
With this fix (and initvals in a subsequent commit), the AR2427 behaves
a lot better.
Note - there's still significant drift between the ath9k v4k eeprom
init code (again, used by AR9285 and derivatives) and what's in this
tree. That needs to be investigated and resolved.
|
| 217790 |
24-Jan-2011 |
adrian |
Remove an invalid register setup; this is likely a holdover from
the AR5212 code. It doesn't exist in ath9k and I've been told it
doesn't exist in the Atheros internal driver.
|
| 217752 |
23-Jan-2011 |
adrian |
Enable the 11n PHY by default whether or not 11n is configured.
The linux ath9k driver and (from what I've been told) the atheros reference
driver does this; it then leaves discarding 11n frames to the 802.11 layer.
Whilst I'm here, merge in a fix from ath9k which maintains a turbo register
setting when enabling the 11n register; and remove an un-needed (duplicate)
flag setting.
|
| 217751 |
23-Jan-2011 |
adrian |
Update the AR9280v2 inivals to match what is in Linux ath9k.
This repairs the behaviour of my AR9280 - both radio chains now seem
to correctly be receiving.
|
| 217687 |
21-Jan-2011 |
adrian |
Fix some typos.
|
| 217686 |
21-Jan-2011 |
adrian |
Add missing getCapability call for AR5416.
|
| 217685 |
21-Jan-2011 |
adrian |
Modify the v14/v4k eeprom diag interface to return the whole eeprom.
The v1 and v3 interfaces returned the whole EEPROM but the v14/v4k
interfaces just returned the base header. There's extra information
outside of that which would also be nice to get access to.
|
| 217684 |
21-Jan-2011 |
adrian |
ANI changes #1 - split out the ANI polling from the RxMonitor hook.
The rxmonitor hook is called on each received packet. This can get very,
very busy as the tx/rx/chanbusy registers are thus read each time a packet
is received.
Instead, shuffle out the true per-packet processing which is needed and move
the rest of the ANI processing into a periodic event which runs every 100ms
by default.
|
| 217641 |
20-Jan-2011 |
adrian |
ar9280SetAntennaSwitch() was using the AR5416 chainmasks (3 chains)
rather than the AR9280 chainmasks (2 chains)
|
| 217634 |
20-Jan-2011 |
adrian |
Only enable 11n modes if the chipset suports 11n.
Since the AR2427 doesn't allow 802.11n, it shouldn't have them
configured.
|
| 217632 |
20-Jan-2011 |
adrian |
Include the device ids for the AR2427.
This is apparently an AR9285 with the 802.11n specific bits disabled.
This code is completely untested; I'm doing this in response to users
who wish to test the functionality out. It's likely as buggy as the
AR9285 support is in FreeBSD at the moment.
|
| 217631 |
20-Jan-2011 |
adrian |
Push the non-AR5416 related stuff into chipset specific directories.
sys/dev/ath/ath_hal/ar5416/ is getting very crowded and further
commits will make it even more crowded. Now is a good time to
shuffle these files out before any more extensive work is done
on them.
Create an ar9003 directory whilst I'm here; ar9003 specific
chipset code will eventually live there.
|
| 217629 |
20-Jan-2011 |
adrian |
Add a comment from my local HAL about what is actually going on here
with these ADC DC Gain/Offset calibrations.
The whole idea is to calibrate a pair of ADCs to compensate for any
differences between them.
The AR5416 returns lots of garbage, so there's no need to do the
calibration there.
The AR9160 returns 0 for secondary ADCs when calibrating 2.4ghz 20mhz
modes. It returns valid data for the secondary ADCs when calibrating
2.4ghz HT/40 and any 5ghz mode.
|
| 217624 |
20-Jan-2011 |
adrian |
Include the initial support for external EEPROMs.
The AR9100 at least doesn't have an external serial EEPROM
attached to the MAC; it instead stores the calibration data
in the normal system flash.
I believe earlier parts can do something similar but I haven't
experienced it first-hand.
This commit introduces an eepromdata pointer into the API but
doesn't at all commit to using it. A future commit will
include the glue needed to allow the AR9100 support code
to use this data pointer as the EEPROM.
|
| 217623 |
20-Jan-2011 |
adrian |
Port over another EEPROM option from ath9k - AR_EEP_DAC_HPWR_5G
This will be used by the temperature compensation calibration code
which will shortly make an appearance.
|
| 217622 |
20-Jan-2011 |
adrian |
Add another HAL function which waits for a register for a configurable amount.
This will be used by some future code.
|
| 217621 |
20-Jan-2011 |
adrian |
Add a new HAL method to retrieve the completion schedule. It sets
the completion schedule from the hardware and returns AH_TRUE if
the hardware supports multi-rate retries (AR5212 and above); and
returns AH_FALSE if the hardware doesn't support multi-rate retries.
The sample rate module directly reads the TX completion descriptor
and extracts the TX schedule information from that. It will be
updated in a future commit to instead use this method to determine
the completion schedule.
|
| 217618 |
20-Jan-2011 |
adrian |
Break out the diagnostic codes from ah_internal.h and place them in ah_diagcodes.h.
Since we now have the source code, there's no reason to hide the diag codes
from other areas.
They live in the HAL as they form part of the HAL API and should still be treate
as "potentially flexible; don't publish as a public API." But since they're
already used as a public API (see follow-up commit), we may as well use
them in place of magic constants.
|
| 211330 |
15-Aug-2010 |
adrian |
Fix indenting/whitespace issues introduced by me.
|
| 211328 |
15-Aug-2010 |
adrian |
The comment is misleading - that register setting seems to kick off the
initial chip NF cal.
|
| 211309 |
14-Aug-2010 |
adrian |
A local addition, not imported from ath9k.
AR_PHY_CALMODE is explicitly reset on interface reset for other chipsets;
this commit also sets it for the AR9160.
|
| 211308 |
14-Aug-2010 |
adrian |
* Merge in AR9160 initval updates from Linux-2.6.34.
* Grab the AR_PHY_CCA and AR_PHY_EXT_CCA initvals from Linux wireless-testing.
Obtained from: Linux-2.6.34
|
| 211307 |
14-Aug-2010 |
adrian |
Merge in a fix for the power/(gain?) calculation. Apply it to both
the 5416/9160 and 9285 code paths.
Obtained from: OpenWRT r22123, 522-ath9k_pwrcal_fix.patch
|
| 211306 |
14-Aug-2010 |
adrian |
Fix the calibration logic to correctly clamp the calculated coefficient.
Obtained from: OpenWRT r22123, 521-ath9k_iqcal_fix.patch
|
| 211214 |
12-Aug-2010 |
adrian |
* Fix indentation
* Restore comment erroneously deleted from the previous commit
|
| 211211 |
12-Aug-2010 |
adrian |
Loading the NF CCA values may take longer than expected to occur.
If it does, don't then try reprogramming the NF "cap" values (ie
what values are the "maximum" value the NF can be) - instead,
just leave the current CCA value as the NF cap.
This was inspired by some similar work from ath9k. It isn't
a 100% complete solution (as there may be some reason where a
high NF CCA/cap is written, causing the baseband to stop thinking it
is able to transmit, leading to stuck beacon and interface reset)
which I'll investigate and look at fixing in a later commit.
Obtained from: Linux
|
| 211210 |
12-Aug-2010 |
adrian |
Use ar5212IsNFCalInProgress() to check for NF calibration progress.
|
| 211209 |
12-Aug-2010 |
adrian |
Fix indentation.
|
| 211208 |
12-Aug-2010 |
adrian |
Ensure that the correct rxchainmask is used when doing calibration in the
AR5416 and later chipsets.
ath_hal_calibrateN() calls the HAL calibrateN function with rxchainmask=0x1.
This is not necessarily the case for AR5416 and later chipsets.
|
| 211207 |
12-Aug-2010 |
adrian |
Internal NF calibration should not occur in parallel with any other
calibration. Ensure that the NF calibration completes before continuing
with the rest of the calibration setup process.
|
| 211206 |
12-Aug-2010 |
adrian |
Add a couple of functions to check NF calibration progress / completion.
|
| 211135 |
10-Aug-2010 |
adrian |
Bring over ar5416 inivals from Linux-2.6.34.
Reviewed by: rpaulo@
Obtained from: Linux
|
| 211134 |
10-Aug-2010 |
adrian |
Re-format the ar5416 inivals to be consistent with what
Linux ath9k uses.
|
| 209548 |
27-Jun-2010 |
rpaulo |
Fix typo introduced in previous revision.
|
| 209541 |
26-Jun-2010 |
rpaulo |
Fix the AR_SREV_MERLIN_20_OR_LATER() check.
Submitted by: Alex Kozlov <spam at rm-rf.kiev.ua>
MFC after: 2 weeks
|
| 208712 |
01-Jun-2010 |
rpaulo |
Rewrite ar9285SetBoardValues() to match what ath9k does and fix out of
bounds reads.
MFC after: 3 days
|
| 208711 |
01-Jun-2010 |
rpaulo |
Bring in a couple of fixes from the Linux ath9k related to chip hangs.
While there, try to make the register write pattern look like what's
done by ath9k.
MFC after: 3 days
|
| 208703 |
01-Jun-2010 |
rpaulo |
Fix an off by one in ar9285SetPowerCalTable().
Found with: Coverity Prevent(tm)
CID: 3979
MFC after: 3 days
|
| 208644 |
29-May-2010 |
rpaulo |
Due to the way HALDEBUG() is defined, we need to add curly brackets
when using it as a sole if clause instruction.
While there, fix 'const static' typo.
Submitted by: Arnaud Lacombe <alc@FreeBSD.org>
MFC after: 1 week
|
| 208643 |
29-May-2010 |
rpaulo |
Due to the way HALDEBUG() is defined, we need to add curly brackets when
using it as a sole if clause instruction.
Submitted by: Arnaud Lacombe <alc@FreeBSD.org>
MFC after: 1 week
|
| 208642 |
29-May-2010 |
rpaulo |
Don't shadow the global variable 'version'.
Submitted by: Arnaud Lacombe <alc@NetBSD.org>
MFC after: 1 week
|
| 207472 |
01-May-2010 |
imp |
The Atheros AR71xx CPUs, when paired with the AR5212 parts, has a bug
that generates a fatal bus trap. Normally, the chips are setup to do
128 byte DMA bursts, but when on this CPU, they can only safely due
4-byte DMA bursts due to this bug. Details of the exact nature of the
bug are sketchy, but some can be found at
https://forum.openwrt.org/viewtopic.php?pid=70060 on pages 4, 5 and 6.
There's a small performance penalty associated with this workaround,
so it is only enabled when needed on the Atheros AR71xx platforms.
Unfortunately, this condition is impossible to detect at runtime
without MIPS specific ifdefs. Rather than cast an overly-broad net
like Linux/OpenWRT dues (which enables this workaround all the time on
MIPS32 platforms), we put this option in the kernel for just the
affected machines. Sam didn't like this aspect of the patch when he
reviewed it, and I'd love to hear sane proposals on how to fix it :)
Reviewed by: sam@
|
| 206496 |
12-Apr-2010 |
rpaulo |
Remove svn:executable prop.
|
| 206420 |
09-Apr-2010 |
rpaulo |
Setup the correct RX/TX chainmask when we play with the antenna
settings.
MFC after: 1 week
Sponsored by: iXsystems, inc
|
| 204645 |
03-Mar-2010 |
rpaulo |
Introduce ath_hal_setInterrupts(), a macro for ah_setInterrupts().
Pointed out by: sam
|
| 204644 |
03-Mar-2010 |
rpaulo |
Replace Id keyword with FreeBSD keyword and set the svn props correctly.
No functional change.
|
| 204579 |
02-Mar-2010 |
rpaulo |
Couple of suggestions from Sam regarding latest commit:
o rename the new variables to comply with the naming scheme
o move the new variables to an AR5212 specific struct
o use ahp when available
o revert to previous ts_flags check
|
| 204521 |
01-Mar-2010 |
rpaulo |
Properly setup the TX FIFO threshold for AR5416 based chipsets,
including the AR9285. This seems to fix some users's problems.
Submitted by: Jorge Boncompte [DTI2] <jorge at dti2.net>
|
| 203959 |
16-Feb-2010 |
rpaulo |
Fix Kite and Merlin version check.
|
| 203933 |
15-Feb-2010 |
rpaulo |
Fix KITE version check.
Obtained from: //depot/user/rpaulo/80211n/...
|
| 203930 |
15-Feb-2010 |
rpaulo |
Bring back AR9285 support. This fixes most of the issues and should be
pretty usable.
MFC after: 1 month
|
| 203882 |
14-Feb-2010 |
rpaulo |
Revert part of the 9285 support because it breaks the 9280 support. I'll
try to do the 9285 support without interfering with any other chipset
revisions support.
|
| 203750 |
10-Feb-2010 |
rpaulo |
't' stands for Turbo and is a valid mode, so fix previous commit.
Pointed out by: sam
|
| 203682 |
08-Feb-2010 |
rpaulo |
Fix TX power problems with AR9285.
|
| 203680 |
08-Feb-2010 |
rpaulo |
Fix typo in comment.
|
| 203159 |
29-Jan-2010 |
rpaulo |
Add support for the AR9285 chipset, which is found on many netbooks
available today.
This card is a low power 802.11bgn that only does 11n rates up to MCS 7
(that's 65 Mbps in 20Mhz mode and 135 in 40Mhz mode).
802.11n is not yet supported, but will be in the future.
The driver still has a problem regarding to the setting of txpower on
the card, so don't expect good performance yet. After fixing this
problem, an MFC is possible.
Special thanks to iXsystems and S Smirnov <tonve at yandex.ru> for help
with the purchase of a netbook with this card.
Sponsored by: iXsystems, Inc.
|
| 203158 |
29-Jan-2010 |
rpaulo |
Replace Id keyword with the FreeBSD keyword.
|
| 203156 |
29-Jan-2010 |
rpaulo |
Replace Id keyword with the FreeBSD keyword.
|
| 202161 |
12-Jan-2010 |
gavin |
Spell "Hz" correctly wherever it is user-visible.
PR: bin/142566
Submitted by: N.J. Mann njm njm.me.uk
Approved by: ed (mentor)
MFC after: 2 weeks
|
| 201758 |
07-Jan-2010 |
mbr |
Remove extraneous semicolons, no functional changes.
Submitted by: Marc Balmer <marc@msys.ch>
MFC after: 1 week
|
| 199491 |
18-Nov-2009 |
rpaulo |
Add WorldB SKU.
Reviewed by: sam
MFC after: 1 week
|
| 197948 |
10-Oct-2009 |
rpaulo |
Atheros EEPROM version 4K. This version is mostly based on version 1.4.
This is needed by the upcoming AR9285 support.
Information on the layout gathered from Linux ath9k.
Not yet connected to the build.
Tested by: Eugeny Dzhurinsky
|
| 196970 |
08-Sep-2009 |
phk |
Revert previous commit and add myself to the list of people who should
know better than to commit with a cat in the area.
|
| 196969 |
08-Sep-2009 |
phk |
Add necessary include.
|
| 196934 |
07-Sep-2009 |
sam |
fix extraneous return that can cause a memory leak
Submitted by: phk
MFC after: 1 week
|
| 196603 |
27-Aug-2009 |
sam |
change default regdomain for thailand
Obtained from: linux-wireless@kernel.org
|
| 195809 |
21-Jul-2009 |
sam |
Fix handling of AR_RX_FILTER_BSSID: write the shadow value for AR_MISC_MODE
so other register writes preserve the setting of AR_MISC_MODE_BSSID_MATCH_FORCE.
Reviewed by: rpaulo
Approved by: re (kib)
|
| 195426 |
07-Jul-2009 |
sam |
Fix ar5416 and later parts on big-endian platforms: setup the h/w byte
swizzler using the same technique used everywhere else.
Approved by: re (kib)
|
| 195135 |
28-Jun-2009 |
phk |
Revert a local change that should not have been in the last commit.
Approved by: re (kib)
|
| 195134 |
28-Jun-2009 |
phk |
There are a number of ways an application can check if there are
inbound data waiting on a filedescriptor, such as a pipe or a socket,
for instance by using select(2), poll(2), kqueue(2), ioctl(FIONREAD)
etc.
But we have no way of finding out if written data have yet to be
disposed of, for instance, transmitted (and ack'ed!) to some remote
host, or read by the applicantion at the far end of the pipe.
The closest we get, is calling shutdown(2) on a TCP socket in
non-blocking mode, but this has the undesirable sideeffect of
preventing future communication.
Add a complement to FIONREAD, called FIONWRITE, which returns the
number of bytes not yet properly disposed of. Implement it for
all sockets.
Background:
A HTTP server will want to time out connections, if no new request
arrives within a certain period after the last transmitted response
has actually been sent (and ack'ed).
For a busy HTTP server, this timeout can be subsecond duration.
In order to signal to a load-balancer that the connection is truly
dead, TCP_RST will be the preferred method, as this avoids the need
for a RTT delay for FIN handshaking, with a client which, surprisingly
often, no longer at the remote IP number.
If a slow, distant client is being served a response which is big
enough to fill the window, but small enough to fit in the socket
buffer, the write(2) call will return immediately.
If the session timeout is armed at that time, all bytes in the
response may not have been transmitted by the time it fires.
FIONWRITE allows the timeout to check that no data is outstanding
on the connection, before it TCP_RST's it.
Input & Idea from: rwatson
Approved by: re (kib)
|
| 195114 |
27-Jun-2009 |
sam |
Add HAL_RX_FILTER_BSSID support (to disable bssid match):
o add HAL_CAP_BSSIDMATCH to identify parts that have the support for
disabling bssid match
o honor capability for set/get rx filter
o use HAL_CAP_BSSIDMATCH in driver to decide whether to use the bssid
match disable or fall back to promisc mode
Reviewed by: rpaulo
Approved by: re (rwatson)
|
| 194135 |
13-Jun-2009 |
sam |
purge HAL_TXSTAT_ALTRATE; you can figure this out by checking ts_finaltsi
and it cannot be used with MCS rate codes
|
| 192401 |
19-May-2009 |
sam |
correct HAL_INT_BNR comment, this bit is mapped directly the h/w now
|
| 192400 |
19-May-2009 |
sam |
add TBTT interrupt support; this was added in Griffin so consumers should
check HAL_CAP_INTRMASK before using it
NB: didn't test 11n parts yet so supported only for 5212-class parts
|
| 192399 |
19-May-2009 |
sam |
minor cleanup
|
| 192397 |
19-May-2009 |
sam |
remove special handling for BNR; it is direct mapped to the harwdare so
can be added to HAL_INT_COMMON except on the 5210 where it doesn't exist
|
| 192396 |
19-May-2009 |
sam |
add HAL_CAP_INTRMASK to return the set of interrupts supported by the device
|
| 191909 |
08-May-2009 |
sam |
kill more portability functions that are no longer useful
|
| 191864 |
06-May-2009 |
sam |
add support for the Beacon Not Ready (BNR) interrupt
(available on 5211 and later)
|
| 191022 |
13-Apr-2009 |
sam |
o eliminate a << in calculating the tx time for turbo mode by pre-multiplying
data in the phy tables
o correct the ctrl rate indices in the 5212 turbog phy table
|
| 190867 |
09-Apr-2009 |
sam |
check the method pointer before invoking ah_eepromDetach as it can
be null if attach work fails before hooking up the eeprom support
Obtained from: madwifi
|
| 190096 |
19-Mar-2009 |
sam |
purge hal abi support; now that the hal is merged w/ the driver
we cannot be out of sync
MFC after: 1 week
|
| 189747 |
12-Mar-2009 |
sam |
preliminary ar9280 support:
o add 9280 attach that sets up ini, cal, etc.
o new rf backend for 9280 and later parts
o split ini setup and spur mitigation support out to methods
and provide 9280-specific support
o minor fixups to shared code to handle 9280-specific work
Obtained from: Atheros (ini values and some code)
|
| 189713 |
12-Mar-2009 |
sam |
add asserts
|
| 189604 |
09-Mar-2009 |
sam |
remove ar9160Detach; it does nothing
|
| 188993 |
24-Feb-2009 |
sam |
fix typo's
|
| 188980 |
24-Feb-2009 |
sam |
move attach debug msg to the rf backend
|
| 188979 |
24-Feb-2009 |
sam |
Add PCIE power control api:
o add ah_configPCIE and ah_disablePCIE for drivers to configure PCIE
power save operation (modeled after ath9k, may need changes)
o add private state flag to indicate if device is PCIE (replaces private
hack in 5212 code)
o add serdes programming ini bits for 5416 and later parts and setup
for each part (5416 and 9160 logic hand-crafted from existing routines);
5212 remains open-coded but is now hooked in via ah_configPCIE
o add PCIE workaround gunk
o add ar5416AttachPCIE for iodomatic code used by 5416 and later parts
|
| 188976 |
24-Feb-2009 |
sam |
Fill in gpio support for 5416 and later parts:
o add output mux support
o gpio pin count is chip-dependent
o 9280 and 9285 do input handling different
o hookup gpio interrupts
o no need to save/restore soft led state around reset
|
| 188975 |
24-Feb-2009 |
sam |
misc fixups, mostly for code not compiled yet
|
| 188974 |
24-Feb-2009 |
sam |
5416 and later parts mux the gpio outputs; extend the api to include
a signal type that's used to select the appropriate mux
|
| 188973 |
24-Feb-2009 |
sam |
move eeprom attach above first reset as the reset code checks the
eeprom contents for 9280 and later parts
|
| 188972 |
24-Feb-2009 |
sam |
attach methods don't need to be public, make 'em static
|
| 188971 |
23-Feb-2009 |
sam |
5416 and later parts get the radio rev differently; add ar5416GetRadioRev
to do it the right way
|
| 188970 |
23-Feb-2009 |
sam |
remove private copies of gpio methods that were needed when the hal
was an independent entity
|
| 188968 |
23-Feb-2009 |
sam |
print mac+rf part names; drop the printing 2ghz rf stuff (might come back)
|
| 188866 |
20-Feb-2009 |
sam |
correct SIFS setting; there is a 2usec adjustment between the calculated
value and what the hardware requires (based on inspection of INI values)
Submitted by: Jiri Fojtasek <jiri.fojtasek@hlohovec.net>
|
| 188865 |
20-Feb-2009 |
sam |
don't adjust core clk conversions for 1/2 and 1/4 rate channels; the
mac runs at full speed so doing this breaks conversion for ifs parameters
Submitted by: Felix Fietkau <nbd@openwrt.org>
|
| 188773 |
19-Feb-2009 |
sam |
Cleanup ath_hal_computetxtime's handling of 1/2 and 1/4-width channels:
o mark phy type to indicate 1/2 or 1/4-rate operation
o use phy type instead of channel attributes to identify 1/2 and 1/4-rate
operation
o general cleanup of code including move phy constants to ah_internal.h
Eventually this code should go away and we should use the net0211 equivalents.
|
| 188771 |
19-Feb-2009 |
sam |
add HAL_DIAG_SETREGS to write registers via the diag api
|
| 188770 |
19-Feb-2009 |
sam |
whitespace
|
| 188549 |
13-Feb-2009 |
sam |
Recognize AR5212_AR2317_REV2 in ar5312Probe()
Submitted by: Pavel Roskin <proski@gnu.org>
|
| 188504 |
11-Feb-2009 |
sam |
fix both instances of name
Pointy hat: sam
|
| 188500 |
11-Feb-2009 |
sam |
fix typo in AH_CHIP definition
Submitted by: Pavel Roskin <proski@gnu.org>
|
| 188499 |
11-Feb-2009 |
sam |
gcc 4.3.2 examines getLowerUpperIndex() and concludes that it's not
guaranteed to initialize its two last arguments. Therefore, there is a
warning in the subsequent caller ar5416FillVpdTable(), which doesn't
initialize those arguments.
Change getLowerUpperIndex() to assign values to indexL and indexR even
in the case of assertion failure.
Submitted by: Pavel Roskin <proski@gnu.org>
|
| 188444 |
10-Feb-2009 |
sam |
consolidate conditional code
|
| 188264 |
07-Feb-2009 |
sam |
fix 11n channel construction
|
| 188263 |
07-Feb-2009 |
sam |
add macro for future regulatory mods
|
| 188213 |
06-Feb-2009 |
sam |
add PSB channels to the calibration list
|
| 188197 |
05-Feb-2009 |
sam |
eliminate gainFCorrection; just have ar5212GetGainFCorrection return
the calculated value as it's only used in one place
|
| 188194 |
05-Feb-2009 |
sam |
improve IQ cal debug msgs; in particular don't scare people by screaming
"MISGATED IQ CAL!" when it's not
|
| 188193 |
05-Feb-2009 |
sam |
fill in ar5212ResetCalValid; reset the IQ valid flag on the channel
so IQ calibration will be started on the next periodic cal
|
| 188192 |
05-Feb-2009 |
sam |
style
|
| 188191 |
05-Feb-2009 |
sam |
replace r/w idiom with OS_REG_SET_BIT (to match other code)
|
| 188084 |
03-Feb-2009 |
sam |
fix compilation w/ AH_DEBUG
|
| 188012 |
02-Feb-2009 |
sam |
o make SAVE_CCK slightly less error prone by always writing the _flag
value used later by RESTORE_CCK
o swap arg order in RESTORE_CCK to slightly reduce cost
|
| 188011 |
02-Feb-2009 |
sam |
restore variable initialization removed in r187831; this broke
the horrible SAVE/RESTORE_CCK macros used by swan/nala cards to
implement 11b using 11g
|
| 187831 |
28-Jan-2009 |
sam |
Overhaul regulatory support:
o remove HAL_CHANNEL; convert the hal to use net80211 channels; this
mostly involves mechanical changes to variable names and channel
attribute macros
o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant
with the net80211 channel available
o change api for ath_hal_init_channels: no more reglass id's, no more outdoor
indication (was a noop), anM contents
o add ath_hal_getchannels to have the hal construct a channel list without
altering runtime state; this is used to retrieve the calibration list for
the device in ath_getradiocaps
o add ath_hal_set_channels to take a channel list and regulatory data from
above and construct internal state to match (maps frequencies for 900MHz
cards, setup for CTL lookups, etc)
o compact the private channel table: we keep one private channel
per frequency instead of one per HAL_CHANNEL; this gives a big
space savings and potentially improves ani and calibration by
sharing state (to be seen; didn't see anything in testing); a new config
option AH_MAXCHAN controls the table size (default to 96 which
was chosen to be ~3x the largest expected size)
o shrink ani state and change to mirror private channel table (one entry per
frequency indexed by ic_devdata)
o move ani state flags to private channel state
o remove country codes; use net80211 definitions instead
o remove GSM regulatory support; it's no longer needed now that we
pass in channel lists from above
o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A
o simplify initial channel list construction based on the EEPROM contents;
we preserve country code support for now but may want to just fallback
to a WWR sku and dispatch the discovered country code up to user space
so the channel list can be constructed using the master regdomain tables
o defer to net80211 for max antenna gain
o eliminate sorting of internal channel table; now that we use ic_devdata
as an index, table lookups are O(1)
o remove internal copy of the country code; the public one is sufficient
o remove AH_SUPPORT_11D conditional compilation; we always support 11d
o remove ath_hal_ispublicsafetysku; not needed any more
o remove ath_hal_isgsmsku; no more GSM stuff
o move Conformance Test Limit (CTL) state from private channel to a lookup
using per-band pointers cached in the private state block
o remove regulatory class id support; was unused and belongs in net80211
o fix channel list construction to set IEEE80211_CHAN_NOADHOC,
IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT
o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are
now set in the constructed net80211 channel
o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one
of the driver-private flag bits of the net80211 channel
o move 900MHz frequency mapping into the hal; the mapped frequency is stored
in the private channel and used throughout the hal (no more mapping in the
driver and/or net80211)
o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the
calculation and available in the net80211 channel
o change noise floor calibration logic to work with compacted private channel
table setup; this may require revisiting as we no longer can distinguish
channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used
only to calculate status data we can live with it for now
o change ah_getChipPowerLimits internal method to operate on a single channel
instead of all channels in the private channel table
o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency
(always the same except for 900MHz channels)
o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory
problems
o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now
o change ath_hal_getwirelessmodes to really return wireless modes supported
by the hardware (was previously applying regulatory constraints)
o return channel interference status with IEEE80211_CHANSTATE_CWINT (should
change to a callback so hal api's can take const pointers)
o remove some #define's no longer needed with the inclusion of
<net80211/_ieee80211.h>
Sponsored by: Carlson Wireless
|
| 187611 |
23-Jan-2009 |
sam |
fix return status handling by ar5XXXReset; this is the reason the
driver sometimes reports reset failed w/ status 0
|
| 187510 |
21-Jan-2009 |
sam |
correct typo that left programmed sifs time in the slot time
(to be applied on subsequent resets)
Submitted by: Jiri Fojtasek <jiri.fojtasek@hlohovec.net>
|
| 187345 |
16-Jan-2009 |
sam |
export PSB frequencies
|
| 187129 |
13-Jan-2009 |
sam |
On some platforms touching the bb registers when the phy is powered
down will cause a fault. Check the phy power state before possibly
reading from the bb, this can happen as ar5212Reset intentionally
calls ar5212GetRfgain before bringing the bb out of reset (but we
do it here and not in the caller to guard against other possible uses).
|
| 186333 |
19-Dec-2008 |
sam |
add FreeBSD property
|
| 186332 |
19-Dec-2008 |
sam |
Correct 5212 ani support so that max noise immunity, spur immunity, and
step levels are used.
Noticed by: Jiri Fojtasek <jiri.fojtasek@hlohovec.net>
Reviewed by: rpaulo
|
| 186098 |
15-Dec-2008 |
sam |
fix ini setup
Submitted by: Jiri Fojtasek <jiri.fojtasek@hlohovec.net>
|
| 186020 |
13-Dec-2008 |
sam |
o remove dead code
o fix AH_RF macro expansion to be as intended (worked before unintentionally)
Obtained from: netbsd
|
| 186019 |
13-Dec-2008 |
sam |
remove dead code
Obtained from: netbsd
|
| 186018 |
13-Dec-2008 |
sam |
add const
Obtained from: netbsd
|
| 186017 |
13-Dec-2008 |
sam |
fix static const order
Obtained from: netbsd
|
| 186016 |
13-Dec-2008 |
sam |
fix static const order
Obtained from: netbsd
|
| 186015 |
13-Dec-2008 |
sam |
remove duplicate case
Obtained from: netbsd
|
| 186014 |
13-Dec-2008 |
sam |
remove conflicting decl
Obtained from: netbsd
|
| 185907 |
11-Dec-2008 |
sam |
add missing break
Coverity ID: 4159
|
| 185906 |
11-Dec-2008 |
sam |
add missing break
Coverity ID: 4151
|
| 185521 |
01-Dec-2008 |
sam |
import ath hal
|
| 185470 |
30-Nov-2008 |
sam |
purge useless code
|
| 185469 |
30-Nov-2008 |
sam |
make code compile
|
| 185467 |
30-Nov-2008 |
sam |
not needed any more
|
| 185466 |
30-Nov-2008 |
sam |
move bus+softc typedefs to ah_osdep.h so we can eliminate the opaque
write-around; it doesn't work for some platforms (e.g. ia64) and is
now pointless
|
| 185418 |
28-Nov-2008 |
sam |
add chip+rf names for debug msgs, showing compiled-in support, etc.
|
| 185417 |
28-Nov-2008 |
sam |
use os shim for linker set walking
|
| 185416 |
28-Nov-2008 |
sam |
remove ath_hal_buildopts and ath_hal_version; they are not needed any more
|
| 185412 |
28-Nov-2008 |
sam |
kill AH_DISABLE_WME stuff; it's been posible to do this from the
driver for a while
|
| 185407 |
28-Nov-2008 |
sam |
bump for linke set changes
|
| 185406 |
28-Nov-2008 |
sam |
Replace most compile-time support options with linker sets for
chip and RF backend support:
o add OS_DATA_SET and OS_SET_DECLARE os requirements for setting
up linker sets
o add AH_CHIP macro for registering chip support (e.g. 5210)
o add AH_RF macro for registering RF support (e.g. 2413); note
this isn't required for single chip solutions where there's no
ambiguity (e.g. 5416/9160+2133) but for 5212 class parts it's
required because of the multi-chip solutions
o remove all uses of AH_SUPPORT_AR5210, AH_SUPPORT_AR5211, AH_SUPPORT_5212,
and AH_SUPPORT_AR9160; still need AH_SUPPORT_AR5416 to enable the 11n
descriptor formats and 5312 support is presently broken
o remove all uses of AH_SUPPORT_2133, AH_SUPPORT_2413, AH_SUPPORT_5111,
AH_SUPPORT_5112, AH_SUPPORT_2417, AH_SUPPORT_2425, and AH_SUPPORT_5413;
5312-related support still requires fixup
Remaining issues:
o fixup SoC attach
o ath_hal_attach uses a hack to probe w/o access to the vendorid
o fallback handling of parts w/o a macrev needs to be restored
|
| 185380 |
28-Nov-2008 |
sam |
Update to later code from my repository:
o many bug fixes
o add new periodic calibration api
o break up 5416 periodic calibration code in preparation for 928x
o move get noise floor to rf backends
o 5416-specific ani (still disabled)
o modularize 5210 eeprom format a la other eeprom formats
o start cleaning up regdomain code
o prepare for proper 1/2 and 1/4 width channel support
o bring back 900MHz card support
o clean up 5212 rf version handling
o add 1/2 and 1/4 width channel support for 5212 parts
o split 5212 rfgain handling out
o improve ani debugging
o add AH_USE_INIPDGAIN compile option
o purge a bunch of dead 5212 state
o add 1/2 and 1/4 rate modes
o remove HAL_CAP_CHAN_HALFRATE and HAL_CAP_CHAN_QUARTERRATE; the
same info can now be deduced from the set of supported modes
|
| 185379 |
28-Nov-2008 |
sam |
not needed
|
| 185378 |
28-Nov-2008 |
sam |
remove unneeded stuff
|
| 185377 |
28-Nov-2008 |
sam |
virgin import of ath hal
|