the default tx/rx chainmask for AR9462 is 0x3.
this patch helps to assign 0x3 rather than 0x7 for
AR9462 with the help of fix_chainmask module if something
goes wrong in reading tx/rx chain mask from OTP/EEPROM
card(though its very unlikely)
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
only for AR9485 (or) later chipsets TxIQ calibration
runs as part of AGC calibration. without this patch
TX IQ cal completion i.e. ar9003_hw_tx_iq_cal_run won't be executed
for AR9003
Reviewed-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We should free "bus_if" here, it's a small leak but it makes the static
checkers happy.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
here we check for BT state and if BT calibration has started,
give 25ms for BT Calibration to finish. we also take care of 2G/5G
switch and LNA transfer incase WLAN is operating in 5G. in case the BT
state is awake when we do WLAN calibration re-calibrate and we reset
the message exchange between WLAN and BT. BT is given preference when
simultaneous CAL request happens. calibration for WLAN/BT is done
assuming that the other co-existing module is in awake state, if not
we continue to do calibration while if the other module's state changes
we need to do restart the calibration handshake
Cc: Wilson Tsao <wtsao@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
WLAN communicates with BT for its calibration by sending WLAN_CAL_REQ,
waits for BT_CAL_GRANT. This is done with the help of GPM messages.
also WLAN_CAL_DONE messages is sent once WLAN calibration is done.
Cc: Wilson Tsao <wtsao@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
send halt BT GPM if the chip is in network sleep and BT state
is awake
Cc: Wilson Tsao <wtsao@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
required buffers and dma allocation is done for GPM and SCHED
messages
Cc: Wilson Tsao <wtsao@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
check for the condition of MCI interrupt being triggered and
appropriately obtain the values of MCI_INTERRUPT_RX_MSG_RAW and
MCI_INTERRUPT_RAW
Cc: Wilson Tsao <wtsao@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
MCI interrupt is an asynchronous one, so take care of it by having a
check in ath9k_hw_intrpend, which actually decides whether the interrupt
is really for the driver from ath_isr
Cc: Wilson Tsao <wtsao@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
enable MCI interrupt when ath9k_hw_enable_interrupts is called,
like during the completion of chip_reset before which the interrupts
are disabled
Cc: Wilson Tsao <wtsao@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
these parameter will be utilized and modified in the MCI hardware codes
state machine
Cc: Wilson Tsao <wtsao@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
these definitions will be used by MCI state machine and the corresponding
hardware code
Cc: Wilson Tsao <wtsao@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As of hostap_0_7_1~358 the CONFIG_DRIVER_PRISM54
was removed from upstream wpa_supplicant/hostapd so
lets just kill the useless old prism54 private ioctl
crap.
Cc: Jouni Malinen <j@w1.fi>
Cc: David Miller <davem@davemloft.net>
Reported-by: David Miller <davem@davemloft.net>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
change the AR_DEF_ANTENNA register settings i.e setting default antenna
setting only for antenna diversity enabled chipsets. no point in
doing this for MIMO chipsets
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
GPIO pin 4 is assigned AR9462 chipsets LED.
while GPIO pin 0 worked for obselete AR9462 chipsets though
they are meant for EEPROM as per Russell
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Russell Hu <rhu@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mBm is passed but dBm was assumed...
Acked-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Both cases are doing the same so treat the switch cases
for both as an "or".
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mBm is passed but dBm was assumed...
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add more data when inconsistencies occur in the AGG state machine.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Not sure it is the best way to do it, but many times we want to know what the
configuration options were enabled for the compiled driver.
Let's just log the options during load time; so there were be no confusion.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since the uCode hasn't been released (yet?),
warn only if using older than API 4, but load
anything up to API 6.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This makes handling the calibration data more generic
and no longer requires updating IWL_CALIB_MAX when a
new uCode comes with more calibration packets. Since
we just copy the data back, there's also no need for
understanding which calibration we received -- we can
just reflect it back to the runtime uCode.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The init microcode knows very well which calibrations
are required and sends us results for those that are.
Consequently, we can just send all of those to the RT
uCode again.
The problem with having the driver know about this is
that it is a uCode feature, not a hardware feature so
the config is completely unsuitable.
The only thing we need to check is whether the device
needs crystal calibration or not, add a new parameter
to the configuration for that.
This makes new uCode work on 6000 series devices.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Create new testmode commands to suppot indirect access
of peripheral register.
- IWL_TM_CMD_APP2DEV_INDIRECT_REG_READ32
- IWL_TM_CMD_APP2DEV_INDIRECT_REG_WRITE32
Meanwhile, add affix "DIRECT" into original register access
commands for better discrimination with new commands.
- IWL_TM_CMD_APP2DEV_DIRECT_REG_READ32
- IWL_TM_CMD_APP2DEV_DIRECT_REG_WRITE32
- IWL_TM_CMD_APP2DEV_DIRECT_REG_WRITE8
Signed-off-by: Kenny Hsu <kenny.hsu@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Optimize ath5k_cw_validate by using the classic (X & (X - 1)) == 0
check to see if a number is power of 2.
v2: Use functions from log2.h instead
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
According to documentation higher DCUs have higher priority and should
be used for beacons and CAB traffic. More specifically DCU 9 should be
used for beacons and DCU 8 for CAB traffic, I assumed DCU 7 should be
OK for UAPSD traffic.
Note that DCU 8 and 9 are special because they can only be mapped to a single
QCU each but since we use a 1:1 mapping between QCUs and DCUs anyway we don't
have to change much.
P.S. I also did a few related cleanups on qcu.c and ath5k.h
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
MRR support and 2GHz radio override belong in ah_capabilities and we
should use them (e.g. so far we used to set mrr descriptor without
checking if MRR support is enabled + we checked for MRR support 2
times, one by trying to set up an MRR descriptor and another one based
on MAC version).
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add a module parameter to disable hw rf kill switch (GPIO interrupt) because
in some cases when the card doesn't come with the laptop, EEPROM configuration
doesn't match laptop's configuration and rf kill interrupt always fires up and
disables hw. I thought of moving this to debugfs and make it per-card but
this way it's easier for users and distros to handle.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Tested-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There is no short calibration on AR5210, make sure we treat it always
as full calibration.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
No functional changes
Add kernel doc for all ath5k_hw_* functions and strcucts. Also do some cleanup,
rename ath5k_hw_init_beacon to ath5k_hw_init_beacon_timers, remove an unused
variable from ath5k_hw_pcu_init and a few obsolete macros, mostly related to XR.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use usleep_range where possible to reduce busy waits
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Noise floor calibration does not interfere with traffic and should run more
often as part of our "short calibration". The full calibration is not the
noise floor calibration but the AGC + Gain_F (on RF5111 and RF5112) calibration
and should run less often because it does interfere with traffic.
So
Short calibration -> I/Q & NF Calibration
Long calibration -> Short + AGC + Gain_F
This patch was for some time on my pub/ dir on www.kernel.org and has been tested
by a few people and me. I think it's O.K. to go in.
I also changed ah_calibration to ah_iq_cal_needed to make more sense.
v2 Use a workqueue instead of a tasklet for calibration
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
No functional changes, just a few comments/documentation/cleanup
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add TXNOFRM to INT_TX_ALL since it's a TX interrupt too.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since card has 12 tx queues and we want to keep track of the interrupts
per queue we can't fit all these interrupt bits on a single register.
So we have 5 registers, the primary interrupt status register (PISR) and
the 4 secondary interupt status registers (SISRs).
In order to be able to read them all at once (atomic operation) Atheros
introduced the Read-And-Clear registers to make things easier. So when
reading RAC_PISR register, hw does a read on PISR and all SISRs, returns
the value of PISR, copies all SISR values to their shadow copies (RAC_SISRx)
and clears PISR and SISRs. This saves us from reading PISR/SISRs in a sequence.
So far we 've used this approach and MadWiFi/Windows driver etc also used it
for years.
It turns out this operation is not atomic after all (at least not on all cards)
That means it's possible to loose some interrupts because they came after the
copy step and hw cleared them on the clean step !
That's probably the reason we got missed beacons, got stuck queues etc and
couldn't figure out what was going on.
With this patch we switch from RaC operation to an alternative method (that
makes more sense IMHO anyway, I just chose to be on the safe side so far).
Instead of reading RAC registers, we read the normal PISR/SISR registers and
clear any bits we got by writing them back on the register. This will clear only
the bits we got on our read step and leave any new bits unaffected (at least
that's what docs say). So if any new interrupts come up we won't miss it.
I've tested this with an AR5213 and an AR2425 and it seems O.K.
Many thanks to Adrian Chadd for debuging this and reviewing the patch !
v2: Make sure we don't clear PISR bits that map to SISR generated interrupts
(added a comment on the code for this)
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In ancient times it was necessary to manually initialize the bus field of an
spi_driver to spi_bus_type. These days this is done in spi_driver_register(),
so we can drop the manual assignment.
The patch was generated using the following coccinelle semantic patch:
// <smpl>
@@
identifier _driver;
@@
struct spi_driver _driver = {
.driver = {
- .bus = &spi_bus_type,
},
};
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Dan Williams <dcbw@redhat.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Luciano Coelho <coelho@ti.com>
Cc: libertas-dev@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Acked-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Previously BlockAcks were always dropped by the rt2800 hardware while
BlockAckReqs were always accepted. However, both are only useful on
monitor interfaces at the moment and both are control frames. So
pass them up when mac80211 sets FIF_CONTROL.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The recent discussion regarding an incorrect return of IRQ_HANDLED
from rt2800pci caused me to look at this PCI interrupt routine. I
discovered that changes were needed.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Mohammed Shafi Shajakhan