aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ath/ath5k/base.c
diff options
context:
space:
mode:
authorNick Kossifidis <mickflemm@gmail.com>2011-11-25 20:40:20 +0200
committerJohn W. Linville <linville@tuxdriver.com>2011-11-28 14:44:10 -0500
commit7ff7c82ee4339af277cface9071f81c5c10a9283 (patch)
treee8daee17b99f7756cc937b7eafc09128597fc02d /drivers/net/wireless/ath/ath5k/base.c
parent61c0d48f1565efdbab1e913c3cfda997e6299c41 (diff)
ath5k: Switch from read-and-clear to write-to-clear method when handling PISR/SISR registers
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>
Diffstat (limited to 'drivers/net/wireless/ath/ath5k/base.c')
-rw-r--r--drivers/net/wireless/ath/ath5k/base.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index b346d049200..c18d3100897 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1689,7 +1689,7 @@ ath5k_tasklet_tx(unsigned long data)
struct ath5k_hw *ah = (void *)data;
for (i = 0; i < AR5K_NUM_TX_QUEUES; i++)
- if (ah->txqs[i].setup && (ah->ah_txq_isr & BIT(i)))
+ if (ah->txqs[i].setup && (ah->ah_txq_isr_txok_all & BIT(i)))
ath5k_tx_processq(ah, &ah->txqs[i]);
ah->tx_pending = false;