Re: [PATCH v3 2/2] PM / Runtime: Add pm_runtime_enable_recursive

[Alan Stern]

On Wed, 20 May 2015, Tomeu Vizoso wrote:

> On 19 May 2015 at 19:49, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Tue, 19 May 2015, Tomeu Vizoso wrote:
> >
> >> This function makes less cumbersome to enable runtime PM in a device and
> >> its descendants.
> >>
> >> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@xxxxxxxxxxxxx>
> >
> > I don't see the point of this.  In the scenario you have in mind, are
> > the device and all its descendants registered by the same
> > subsystem/driver?
> 
> Not quite, the scenario here is a driver (uvcvideo) that deals with a
> specific piece of hardware and knows that all the descendants of the
> device it's bound to are virtual.
> 
> The subtree is:
> 
> 1-1:1.0 (bound to uvcvideo)
>         ep_87
>         input4
>                 event4
>         media0
>         video0

Just because these sub-devices are virtual, it doesn't mean you can 
ignore the way they interact with runtime PM.

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.

Does the uvcvideo interface go into runtime suspend at the right times? 
If it does then you shouldn't have anything more to worry about.

> I liked how the force_direct_complete flag played out here, but I
> agree with Rafael that it can be abused as the PM domain or the bus
> type weren't able to prevent going directly to complete.
> 
> This is my testing branch, btw:
> 
> https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=fast-resume-v5
> 
> > If they are, can't the subsystem/driver code enable
> > runtime PM for each of them when they are registered, by adding a
> > single call in the right spot?
> >
> > If they don't all belong to the same subsystem/driver, who is going to
> > call your pm_runtime_enable_recursive routine?  No single caller will
> > have the right to enable runtime PM for all these devices.
> 
> Yeah, I was thinking that uvcvideo might be able to decide that, but
> I'm not really sure about it.

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.

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/