The row/column sizes can be derived from the array argument within the macro
itself, which is less error prone. In a few cases the supplied column size
was actually wrong.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
for AR9002 family of chipsets and for WoW sleep, we reprogram
the SerDes so that the PLL and CHK REQ are both enabled. this
uses more power but in certain cases this is required as otherwise
WoW sleep is unstable and chip may disappear.
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Cc: vadivel@qca.qualcomm.com
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It was found to be buggy on a variety of chipsets from AR913x to AR928x.
The new version (which was introduced along with AR93xx support) is more
reliable in preventing connectivity dropouts and also fixes MIB interrupt
storm issues.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Program tx gain through iniModesTxGain like on AR9287
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
use iniModesFastClock for 5 ghz fast clock specific settings, and
iniAdditional for clock/chip specific initval overrides
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Comparing SHA1 checksums of the initval tables has shown that there are many
tables that are 100% identical.
iniBank{0,1,2,3,7} and iniBB_RfGain are shared by AR5416, AR913x, AR9160
iniBank6 is shared between AR5416 and AR9160
iniBank6TPC is shared between AR913x and AR9160
iniPcieSerdes is the same for all AR9002 based devices
The CCK FIR coefficients are shared between AR9271 and AR9287
Getting rid of those duplicates saves about 7.5k uncompressed (on MIPS).
For AR9003 and later there are some duplicates as well, but I've decided to
leave them in for now, as the initvals for those chips are still actively
maintained by QCA.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Duplicate the data for iniAddac early on, to avoid having to do redundant
memcpy calls later. While we're at it, make AR5416 < v2.2 use the same
codepath. Fixes a reported crash on x86.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Magnus Määttä <magnus.maatta@logica.com>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
These files were using moduleparam infrastructure, but were not
including anything for it -- which is fine when module.h is being
implicitly included in all files, but that is going away.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
It was used for the defunct 'turbo' mode which was never implemented in the
driver. Saves ~7.5k uncompressed
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move common checks into wrapper function. Since ASPM can be only enabled
on PCIe devices ->is_pciexpress check is unneeded.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We always call ->config_pci_powersave() with both restore and power_off
arguments equal to 0 or both equal to 1, so merge them into one
argument.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We receive many bug reports about system hang during suspend/resume
when ath9k driver is in use. Adrian Chadd remarked that this problem
happens on systems that have ASPM disabled.
To do not hit the bug, skip doing ->config_pci_powersave magic if PCIe
downstream port device, which ath9k device is connected to, has ASPM
disabled.
Bug was introduced by:
commit 53bc7aa08b
Author: Vivek Natarajan <vnatarajan@atheros.com>
Date: Mon Apr 5 14:48:04 2010 +0530
ath9k: Add support for newer AR9285 chipsets.
Patch should address:
https://bugzilla.kernel.org/show_bug.cgi?id=37462https://bugzilla.kernel.org/show_bug.cgi?id=37082https://bugzilla.redhat.com/show_bug.cgi?id=697157
however I did not receive confirmation about that, except from Camilo
Mesias, whose system stops hang regularly with this patch (but still
hangs from time to time, but this is probably some other bug).
Tested-by: Camilo Mesias <camilo@mesias.co.uk>
Cc: stable@kernel.org # 2.6.35+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Now that the clock rate is initialized properly and SIFS, EIFS, USEC,
slot time and ACK timeout are properly calculated by the generic code,
the 'async FIFO' register hacks are no longer necessary.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The bit 6 & 7 of AR_WA (0x4004) should be enabled only
for the chips that are supporting L0s functionality
while resuming back from S3/S4.
Enabling these bits for AR9280 is causing system hang
within a few S3/S4-resume cycles.
Cc: stable@kernel.org
Cc: Jack Lee <jlee@atheros.com>
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There's no need to have separate callbacks for pre-AR9003 vs AR9003
SREV version checks, so just merge those into one function.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
So these errors are always emitted at KERN_ERR level.
Remove ARRAY_SIZE casts, use printf type %zu
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bit 22 of AR_WA should be set to fix the situation where chip reset
is asynchronous to clock of analog shift registers, such that when
reset is released, it could mess up the values of analog shift registers
and cause some hw issue on AR9280.
This bit is write only, but the driver does a read-modify-write
on AR_WA without setting bit 22 in ar9002_hw_configpcipowersave()
during radio disable. This causes surprise removal of hw. It can
never recover from this state and the hw will become usable only
after a power on/off cycle, and sometimes only during a cold reboot.
This issue can be triggered by doing frequent roaming with the
simple/test-roam script available from the wifi-test project [1]
when roaming between APs quickly. When roaming there is a is a high
possibility that the device being put into idle (radio disable) state
by mac80211 during AUTH->ASSOC. A device hardware reset would fail
and the kernel would output:
[40251.363799] ath: AWAKE -> FULL-SLEEP
[40251.363815] ieee80211 phy17: device no longer idle - working
[40251.363817] ath: Marking phy17 as not-idle
[40251.363819] ath: FULL-SLEEP -> AWAKE
[40251.415978] pciehp 0000:00:1c.3:pcie04: Card not present on Slot(3)
[40251.419896] ath: ah->misc_mode 0x4
[40251.428138] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3)
[40251.532247] ath: timeout (100000 us) on reg 0x9860: 0xffffffff & 0x00000001 != 0x00000000
[40251.532250] ath: Unable to reset channel (2462 MHz), reset status -5
[40251.532422] ath: Set channel: 5745 MHz
[40251.540639] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.548826] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.557023] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.565211] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.573415] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.581603] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.581606] ath: Failed to stop TX DMA. Resetting hardware!
[40251.592679] ath: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff
[40251.703330] ath: timeout (100000 us) on reg 0x7000: 0xffffffff & 0x00000003 != 0x00000000
[40251.703333] ath: RTC stuck in MAC reset
[40251.703334] ath: Chip reset failed
[40251.703335] ath: Unable to reset hardware; reset status -22
This is currently only reproducible with some HB92 (Half Mini-PCIE)
cards but the fix applies to all AR9280 cards. This patch fixes this
issue by setting bit 22 during radio disable.
This patch has fixes for all kernels that has ath9k.
[1] http://wireless.kernel.org/en/developers/Testing/wifi-test
Cc: kyungwan.nam@atheros.com
Cc: amod.bodas@atheros.com
Cc: david.quan@atheros.com
Cc: stable@kernel.org
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
After the last rounds of cleanup, these functions are now functionally
equivalent and can thus be merged.
Also get rid of some excessive (and redundant) debug messages.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Throughout the code, DISABLE_REGWRITE_BUFFER is always called right after
REGWRITE_BUFFER_FLUSH. Since that's unlikely to change any time soon, that
makes keeping those ops separate rather pointless, as it only increases
code size and line number counts.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since AR9280 v1.0 was never sold (and the initvals removed), v1.0 specific
revision checks can be removed and the 'v2.0 or later' check can be
simplified to a check for AR9280 or later.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For AR9271 chips, if partial reset is done while scanning, the cycpwrThr1
will be set to maximum. This causes the degrade in DL throughput.
So restore the ANI registers to default during the partial reset.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
According to documentation, The following chip revisions were never sold:
- AR9280 v1.0
- AR9285 v1.0
- AR9285 v1.1
- AR9287 v1.0
Removing initvals specific to these chip revisions saves around 30k in
binary size (tested on MIPS).
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds support for ANI for AR9003. The implementation for
ANI for AR9003 is slightly different than the one used for
the older chipset families. It can technically be used for
the older families as well but this is not yet fully tested
so we only enable the new ANI for the AR5008, AR9001 and AR9002
families with a module parameter, force_new_ani.
The old ANI implementation is left intact.
Details of the new ANI implemention:
* ANI adjustment logic is now table driven so that each ANI level
setting is parameterized. This makes adjustments much more
deterministic than the old procedure based logic and allows
adjustments to be made incrementally to several parameters per
level.
* ANI register settings are now relative to INI values; so ANI
param zero level == INI value. Appropriate floor and ceiling
values are obeyed when adjustments are combined with INI values.
* ANI processing is done once per second rather that every 100ms.
The poll interval is now a set upon hardware initialization and
can be picked up by the core driver.
* OFDM error and CCK error processing are made in a round robin
fashion rather than allowing all OFDM adjustments to be made
before CCK adjustments.
* ANI adjusts MRC CCK off in the presence of high CCK errors
* When adjusting spur immunity (SI) and OFDM weak signal detection,
ANI now sets register values for the extension channel too
* When adjusting FIR step (ST), ANI now sets register for FIR step
low too
* FIR step adjustments now allow for an extra level of immunity for
extremely noisy environments
* The old Noise immunity setting (NI), which changes coarse low, size
desired, etc have been removed. Changing these settings could affect
up RIFS RX as well.
* CCK weak signal adjustment is no longer used
* ANI no longer enables phy error interrupts; in all cases phy hw
counting registers are used instead
* The phy error count (overflow) interrupts are also no longer used
for ANI adjustments. All ANI adjustments are made via the polling
routine and no adjustments are possible in the ISR context anymore
* A history settings buffer is now correctly used for each channel;
channel settings are initialized with the defaults but later
changes are restored when returning back to that channel
* When scanning, ANI is disabled settings are returned to (INI) defaults.
* OFDM phy error thresholds are now 400 & 1000 (errors/second units) for
low/high water marks, providing increased stability/hysteresis when
changing levels.
* Similarly CCK phy error thresholds are now 300 & 600 (errors/second)
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The AR9003 hardware family will use a slightly modified ANI
implementation which has not yet been tested on the other hardware
families. To allow for this new ANI implementation a few ANI
calls need to be abstracted away. This patch just allows for
each hardware family to declare their own ANI ops and annotates
the current ANI implementation as old.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Async fifo is now enabled only for versions 1.3 and above.
Enable it in the appropriate place, in the reset routine,
instead of process_ini().
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch updates the PCI power save handling
code, fixing ASPM hangs and handling device state D3
properly.
The WAR register is programmed with the correct
values now.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a code segment in configpciepowersave()
to make use of multiple register writes.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds macros at certain places
which could be optimized for multiple register writes.
The performance of ath9k_htc improves considerably,
especially reducing the latency involved in a scan run.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The AR9002 hardware code enables aggregation for WEP but
mac80211 doesn't enable aggregation with WEP, and the AR9003
code family does not need this so skip it for now for AR9003
but leave the code and annotate we should eventually consider
how to remove this in consideration for the HAL unification
goals.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The asynch fifo code is specific to >= AR9287 so stuff it
into the AR9002 hardware family code and skip it for AR9003
cards.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The AR9003 TX/RX gain is currently initialized with the other
components, so for now AR9003 does not implment this callback,
after hardware bring up we can test moving the TX/RX gain there
as well and if it works well move them to its own callback as
well.
Since all INI stuff is now moved out hw.c no longer needs to
include and touch any original INI headers/structs.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is specific to the AR9002 family only.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move out the generic hardware family code out into their own
files, we have one for AR5008, AR9001, and AR9002 family (ar9002_hw.c)
and another file for the new AR9003 hardware family (ar9003_hw.c).
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau