267654 |
20-Jun-2014 |
gjb |
Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
263447 |
20-Mar-2014 |
dim |
MFC r243164 (by 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.
|
243261 |
19-Nov-2012 |
adrian |
Merge r227468: Don't fondle this particular CCA register from extension channel.
|
229740 |
06-Jan-2012 |
dim |
MFC r228817:
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.
|
225736 |
23-Sep-2011 |
kensmith |
Copy head to stable/9 as part of 9.0-RELEASE release cycle.
Approved by: re (implicit)
|
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)
|
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)
|
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)
|
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)
|
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
|
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
|
222315 |
26-May-2011 |
adrian |
Make sure only two chains are calibrated for the AR9287.
|
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
|
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.
|
222054 |
18-May-2011 |
adrian |
This isn't needed any longer, it's defined in ah_internal.h.
|
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.
|
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.
|
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
|
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().
|
221701 |
09-May-2011 |
adrian |
Fix a regression I introduced - only swap analog chains if the RX chainmask is 0x5.
|
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.)
|
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.
|
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.
|
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.
|
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.
|
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
|
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.
|
220598 |
13-Apr-2011 |
adrian |
Change this to be less noisy.
|
220539 |
11-Apr-2011 |
adrian |
De-dup the ar5416 rates array definition.
|
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.
|
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.
|
220294 |
03-Apr-2011 |
adrian |
Import a fix from the ath9k - reduce the TX FIFO size for Kite (AR9285.)
|
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.
|
219984 |
25-Mar-2011 |
adrian |
I broke periodic adc calibrations - so restore them to working order.
|
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.
|
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.
|
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.
|
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.
|
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().
|
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.
|
219443 |
10-Mar-2011 |
adrian |
Merlin fix - first pdadc gain index is 0 - minpwr/2 .
Obtained from: Linux ath9k
|
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.
|
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
|
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.
|
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.
|
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.
|
218690 |
14-Feb-2011 |
adrian |
bring this in line with what ath9k does.
|
218441 |
08-Feb-2011 |
adrian |
I missed this commit - enable 4k transaction support for the ar5416+ar9160.
|
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
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
217687 |
21-Jan-2011 |
adrian |
Fix some typos.
|
217686 |
21-Jan-2011 |
adrian |
Add missing getCapability call for AR5416.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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
|
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
|
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.
|
201758 |
07-Jan-2010 |
mbr |
Remove extraneous semicolons, no functional changes.
Submitted by: Marc Balmer <marc@msys.ch> MFC after: 1 week
|
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
|
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)
|
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)
|
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)
|
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>
|
188084 |
03-Feb-2009 |
sam |
fix compilation w/ AH_DEBUG
|
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
|
186333 |
19-Dec-2008 |
sam |
add FreeBSD property
|
185521 |
01-Dec-2008 |
sam |
import ath hal
|
185418 |
28-Nov-2008 |
sam |
add chip+rf names for debug msgs, showing compiled-in support, etc.
|
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
|
185377 |
28-Nov-2008 |
sam |
virgin import of ath hal
|