According to tests, both TSF lower and upper registers kept counting, so
the higher part could have been updated after the lower part has been
read, as shown in the following log where the upper part is read first
and the lower part next.
This patch corrects this by checking that the upper part has not been
changed while the lower part was read. It has been tested in an IBSS
network where artifical IBSS merges have been done in order to trigger
hundreds of rollover for the TSF lower part.
It follows the logic mentionned by Derek, with only 2 register reads
needed at each additional steps instead of 3 (the minimum number of
register reads is still 3).
Signed-off-by: Benoit Papillault <benoit.papillault@free.fr> Signed-off-by: John W. Linville <linville@tuxdriver.com>
LDPC is enabled by the rate control if the its determined
that the target peer supports LDPC. We would have already
intersected the HT capabilities so if our peer supports
LDPC so do we.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: Compute pointer checksum over the link descriptor
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: skip WEP aggregation enable code for AR9003
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>
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Once upon a time the AR_EEPROM_MAC macro was added to let us
add a random attribute to the three 4-bytes of MAC addresses
entries we read from the EEPROM. This was good while a random
high-enough value was used which did not conflict with any
of the already existing enum eeprom_param values. With AR9003
support the enums overlap and it means we either increment
the random offset or just restore the reading logic to match
what the HAL has. I choose to do the later to synchronize
the logic on both code bases.
This should fix reading the MAC address from the EEPROM
on AR9003 hardware.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
This goes with some new shiny TX IQ calibration that AR9003
hardware family supports.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is the last call on calib.c which acceses PHY stuff,
with this change we calib.c is now generic between both
all supported hardware families.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: Abstract the routine which returns interrupt status
Also move interrupt related code to mac.c
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: move TX/RX gain INI stuff to its own hardware family code
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>
ath9k_hw: split the generic hardware code by hardware family
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>
Calibration code touches phy registers and since these
change the calibration code needs to be abstracted.
Noise floor calibration is the only thing remaining but
since the remaining calls only touch the AR_PHY_AGC_CONTROL
register we'll just define that register conditionally, that
will be done separately. The goal is to remove the dependency
of ar9002_phy.h on calib.c
This also adds stubs to be filled for AR9003 calibration code.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: the eep_map is used only for AR9280 PCI card ini fixup
We can reorganize the code in such a way that eep_map can be removed,
which makes the code more clearer.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau [Thu, 15 Apr 2010 21:38:49 +0000 (17:38 -0400)]
ath9k_hw: Split out the function for reading the noise floor
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau [Thu, 15 Apr 2010 21:38:48 +0000 (17:38 -0400)]
ath9k: Add Rx EDMA support
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k: Remove ATH9K_TX_SW_ABORTED and introduce a bool for this purpose
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: add helpers for processing the AR9003 INI
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
The initvals.h file is over 7000 lines now, so instead of adding
AR9003 initvals to it instead lets split the current initvals.h by
hardware family: AR5008, AR9001, AR9002
The AR9003 family will have its own initval file later.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau [Thu, 15 Apr 2010 21:38:35 +0000 (17:38 -0400)]
ath9k_hw: Implement spur mitigation on AR9003
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau [Thu, 15 Apr 2010 21:38:34 +0000 (17:38 -0400)]
ath9k_hw: Implement PLL control on AR9003
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau [Thu, 15 Apr 2010 21:38:33 +0000 (17:38 -0400)]
ath9k_hw: Set the channel on AR9003
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: prevent reset control register zeroing on AR9003 reset
Also, no need for the udelay(2) on AR9003 hardware.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
The AR9003 family requires a change on the loop and can also skip
testing the PHY timing registers. This chip test can now be used
by all Atheros hardware families, including legacy. We can
eventually move this out to the generic ath module.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Set rx buf size in register 0x60
* Set rxdp on the respective hw rx queue (HP and LP queues)
* Process rx descriptor
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: Add hw cap flag for EDMA for the AR9003 family
AR9003 supports extended DMA (EDMA), this comes with some
bells and whistles on top of the legacy DMA that we are used
to. Mark AR9003 and later chips EDMA capable.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ANI is still being debugged on AR9003 by our systems team
so it should not yet be enabled yet. When ANI will be
enabled all ANI functionality is expected to be enabled
so fill the ANI functionality to all for AR9003 for now
as well.
Cc: Enis Akay <Enis.Akay@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: move init config and default after chip is up
This allows us to add SREV checks on these helpers.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
This add stubs for PHY support for the AR9003 hardware family.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: Add the PCI IDs for AR9300 and fill up the pci_id_tables
Also, clean up and reorganize the AR9287 macro to have better
ordering. We won't add the PCI ID to the supported device list
until we have some functional code for it.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: add a private callback for PLL control computation
The PLL control computation used to program the AR_RTC_PLL_CONTROL
register varies between our harware so just add a private callback for it.
AR9003 will use its own callback.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: Move some RF ops to the private callbacks
The PHY split is easier done in a few steps. First move
the RF ops to the private ops and rename them accordingly.
We split PHY stuff up first for the AR5008 and AR9002
families. There are some callbacks that AR9002 share
with the AR5008 familiy so we set those first, if AR9002
has some different callbacks it will override them upon
hardware init.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is used only once by ath9k_hw_process_ini() to
write an array of phy registers through REG_WRITE_ARRAY(),
but we already call REG_WRITE_ARRAY() multiple times
on the same caller so just remove this pointless wrapper.
We'll eventually just move the ath9k_hw_process_ini()
caller as an callback to abstract away between different
hardware families.
Although this change is subtle I should note that this
does change the delay pattern on writing the next series
of registers. REG_WRITE_ARRAY() uses a counter for each
register write and does a udelay(1) every 64 writes. By
removing this call it means that the counter is processed
for all the iniBB_RfGain registers and is incremented
on ath9k_hw_process_ini(), before this the after the call
ath9k_hw_write_regs() was made the register counter was
kept at the same index number prior to the call.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: AR9003 does not have AR_RC_AHB skip its setting
AR9003 does not have a reset control for AHB.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau [Thu, 15 Apr 2010 21:38:07 +0000 (17:38 -0400)]
ath9k_hw: add silicon revision macros for AR9300
AR9300 will be the first device supported of the AR9003
family. AR9300 1.0 hardware exists but it is not going to
be sold anywhere so we completely skip its support.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: start building an abstraction layer for hardware routines
ath9k supports the AR5008, AR9001 and AR9002 family of Atheros
chipsets, all 802.11n. The new breed of 802.11n chips, the
AR9003 family will be supported as well soon. To help with its
support we're going to add a few callbacks for hardware routines
which differ considerably instead of adding branch checks for
the revision at runtime.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Dan Williams [Thu, 15 Apr 2010 20:32:58 +0000 (13:32 -0700)]
libertas: Davinci platforms need more time loading helper firmware
Davinci platforms apparently need more time in-between helper firmware
blocks. Even though this is an increased delay, we only take this hit
once at initialization time.
Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
projects / linux-beck.git / log