On 25 August 2016 at 11:15, Lamar Hansford <lamar.hansf...@maxpoint.com> 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. _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
