[ath9k-devel] Interrupt issue on ARM with SMP

Adrian Chadd <[email protected]> Thu, 25 Aug 2016 18:33:32 -0700
Newsgroups org.ath9k.lists.ath9k-devel
Message-ID <CAJ-VmonFv5LGD7X5SvPD-z7gJ0DFQApGtXW=AgxH5bsD+kWemw@mail.gmail.com>
On 25 August 2016 at 11:15, Lamar Hansford <[email protected]> wrote:
> I am using legacy interrupts in this case.  I found the issue where the interrupts were not firing (stupid issue on my part).  Working on getting the data through the pipe.
>
> I still have a question on the meaning for the ASYNC cause.
>
> After receiving and clearing interrupts (writing the ISR back to itself).   I am masking the bits until they are serviced.  When the interrupts are masked I get an async cause of 0x0 and the interrupts are ignored.
>
> Is the AR_INTR_ASYNC_CAUSE indicating that the interrupt has not changed since the last IMR update?

Right. It's not triggering an interrupt, so ASYNC_CAUSE won't get
triggered. AR_ISR will still show the status, but if it's disabled, it
won't trigger an interrupt at all.

> If so this would be odd behavior (normally an IMR will prevent spurious ISR to relieve loading).

AR_IMR_* is the MAC status control register - it controls which
MAC/PHY events generate interrupts.

SYNC_CAUSE / ASYNC_CAUSE is the whole chip interrupt - it includes
interrupts for hardware errors too, sleep state accesses, etc.

AR_IER controls whether the MAC generates interrupts at all.

So my suggestion is you only enable/disable AR_IER, and you don't try
to enable/disable bits in the AR_IMR register.

SYNC vs ASYNC - the TL;DR is that ASYNC always stays asserted until
you ACK the underlying condition, SYNC gets triggered once until you
ACK the SYNC_CAUSE register bit.

Eg, I do GPIO interrupts on ath9k (haven't integrated / published it
yet.) I use SYNC interrupts otherwise I keep getting the GPIO
interrupts until the GPIO bits are serviced, which can take time. The
underlying event (polarity low or high) can be asserted for quite some
time and I don't want to be spammed with interrupts.


-adrian


>
> Thanks in advance,
> -Lamar
>
>
>
>
>
>
> This email and any attachments may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please immediately delete this email and any attachments.