Messages in this thread | | | Date | Thu, 2 Jul 2015 11:21:17 -0400 (EDT) | From | Alan Stern <> | Subject | Re: [PATCH v3 2/2] PM / Runtime: Add pm_runtime_enable_recursive |
| |
On Thu, 2 Jul 2015, Tomeu Vizoso wrote:
> > Just because these sub-devices are virtual, it doesn't mean you can > > ignore the way they interact with runtime PM. > > Fair enough, but then, how are we expected to be able to use the > direct_complete facility if the core bails out if a descendant doesn't > have runtime PM enabled? > > > In the case of ep_87 this doesn't matter. Endpoint devices (like all > > devices) are in the SUSPENDED state by default when they are created, > > and they never leave that state. > > I don't see why it doesn't matter for endpoints or the others. They > don't have runtime PM enabled, so no ancestor will be able to do > direct_complete.
Ah, you're concerned about these lines near the start of __device_suspend():
if (dev->power.direct_complete) { if (pm_runtime_status_suspended(dev)) { pm_runtime_disable(dev); if (pm_runtime_suspended_if_enabled(dev)) goto Complete;
pm_runtime_enable(dev); } dev->power.direct_complete = false; }
Perhaps the pm_runtime_suspended_if_enabled() test should be changed to pm_runtime_status_suspended(). Then it won't matter whether the descendant devices are enabled for runtime PM.
> > A possible way around the problem is to use pm_suspend_ignore_children > > on the uvcvideo interface. But I'm not sure that would be the right > > thing to do. > > Would that mean that if a device has ignore_children then it could > still do direct_complete even if its descendants weren't able to?
I think we could justify that. The ignore_children flag means we can communicate with the children even when the device is in runtime suspend, so there's no reason to force the device to leave runtime suspend during a system sleep.
Alan Stern
| |