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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
