Re: Re: Runtime PM and device locking

[Adam Belay <ambx1@neo.rr.com>]

[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]

On Mon, Aug 08, 2005 at 04:03:56PM -0400, Alan Stern wrote:
> On Mon, 8 Aug 2005, Patrick Mochel wrote:
> 
> > 
> > On Sat, 6 Aug 2005, Alan Stern wrote:
> > 
> > > Brief recap: To avoid races, the RTPM code in a driver will need to
> > > lock the device while it does its work.  The locking-order
> > > requirement for dev->sem is that locks can only be acquired going
> > > _down_ the device tree: a thread that owns a child's lock may not try
> > > to lock the parent.  However RTPM involves notifications that go _up_
> > > the tree.  This makes it impossible to acquire the locks we need.
> > >
> > > There doesn't appear to be any way to make this work as stated.  So
> > > instead, we add a second semaphore to struct device: dev->power_sem.
> > > The rule for locking is that power_sem's can only be acquired going
> > > _up_ the power DAG.  In addition, if a thread holds a device's
> > > power_sem then it may not try to lock any device's regular semaphore.
> > > (That is, first lock dev->sem, then lock dev->power_sem, then go up
> > > the DAG only acquiring power_sem's.)
> > 
> > At first thought, it seems Ok with the caveat that it should go in to a
> > separate object (the power object with which to create the power DAG).
> > This should make it a bit easier to understand and follow.

Pat, I'm not using kobjects in my power object code.  If we decide it's
necessary, how should we name the power nodes?

> 
> Good -- mainly I just wanted to check that the idea wasn't totally 
> off-base.  Putting the power_sem into the power object makes sense.

This solution is very similar to the power object tree patch I'm currently
working on.  The main difference is that I'm using pre-state-change and
post-state-change notification methods.  The advantage is that we should
be able to use an iterative algorithm, allowing for deep power trees.  I'll
post code soon.

> 
> There are still one or two patches pending for USB power management.  Once 
> those have been submitted and added to Greg's tree, I'll put together 
> something that implements most of this RTPM stuff for USB.  It'll make a 
> good working example to stimulate future discussions.

I think that would be very interesting.

Thanks,
Adam

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]