On Monday 22 June 2009, Arjan van de Ven wrote: > On Mon, 22 Jun 2009 16:27:29 +0900 > Magnus Damm <magnus.damm@xxxxxxxxx> wrote: > > > On Mon, Jun 22, 2009 at 3:43 PM, Arjan van de > > Ven<arjan@xxxxxxxxxxxxx> wrote: > > > On Mon, 22 Jun 2009 15:20:43 +0900 > > > Magnus Damm <magnus.damm@xxxxxxxxx> wrote: > > > > > >> On Sat, Jun 20, 2009 at 11:30 PM, Alan > > >> Stern<stern@xxxxxxxxxxxxxxxxxxx> wrote: > > >> > Some more thoughts... > > >> > > > >> > Magnus, you might have some insights here. It occurred to me > > >> > that some devices can switch power levels very quickly, and the > > >> > drivers might therefore want the runtime suspend and resume > > >> > methods to be called as soon as possible, even in interrupt > > >> > context. > > >> > > >> I'd like to call pm_request_suspend() from interrupt context. I > > >> don't > > > > > > there are some really strong reasons to at least be able to call the > > > resume function from an interrupt handler.... shared interrupts are > > > one of them. > > > > I suppose you mean that you need to resume the hardware device before > > you can check if it has a pending interrupt source? If so then you > > also mean that suspended hardware devices may generate interrupts, no? > > yes and no. For the shared interrupt case.. no. > but yes for the hw I have in mind (and on my desk ;-) that can happen > as well from the device itself. If that's PCI hardware (I guess it is ;-)), I'm not really sure if this behavior is compliant with the specification. Anyway, if the interrupt is not shared and the device can wake up fast enough, we should be able to handle it. Best, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
