On Mon, 22 Jun 2009 16:27:29 +0900Magnus 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 happenas well from the device itself. -- Arjan van de Ven Intel Open Source Technology CentreFor development, discussion and tips for power savings, visit http://www.lesswatts.org_______________________________________________linux-pm mailing listlinux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.linux-foundation.org/mailman/listinfo/linux-pm
