From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrian Chadd Date: Thu, 25 Aug 2016 18:33:32 -0700 Subject: [ath9k-devel] Interrupt issue on ARM with SMP In-Reply-To: References: Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On 25 August 2016 at 11:15, Lamar Hansford 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.