[ath9k-devel] Interrupt issue on ARM with SMP

[Lamar Hansford <Lamar.Hansford@maxpoint.com>]

Thanks for the explanation.

What I current have in my code is that I when I receive the first interrupt with ASYNC_CAUSE=2, I disable interrupts (IER=0).

After I do this I see 2-3 more interrupts with ASYNC_CAUSE=0.

Would this be the Atheros chipset generating the interrupts or spurious interrupts caused by the SoC?

My thought in  addressing this would be to disable the IRQ when I receive an interrupt with cause, with a timer to re-enable the interrupt at a period which allows the spurious condition to settle.   Of course, in order to play nice with shared (legacy) interrupts I need to implement MSI interrupt schema or else I would disable interrupts for all shared handlers.

A Quick note....
The prolific use of spinlock_irqsave and spinlock_bh is bad,  Very bad.   This disables interrupts for the entire system and not merely the Atheros driver.  This will cause adverse system impacts such as deadlocks and latency issues.

On the ARM platform we can run only for a few seconds (under traffic) before we deadlock the entire system (hard lock with no panic).   Under SMP we get an almost immediate hard lock up (no panic).   I have ripped all of the IRQ disables ripped out in order to get the system running to the point I can debug the interrupt handling.

Generally speaking you never want to use spinlocks on long running tasks.  However, I see spinlocks being used in place of mutex (which allow thread sleep) for potentially long running tasks such DMA and flush actions.

Is there any reason why these would be implemented not only using spinlock, but with a spinlock which disables IRQ?   Is there any reason any a mutex would not be better in these cases?

Thanks for your help here!
-Lamar


-----Original Message-----
From: adrian.chadd@gmail.com [mailto:adrian.chadd at gmail.com] On Behalf Of Adrian Chadd
Sent: Thursday, August 25, 2016 8:34 PM
To: Lamar Hansford
Cc: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] Interrupt issue on ARM with SMP

On 25 August 2016 at 11:15, Lamar Hansford <Lamar.Hansford@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.
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.