Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 1 Oct 2010, Rafael J. Wysocki wrote:

> > >  If RPM_IRQ is not set, but
> > > power.callbacks_in_irq is set, we should fall back to the normal behavior
> > > (ie. do not avoid sleeping).
> > 
> > By "do not avoid sleeping", do you mean that 
> > 
> > 	(1) the helper functions should be allowed to sleep, or
> > 
> > 	(2) the callbacks should be invoked with interrupts enabled?
> > 
> > The patch already does (1).  By contrast, (2) isn't safe.  It means
> > there is a risk of having one thread do a busy-wait with interrupts
> > disabled, waiting for another thread that can sleep.
> 
> In my opinion the _irq operations should really be one-shot, without
> any looping, waking up parents etc.  I mean, if the parent is not RPM_ACTIVE,
> the _irq resume should immediately fail and analogously for the _irq
> suspend.  And so on.  As simple as reasonably possible.

But what if the device's own status is currently SUSPENDING or
RESUMING?  Do you want to fail when that happens, instead of waiting
for the concurrent operation to finish?  There's no way to prevent this
on SMP systems, because a wakeup request can arrive while a
software-initiated resume is in progress.

> > Going further, I'm still a little dubious about the whole point of
> > having idle notifications at all.  I don't see why the PM core can't
> > notify a subsystem that a device is idle just by calling the
> > runtime_suspend routine.
> 
> Well, calling _idle is like saying "I think this device may be idle, please
> consider suspending it", while calling _suspend is like saying "suspend
> this device unless you can't".  I think that's enough of a difference to
> have separate _idle.

> A subsystem or a driver may want to schedule the suspend with a timeout
> if _idle is called instead of just suspending synchronously.  The r8169 driver
> actually does something similar (although a bit more complicated).

What you are describing is basically what autosuspend was intended to
accomplish (that is, formalizing the difference between "the device
just became idle, you should consider when to suspend it" and "the
device has been idle for a sufficiently long time, please suspend it
now").  Would the r8169 driver be simplified if it used autosuspend?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux