Re: ath9k: irq storm after suspend/resume

[Clemens Buchacher <drizzd@aon.at>]

On Wed, Oct 05, 2011 at 05:11:00AM +0800, Adrian Chadd wrote:
> 
> Well, the question now is whether the device itself is actually firing
> off interrupts.
> 
> From what you've shown there, the device _isn't_ firing off interrupts
> the normal way.
> So I wonder if it's the card or whether it's something else (eg the
> PCI bus glue.)
> 
> Here, you could try inserting this in the SC_OP_INVALID bit, right
> after you do some logging. I'm still assuming your AR9285 is somehow
> firing off interrupts.
> At this point however I'm all just guessing here. It'd be nice to know
> whether the device is _really_ sending interrupts or not.

No change with the code below, except that the timing is slightly
different.

> /* Mark _all_ async interrupts as serviced */
> REG_WRITE(ah, AR_INTR_ASYNC_CAUSE, 0xffffffff);
> REG_READ(ah, AR_INTR_ASYNC_CAUSE);
> 
> /* Disable sync interrupt sources */
> REG_WRITE(ah, AR_INTR_SYNC_ENABLE, 0);
> /* Mark _all_ sync interrupts as serviced */
> REG_WRITE(ah, AR_INTR_SYNC_CAUSE, 0xffffffff);
> REG_READ(ah, AR_INTR_SYNC_CAUSE);
> 
> /* Do a reset of the AHB and host interface */
> REG_WRITE(ah, AR_RC, AR_RC_AHB | AR_RC_HOSTIF);
> DELAY(100);

Since I could not find a suitable DELAY macro, I used this instead:

 int delay = 100;
 DO_DELAY(delay);

> REG_WRITE(ah, AR_RC, 0);

For the record, instead of going to full sleep, I can reproduce the
issue with

 echo devices >/sys/power/pm_test
 echo mem >/sys/power/state

but not with

 echo freezer >/sys/power/pm_test
 echo mem >/sys/power/state

So it could still be a different device that's causing the issue? I
can try unloading all kinds of modules. Or is there an option to
suspend just one device?

Clemens