• Nick Kossifidis's avatar
    ath5k: Switch from read-and-clear to write-to-clear method when handling PISR/SISR registers · 7ff7c82e
    Nick Kossifidis authored
    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: default avatarNick Kossifidis <mickflemm@gmail.com>
    Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>