* Alan Stern [150309 08:42]:
> On Mon, 9 Mar 2015, Tony Lindgren wrote:
>
> > > > > > Considering the above, should we add a new function something like
> > > > > > pm_resume_complete() that does not need irq_safe set but does
> > > > > > not return until the device has completed resume?
> > > >
On Mon, 9 Mar 2015, Tony Lindgren wrote:
> > > > > Considering the above, should we add a new function something like
> > > > > pm_resume_complete() that does not need irq_safe set but does
> > > > > not return until the device has completed resume?
> > > >
> > > > That doesn't make sense. You'r
* Alan Stern [150308 08:41]:
> On Fri, 6 Mar 2015, Tony Lindgren wrote:
>
> > > > I'll verify again, but I believe the issue was that without doing
> > > > mark_last_busy here the device falls back asleep right away.
>
> As it should. If you don't increment the usage counter (for example,
> by
On Sunday, March 08, 2015 11:43:34 AM Alan Stern wrote:
> On Sat, 7 Mar 2015, Rafael J. Wysocki wrote:
>
> > But this is part of a bigger picture. Namely, if a separete wakeup
> > interrupt
> > is required for a device, the device's power.can_wakeup flag cannot be set
> > until that interrupt ha
On Sat, 7 Mar 2015, Rafael J. Wysocki wrote:
> But this is part of a bigger picture. Namely, if a separete wakeup interrupt
> is required for a device, the device's power.can_wakeup flag cannot be set
> until that interrupt has been successfully requested. Also for devices that
> can signal wake
On Fri, 6 Mar 2015, Tony Lindgren wrote:
> > > I'll verify again, but I believe the issue was that without doing
> > > mark_last_busy here the device falls back asleep right away.
As it should. If you don't increment the usage counter (for example,
by calling pm_runtime_get instead of pm_reques
On Sat, 7 Mar 2015, Rafael J. Wysocki wrote:
> > > Well right now it's using threaded irq, and I'd like to get rid of
> > > I'll verify again, but I believe the issue was that without doing
> > > mark_last_busy here the device falls back asleep right away.
> > > That probably should be fixed in pm
* Rafael J. Wysocki [150306 16:19]:
> On Friday, March 06, 2015 03:05:40 PM Tony Lindgren wrote:
> >
> > Oh it naturally would not work in irq context, it's for the bottom
> > half again. But I'll take a look if we can just call
> > pm_request_resume() and disable_irq() on the wakeirq in without
On Friday, March 06, 2015 03:05:40 PM Tony Lindgren wrote:
> * Alan Stern [150306 11:05]:
> > On Fri, 6 Mar 2015, Tony Lindgren wrote:
> >
> > > > > + struct wakeirq_source *wirq = _wirq;
> > > > > + irqreturn_t ret = IRQ_NONE;
> > > > > +
> > > > > + /* We don't want RPM_ASYNC or RPM
* Alan Stern [150306 11:05]:
> On Fri, 6 Mar 2015, Tony Lindgren wrote:
>
> > > > + struct wakeirq_source *wirq = _wirq;
> > > > + irqreturn_t ret = IRQ_NONE;
> > > > +
> > > > + /* We don't want RPM_ASYNC or RPM_NOWAIT here */
> > > > + if (pm_runtime_suspended(wirq->dev)
On Friday, March 06, 2015 02:05:43 PM Alan Stern wrote:
> On Fri, 6 Mar 2015, Tony Lindgren wrote:
>
> > > > + struct wakeirq_source *wirq = _wirq;
> > > > + irqreturn_t ret = IRQ_NONE;
> > > > +
> > > > + /* We don't want RPM_ASYNC or RPM_NOWAIT here */
> > > > + if (pm_ru
On Fri, 6 Mar 2015, Tony Lindgren wrote:
> > > + struct wakeirq_source *wirq = _wirq;
> > > + irqreturn_t ret = IRQ_NONE;
> > > +
> > > + /* We don't want RPM_ASYNC or RPM_NOWAIT here */
> > > + if (pm_runtime_suspended(wirq->dev)) {
> >
> > What if the device is resumed on a different CPU right
Hi,
* Rafael J. Wysocki [150305 17:38]:
> Please always CC linux-pm on CC patches.
Sure will do for the next rev, sorry forgot to add that.
> On Thursday, March 05, 2015 04:34:06 PM Tony Lindgren wrote:
> > +/**
> > + * handle_dedicated_wakeirq - Handler for device wake-up interrupts
> > + * @
On Fri, Mar 6, 2015 at 3:02 AM, Rafael J. Wysocki wrote:
> Please always CC linux-pm on CC patches.
Doh. That was supposed to say "Please always CC linux-pm on PM patches".
I really should not reply to email when I'm too tired ...
--
To unsubscribe from this list: send the line "unsubscribe lin
Please always CC linux-pm on CC patches.
On Thursday, March 05, 2015 04:34:06 PM Tony Lindgren wrote:
> Some devices have separate wake-up interrupts in addition to the
> normal device interrupts. The wake-up interrupts can be connected
> to a separate interrupt controller that is always powered.
Some devices have separate wake-up interrupts in addition to the
normal device interrupts. The wake-up interrupts can be connected
to a separate interrupt controller that is always powered. This
allows the devices and the whole system to enter deeper idle states
while still being able to wake-up to
16 matches
Mail list logo
