Re: [patch update 3] PM: Introduce core framework for run-time PMof I/O devices

[Alan Stern]

On Wed, 24 Jun 2009, Rafael J. Wysocki wrote:

> > One question still remains: If the counter is 0 at the end of a
> > successful pm_runtime_resume, should the core then call pm_notify_idle?  
> > Or should we make the driver responsible for that too?
> 
> Good question. :-)
> 
> I think the core may call pm_notify_idle() in that case, but not necessarily in
> the synchronous case.

I'm not sure; we may want to do it even for synchronous resumes.  
Otherwise the callers would be forced to do it.

There's also the other side of the coin.  What if the counter is 0 at
the end of a failed pm_runtime_suspend?

For example, suppose the driver's runtime_suspend method decides that
the device hasn't been idle for long enough, so it wants to fail the
suspend attempt with -EBUSY and queue a new delayed autosuspend
request.  But at this point the status is RPM_SUSPENDING, so new
suspend requests won't be accepted (N.B., the test for this in the most
recent patch doesn't look right).

Even with a queued notification, there's no guarantee that the
notification won't be sent before the status changes from
RPM_SUSPENDING to RPM_ACTIVE.  So we really do need the notification to
be sent by pm_runtime_suspend, after it has updated the status and
dropped the lock.


There's another totally separate issue worth discussing here.  This 
will affect the USB implementation of the new runtime PM framework.

The difficulty is that some USB interface drivers require remote wakeup
to be enabled while their interfaces are suspended.  But remote wakeup
is a global setting; it doesn't take effect until the entire physical
device is suspended.  (To put it another way, USB has no notion of
suspending interfaces.)  This means we must not allow these interfaces
to be suspended before the whole device is.  But the whole device is
the parent of the interfaces -- if we can't suspend the children before
suspending the parent then we're stuck.

Clearly this is something the USB stack has to deal with; it shouldn't
affect the general PM framework.  However the only solution I can think
of involves subverting the framework, which isn't very nice.  The idea
is to ignore runtime_suspend callbacks for these interface drivers;
allow them to keep on running even though the PM core thinks they are
suspended.  Then suspend and resume them as part of the callbacks for
the entire device.  (For interface drivers that don't require remote
wakeup there is no problem; it doesn't matter when they get suspended.)

This will work, but it's a hack.  Does anybody have a better idea?

Alan Stern

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