Runtime resume of children

Runtime resume of children

[Alan Stern]

Rafael:

Here's the situation.  Device A has children B1, ..., Bn (possibly
others too).  I need to guarantee that whenever A is active, so are the
children.

One direction seems easy enough.  I can make the idle handler for the
B's first check that A and all the B's are ready to be suspended, then
suspend all the B's, and then suspend A.  This works because the PM and 
driver cores never directly suspend a device; all the do is notify the 
idle handler.

The other direction is a little more complicated.  Resumes initiated by
the bus code aren't troublesome; they can always be written so as to
resume the B's along with the A's.  The real problem arises when A is
resumed directly by the PM or driver cores.  For example, consider what
would happen when one of B1's children sends a remote wakeup signal.  
The PM core would automatically resume B1 and A, but there would be no
chance for the bus code to resume the other B's.

I can't make the runtime_resume method for A call pm_runtime_resume()  
for all the B's.  It would deadlock inside __pm_runtime_resume() where
the code to resume B1 waits for A's resume to complete.

Calling pm_request_resume() for all the B's instead isn't a very good
solution.  For one thing, it's silly to add latency by using a work
queue instead of just doing the resumes directly.  There are also
problems of synchronization, such as the fact that other code expects
all the B's to be resumed when A's resume completes.

Do you have any ideas on how to approach this?  How about allowing A's
runtime_resume method to set A->power.runtime_status to RPM_ACTIVE,
before it tries to resume the B's?  That would avoid the deadlock.

Alan Stern

Re: Runtime resume of children

[Rafael J. Wysocki]

On Sunday 22 November 2009, Alan Stern wrote:
> Rafael:
> 
> Here's the situation.  Device A has children B1, ..., Bn (possibly
> others too).  I need to guarantee that whenever A is active, so are the
> children.

But it's perfectly valid to have an inactive device under an active parent, so
I guess this is not a general case.

> One direction seems easy enough.  I can make the idle handler for the
> B's first check that A and all the B's are ready to be suspended, then
> suspend all the B's, and then suspend A.  This works because the PM and 
> driver cores never directly suspend a device; all the do is notify the 
> idle handler.
> 
> The other direction is a little more complicated.  Resumes initiated by
> the bus code aren't troublesome; they can always be written so as to
> resume the B's along with the A's.  The real problem arises when A is
> resumed directly by the PM or driver cores.  For example, consider what
> would happen when one of B1's children sends a remote wakeup signal.  
> The PM core would automatically resume B1 and A, but there would be no
> chance for the bus code to resume the other B's.

pm_runtime_resume() schedules an idle request for 'dev' at the end,
which theoretically may resume the B's that are still suspended.  There still
would be a delay, though.

> I can't make the runtime_resume method for A call pm_runtime_resume()  
> for all the B's.  It would deadlock inside __pm_runtime_resume() where
> the code to resume B1 waits for A's resume to complete.
> 
> Calling pm_request_resume() for all the B's instead isn't a very good
> solution.  For one thing, it's silly to add latency by using a work
> queue instead of just doing the resumes directly.  There are also
> problems of synchronization, such as the fact that other code expects
> all the B's to be resumed when A's resume completes.
> 
> Do you have any ideas on how to approach this?  How about allowing A's
> runtime_resume method to set A->power.runtime_status to RPM_ACTIVE,
> before it tries to resume the B's?  That would avoid the deadlock.

I don't see a problem with that as long as the A's runtime_resume returns 0 in
such a case.

Thanks,
Rafael

Re: Runtime resume of children

[Alan Stern]

On Mon, 23 Nov 2009, Rafael J. Wysocki wrote:

> On Sunday 22 November 2009, Alan Stern wrote:
> > Rafael:
> > 
> > Here's the situation.  Device A has children B1, ..., Bn (possibly
> > others too).  I need to guarantee that whenever A is active, so are the
> > children.
> 
> But it's perfectly valid to have an inactive device under an active parent, so
> I guess this is not a general case.

Correct.  It's a specific case that I need to handle for USB.

> > Do you have any ideas on how to approach this?  How about allowing A's
> > runtime_resume method to set A->power.runtime_status to RPM_ACTIVE,
> > before it tries to resume the B's?  That would avoid the deadlock.
> 
> I don't see a problem with that as long as the A's runtime_resume returns 0 in
> such a case.

Should I export a routine from the PM core for doing this or just 
implement it directly?

Alan Stern

Re: Runtime resume of children

[Rafael J. Wysocki]

On Monday 23 November 2009, Alan Stern wrote:
> On Mon, 23 Nov 2009, Rafael J. Wysocki wrote:
> 
> > On Sunday 22 November 2009, Alan Stern wrote:
> > > Rafael:
> > > 
> > > Here's the situation.  Device A has children B1, ..., Bn (possibly
> > > others too).  I need to guarantee that whenever A is active, so are the
> > > children.
> > 
> > But it's perfectly valid to have an inactive device under an active parent, so
> > I guess this is not a general case.
> 
> Correct.  It's a specific case that I need to handle for USB.
> 
> > > Do you have any ideas on how to approach this?  How about allowing A's
> > > runtime_resume method to set A->power.runtime_status to RPM_ACTIVE,
> > > before it tries to resume the B's?  That would avoid the deadlock.
> > 
> > I don't see a problem with that as long as the A's runtime_resume returns 0 in
> > such a case.
> 
> Should I export a routine from the PM core for doing this or just 
> implement it directly?

Please implement that directly.  If there's any other bus type needing it,
we'll move it to the core.

Thanks,
Rafael

Re: Runtime resume of children

[Oliver Neukum]

Am Montag, 23. November 2009 21:59:12 schrieb Alan Stern:
> On Mon, 23 Nov 2009, Rafael J. Wysocki wrote:
> > On Sunday 22 November 2009, Alan Stern wrote:
> > > Rafael:
> > > 
> > > Here's the situation.  Device A has children B1, ..., Bn (possibly
> > > others too).  I need to guarantee that whenever A is active, so are the
> > > children.
> >
> > 
> > But it's perfectly valid to have an inactive device under an active
> > parent, so I guess this is not a general case.
> 
> Correct.  It's a specific case that I need to handle for USB.

Hm. In which way is this different from a system where devices
share clock lines? It seems to me that groups of devices that
can be suspended only together are not rare. That in USB these
devices happen to be all a device's interfaces does not really
matter.

	Regards
		Oliver

Re: Runtime resume of children

[Alan Stern]

On Wed, 25 Nov 2009, Oliver Neukum wrote:

> Am Montag, 23. November 2009 21:59:12 schrieb Alan Stern:
> > On Mon, 23 Nov 2009, Rafael J. Wysocki wrote:
> > > On Sunday 22 November 2009, Alan Stern wrote:
> > > > Rafael:
> > > > 
> > > > Here's the situation.  Device A has children B1, ..., Bn (possibly
> > > > others too).  I need to guarantee that whenever A is active, so are the
> > > > children.
> > >
> > > 
> > > But it's perfectly valid to have an inactive device under an active
> > > parent, so I guess this is not a general case.
> > 
> > Correct.  It's a specific case that I need to handle for USB.
> 
> Hm. In which way is this different from a system where devices
> share clock lines? It seems to me that groups of devices that
> can be suspended only together are not rare. That in USB these
> devices happen to be all a device's interfaces does not really
> matter.

That's not a good example because there's nothing wrong with suspending
some of the devices while leaving the clock and the others running.  
You'll have to search harder to find a group of devices which really do 
need to be suspended all together.

Alan Stern

Re: Runtime resume of children

[Oliver Neukum]

Am Mittwoch, 25. November 2009 21:46:14 schrieb Alan Stern:
> On Wed, 25 Nov 2009, Oliver Neukum wrote:
> > Am Montag, 23. November 2009 21:59:12 schrieb Alan Stern:

> > > Correct.  It's a specific case that I need to handle for USB.
> >
> > Hm. In which way is this different from a system where devices
> > share clock lines? It seems to me that groups of devices that
> > can be suspended only together are not rare. That in USB these
> > devices happen to be all a device's interfaces does not really
> > matter.
> 
> That's not a good example because there's nothing wrong with suspending
> some of the devices while leaving the clock and the others running.
> You'll have to search harder to find a group of devices which really do
> need to be suspended all together.

True, so think about a shared switchable power line. But that's the
way of the future.

	Regards
		Oliver

Re: Runtime resume of children

[Mark Brown]

On Thu, Nov 26, 2009 at 05:47:08PM +0100, Oliver Neukum wrote:
> Am Mittwoch, 25. November 2009 21:46:14 schrieb Alan Stern:

> > That's not a good example because there's nothing wrong with suspending
> > some of the devices while leaving the clock and the others running.
> > You'll have to search harder to find a group of devices which really do
> > need to be suspended all together.

> True, so think about a shared switchable power line. But that's the
> way of the future.

There's already quite a few examples of that.  For supply lines handled
via the regulator API the API implements reference counting so that the 
devices don't need to worry about other users - it just drops the refs
to the supply.  For shared power gating blocks in CPUs (like SH, OMAP
and S3C64xx have for example) the current idea is that the bus will do a
similar thing.