[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200906221733.44629.rjw@sisk.pl>
Date: Mon, 22 Jun 2009 17:33:42 +0200
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Arjan van de Ven <arjan@...radead.org>
Cc: Magnus Damm <magnus.damm@...il.com>,
Alan Stern <stern@...land.harvard.edu>,
Greg KH <gregkh@...e.de>, LKML <linux-kernel@...r.kernel.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
"Linux-pm mailing list" <linux-pm@...ts.linux-foundation.org>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [linux-pm] [patch update 2 fix] PM: Introduce core framework for run-time PM of I/O devices
On Monday 22 June 2009, Arjan van de Ven wrote:
> On Mon, 22 Jun 2009 15:20:43 +0900
> Magnus Damm <magnus.damm@...il.com> wrote:
>
> > On Sat, Jun 20, 2009 at 11:30 PM, Alan
> > Stern<stern@...land.harvard.edu> 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.
Yes. But that requires your hardware to be able to wake up fast enough, so I
think we can introduce pm_runtime_resume_atomic() and
pm_runtime_suspend_atomic() to be used with the devices that can do that, as
proposed by Alan.
Surely not all devices can do it, though.
Best,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists