#
259065 |
|
07-Dec-2013 |
gjb |
- Copy stable/10 (r259064) to releng/10.0 as part of the 10.0-RELEASE cycle. - Update __FreeBSD_version [1] - Set branch name to -RC1
[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so start releng/10.0 at '100' so the branch is started with a value ending in zero.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
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.
|
#
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
|
#
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.
|
#
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
|
#
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
|
#
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.
|
#
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
|
#
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.
|
#
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.
|
#
233329 |
|
22-Mar-2012 |
adrian |
Sprinkle some style(9) things around.
|
#
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.
|
#
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
|
#
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.
|
#
227080 |
|
04-Nov-2011 |
adrian |
Call the correct chipset power routine when disabling the AR5416 and later NICs.
|
#
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.
|
#
226760 |
|
25-Oct-2011 |
adrian |
Save and restore the association ID across interface resets.
Obtained from: Atheros MFC after: 1 week
|
#
225924 |
|
02-Oct-2011 |
adrian |
Document exactly what the RX interrupt mitigation timers do.
|
#
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.
|
#
225444 |
|
07-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)
|
#
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)
|
#
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
|
#
222054 |
|
18-May-2011 |
adrian |
This isn't needed any longer, it's defined in ah_internal.h.
|
#
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.
|
#
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.
|
#
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
|
#
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.
|
#
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
|
#
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
|
#
221535 |
|
06-May-2011 |
adrian |
Add a function which enables or disables RX RIFS searching, and migrate the code which does this into it.
|
#
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.
|
#
220955 |
|
22-Apr-2011 |
adrian |
Fix the merlin LNA configuration code - these are bit flags, not raw values to be written into the registers.
|
#
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
|
#
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.
|
#
220294 |
|
03-Apr-2011 |
adrian |
Import a fix from the ath9k - reduce the TX FIFO size for Kite (AR9285.)
|
#
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.
|
#
219975 |
|
24-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.
|
#
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
|
#
219860 |
|
22-Mar-2011 |
adrian |
Set the "right" CCA register.
Obtained From: ath9k
|
#
219855 |
|
21-Mar-2011 |
adrian |
Break out the RF mode setup into ar5416SetRfMode(), mirroring what ath9k does.
|
#
219854 |
|
21-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.
|
#
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.
|
#
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.
|
#
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
|
#
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.
|
#
218690 |
|
14-Feb-2011 |
adrian |
bring this in line with what ath9k does.
|
#
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
|
#
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.
|
#
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.
|
#
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.
|
#
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.
|
#
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
|
#
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
|
#
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>
|
#
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.
|
#
203682 |
|
08-Feb-2010 |
rpaulo |
Fix TX power problems with AR9285.
|
#
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.
|
#
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)
|
#
191909 |
|
07-May-2009 |
sam |
kill more portability functions that are no longer useful
|
#
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)
|
#
188976 |
|
23-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 |
|
23-Feb-2009 |
sam |
misc fixups, mostly for code not compiled yet
|
#
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>
|
#
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
|
#
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 |
|
27-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 |
|
27-Nov-2008 |
sam |
virgin import of ath hal
|