* Rafael J. Wysocki [161123 14:37]:
> On Fri, Nov 18, 2016 at 9:18 PM, Tony Lindgren wrote:
> > Hi,
> >
> > * Rafael J. Wysocki [16 16:35]:
> >> However, my understanding is that the current code actually works for
> >> runtime PM just fine.
> >
> > Hmm well I just noticed that for drivers n
On Fri, Nov 18, 2016 at 9:18 PM, Tony Lindgren wrote:
> Hi,
>
> * Rafael J. Wysocki [16 16:35]:
>> However, my understanding is that the current code actually works for
>> runtime PM just fine.
>
> Hmm well I just noticed that for drivers not using autosuspend it can be
> flakey, see the patc
Hi,
* Rafael J. Wysocki [16 16:35]:
> However, my understanding is that the current code actually works for
> runtime PM just fine.
Hmm well I just noticed that for drivers not using autosuspend it can be
flakey, see the patch below. That probably explains some mysteries people
are seeing wi
On Sat, Nov 12, 2016 at 1:19 AM, Tony Lindgren wrote:
> * Rafael J. Wysocki [16 15:35]:
>> On Fri, Nov 11, 2016 at 11:32 PM, Tony Lindgren wrote:
>> > * Tony Lindgren [16 14:29]:
>> >> * Rafael J. Wysocki [16 13:33]:
>> >> > On Fri, Nov 11, 2016 at 5:31 PM, Tony Lindgren wrote:
>>
* Rafael J. Wysocki [16 15:35]:
> On Fri, Nov 11, 2016 at 11:32 PM, Tony Lindgren wrote:
> > * Tony Lindgren [16 14:29]:
> >> * Rafael J. Wysocki [16 13:33]:
> >> > On Fri, Nov 11, 2016 at 5:31 PM, Tony Lindgren wrote:
> >> > > * Rafael J. Wysocki [161110 16:06]:
> >> > >> On Thu,
On Fri, Nov 11, 2016 at 11:32 PM, Tony Lindgren wrote:
> * Tony Lindgren [16 14:29]:
>> * Rafael J. Wysocki [16 13:33]:
>> > On Fri, Nov 11, 2016 at 5:31 PM, Tony Lindgren wrote:
>> > > * Rafael J. Wysocki [161110 16:06]:
>> > >> On Thu, Nov 10, 2016 at 7:49 PM, Brian Norris
>> > >>
* Tony Lindgren [16 14:29]:
> * Rafael J. Wysocki [16 13:33]:
> > On Fri, Nov 11, 2016 at 5:31 PM, Tony Lindgren wrote:
> > > * Rafael J. Wysocki [161110 16:06]:
> > >> On Thu, Nov 10, 2016 at 7:49 PM, Brian Norris
> > >> wrote:
> > >> > On Thu, Nov 10, 2016 at 10:13:55AM -0800, Dmitr
* Rafael J. Wysocki [16 13:33]:
> On Fri, Nov 11, 2016 at 5:31 PM, Tony Lindgren wrote:
> > * Rafael J. Wysocki [161110 16:06]:
> >> On Thu, Nov 10, 2016 at 7:49 PM, Brian Norris
> >> wrote:
> >> > On Thu, Nov 10, 2016 at 10:13:55AM -0800, Dmitry Torokhov wrote:
> >> >> On Thu, Nov 10, 201
On Fri, Nov 11, 2016 at 8:40 PM, Brian Norris wrote:
> On Fri, Nov 11, 2016 at 08:47:54AM -0800, Tony Lindgren wrote:
>> But sounds like the threaded IRQ is not your concern and you mostly
>
> Right, threaded is OK for this; it's not performance critical. It just
> highlighted the fact that its co
On Fri, Nov 11, 2016 at 5:31 PM, Tony Lindgren wrote:
> * Rafael J. Wysocki [161110 16:06]:
>> On Thu, Nov 10, 2016 at 7:49 PM, Brian Norris
>> wrote:
>> > On Thu, Nov 10, 2016 at 10:13:55AM -0800, Dmitry Torokhov wrote:
>> >> On Thu, Nov 10, 2016 at 10:07 AM, Brian Norris
>> >> wrote:
>> >>
On Fri, 11 Nov 2016, Brian Norris wrote:
> > The wakeup interrupt controller knows something happened earlier,
> > so maybe it could report that time if queried somehow?
>
> Sort of. We have /sys/power/pm_wakeup_irq already. But it's really less
> useful to get IRQ-level stats for this, than to g
* Brian Norris [16 11:40]:
>
> BTW, for context, I'm working on using dev_pm_set_dedicated_wake_irq()
> for a Wifi driver which supports out-of-band (e.g., GPIO-based) wakeup.
> I see it's used in the I2C core, but the I2C code never actually calls
> dev_pm_enable_wake_irq(). So while I think
On Fri, Nov 11, 2016 at 08:47:54AM -0800, Tony Lindgren wrote:
> But sounds like the threaded IRQ is not your concern and you mostly
Right, threaded is OK for this; it's not performance critical. It just
highlighted the fact that its completion is not synchronized with
anything.
> care about gett
* Brian Norris [161110 13:30]:
> On Thu, Nov 10, 2016 at 01:49:11PM -0700, Tony Lindgren wrote:
> > * Brian Norris [161110 11:49]:
> > > On Thu, Nov 10, 2016 at 10:13:55AM -0800, Dmitry Torokhov wrote:
> > > > On Thu, Nov 10, 2016 at 10:07 AM, Brian Norris
> > > > wrote:
> > > > > It's importan
* Rafael J. Wysocki [161110 16:06]:
> On Thu, Nov 10, 2016 at 7:49 PM, Brian Norris
> wrote:
> > On Thu, Nov 10, 2016 at 10:13:55AM -0800, Dmitry Torokhov wrote:
> >> On Thu, Nov 10, 2016 at 10:07 AM, Brian Norris
> >> wrote:
> >> > It's important that user space can figure out what device wok
On Thu, Nov 10, 2016 at 7:49 PM, Brian Norris wrote:
> On Thu, Nov 10, 2016 at 10:13:55AM -0800, Dmitry Torokhov wrote:
>> On Thu, Nov 10, 2016 at 10:07 AM, Brian Norris
>> wrote:
>> > It's important that user space can figure out what device woke the
>> > system from suspend -- e.g., for debugg
On Thu, Nov 10, 2016 at 09:57:20PM +0100, Pavel Machek wrote:
> On Thu 2016-11-10 10:07:07, Brian Norris wrote:
> > It's important that user space can figure out what device woke the
> > system from suspend -- e.g., for debugging, or for implementing
> > conditional wake behavior. Dedicated wakeup
On Thu, Nov 10, 2016 at 01:49:11PM -0700, Tony Lindgren wrote:
> * Brian Norris [161110 11:49]:
> > On Thu, Nov 10, 2016 at 10:13:55AM -0800, Dmitry Torokhov wrote:
> > > On Thu, Nov 10, 2016 at 10:07 AM, Brian Norris
> > > wrote:
> > > > It's important that user space can figure out what device
On Thu 2016-11-10 10:07:07, Brian Norris wrote:
> It's important that user space can figure out what device woke the
> system from suspend -- e.g., for debugging, or for implementing
> conditional wake behavior. Dedicated wakeup IRQs don't currently do
> that.
>
> Let's report the event (pm_wakeup
* Brian Norris [161110 11:49]:
> On Thu, Nov 10, 2016 at 10:13:55AM -0800, Dmitry Torokhov wrote:
> > On Thu, Nov 10, 2016 at 10:07 AM, Brian Norris
> > wrote:
> > > It's important that user space can figure out what device woke the
> > > system from suspend -- e.g., for debugging, or for implem
On Thu, Nov 10, 2016 at 10:13:55AM -0800, Dmitry Torokhov wrote:
> On Thu, Nov 10, 2016 at 10:07 AM, Brian Norris
> wrote:
> > It's important that user space can figure out what device woke the
> > system from suspend -- e.g., for debugging, or for implementing
> > conditional wake behavior. Dedi
On Thu, Nov 10, 2016 at 10:07 AM, Brian Norris wrote:
> It's important that user space can figure out what device woke the
> system from suspend -- e.g., for debugging, or for implementing
> conditional wake behavior. Dedicated wakeup IRQs don't currently do
> that.
>
> Let's report the event (pm_
It's important that user space can figure out what device woke the
system from suspend -- e.g., for debugging, or for implementing
conditional wake behavior. Dedicated wakeup IRQs don't currently do
that.
Let's report the event (pm_wakeup_event()) and also allow drivers to
synchronize with these e
23 matches
Mail list logo