Runtime PM and device locking

Runtime PM and device locking

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2175 bytes --]

Pat:

After considerable thought, this is the only way I can figure out to
handle device locking while doing runtime PM (RTPM).

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.)

If a driver needs to prevent power changes while it's doing some other
work, it must lock dev->power_sem.  That's not so bad.  However it
must release power_sem before doing anything that would affect the
device's children.  It can safely hold dev->sem the whole time.
However an RTPM notification routine can never acquire dev->sem.

The lack of full synchronization between RTPM notifications and other
activities means we need a few special precautions.  In particular, we
have to worry about a notification racing with an unbind.  To prevent
such races, we will need to add to struct device a field that
indicates the condition of driver binding: UNBOUND, BINDING, BOUND, or
UNBINDING.  (There already is a private field like this in USB's
struct interface.)  When sending a notification, a process must
acquire parent->power_sem and then immediately check to see whether
the parent's condition is UNBINDING or UNBOUND.  If it is then the
process must release parent->power_sem without trying to send the
notification.  Of course, we can create helper functions to care of
these things.

There will be a lot of tricky details, but I think it can be made to
work.  What's your opinion?

Alan Stern


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

Re: Runtime PM and device locking

[Patrick Mochel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1129 bytes --]


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.

Thanks,


	Pat

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

Re: Runtime PM and device locking

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1624 bytes --]

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.

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.

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.

Alan Stern


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

Re: Re: Runtime PM and device locking

[Adam Belay]

[-- 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 --]

Re: Re: Runtime PM and device locking

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1827 bytes --]

On Mon, 8 Aug 2005, Adam Belay wrote:

> 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.

I'm looking forward to seeing it.  However, I think an iterative algorithm 
may be impractical, to a greater or lesser extent.  (Not to mention the 
fact that in any particular case we never need both pre- and post- 
notifications.)

Consider a device that has many power parents (P1 - Pn).  A typical 
power-state change for this device might have to go like this:

	Do something to the device.

	Notify P1.

	Do some more to the device.

	Notify P2.

	Do some more to the device.

	...

	Notify Pn.

	Do the last thing to the device.

It's awkward enough as straight-line code.  If you were to use an 
iterative algorithm, the driver would need to include n-1 otherwise 
useless intermediate states: the state where P2 needs to be notified, ..., 
the state where Pn needs to be notified.  I would prefer to avoid putting 
that kind of burden on driver authors.  Then there's the question of how 
you handle an error return from Pk, for some k <= n.

Also, I've been assuming that the implementation of the notification
methods would not be generic -- it would be different for each type of
bus.  For instance, USB already has routines that come close to being
these notifications: usb_suspend_device and usb_resume_device.  In
general, different buses will need to know different things about power
changes in their children.  This makes it hard to come up with a common
function prototype or format, and makes it hard to use an iterative
algorithm.

Alan Stern


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

Re: Re: Runtime PM and device locking

[Pavel Machek]

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

Hi!

> > 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.
> 
> I'm looking forward to seeing it.  However, I think an iterative algorithm 
> may be impractical, to a greater or lesser extent.  (Not to mention the 
> fact that in any particular case we never need both pre- and post- 
> notifications.)
> 
> Consider a device that has many power parents (P1 - Pn).  A typical 
> power-state change for this device might have to go like this:
> 
> 	Do something to the device.
> 
> 	Notify P1.
> 
> 	Do some more to the device.
> 
> 	Notify P2.
> 
> 	Do some more to the device.
> 
> 	...
> 
> 	Notify Pn.
> 
> 	Do the last thing to the device.

Ouch, thats really ugly. Is it really neccessary to do something to
the device just after notifying parent?

I thought it would be more like

mouse
	"oh, I'm idle".
	power myself down. 
	tell all my parents that they can power down my cord.

If something is neccessary to be done after changing parent state, I'd
do it during call from parent.
								Pavel


-- 
if you have sharp zaurus hardware you don't need... you know my address

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

RE: Re: Runtime PM and device locking

[Woodruff, Richard]

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

> (Not to mention the
> fact that in any particular case we never need both pre- and post-
> notifications.)

For voltage and frequency scaling in embedded devices we defiantly have
used both pre and post notifications.

Tell drivers to 'prepare' for change.  This in some cases means
suspending master peripheral DMA operations to DDR.  Next the power
manager does the DVFS switch.  Finally a "post" notification is sent
which allows master drivers to resume their DMA accesses.

Some devices are part of smarter busses which have some notion of these.
Others don't.  In general you provide the list entries in the generic
structure.  Whether a specific device registers a local call back is
something else all together.

Regards,
Richard W. 



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

RE: Re: Runtime PM and device locking

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1496 bytes --]

On Mon, 8 Aug 2005, Woodruff, Richard wrote:

> > (Not to mention the
> > fact that in any particular case we never need both pre- and post-
> > notifications.)
> 
> For voltage and frequency scaling in embedded devices we defiantly have
> used both pre and post notifications.
> 
> Tell drivers to 'prepare' for change.  This in some cases means
> suspending master peripheral DMA operations to DDR.  Next the power

Master peripheral?  DDR?

> manager does the DVFS switch.  Finally a "post" notification is sent

DVFS?

> which allows master drivers to resume their DMA accesses.

Master drivers?

> Some devices are part of smarter busses which have some notion of these.
> Others don't.  In general you provide the list entries in the generic
> structure.  Whether a specific device registers a local call back is
> something else all together.

Even without understanding a lot of your terms, I think hat you're talking
about comes closer to system PM than runtime PM, in that involves a
centrally-directed change to an entire subsystem.  It's not a case of one
driver deciding its device can be suspended and then propagating that
information upward.

The situation you described involves a new concept: a driver that cannot 
change its power usage without first asking all its clients to temporarily 
suspend operations.  Note that the messages you described are not the same 
kind of "notifications" as I've been talking about, because they go down 
the tree instead of up.

Alan Stern


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

RE: Re: Runtime PM and device locking

[Woodruff, Richard]

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

> On Mon, 8 Aug 2005, Alan Stern wrote:
>
> > Tell drivers to 'prepare' for change.  This in some cases means
> > suspending master peripheral DMA operations to DDR.  Next the power
> 
> Master peripheral?  DDR?

Master peripheral: meaning a peripheral which can do DMA to main memory.
This may be using a centralized or private DMA interface.  

DDR just being DDR-SDRAM (double data rate - synchronous dynamic ram).

> > manager does the DVFS switch.  Finally a "post" notification is sent
> 
> DVFS?

Dynamic Voltage Frequency Scaling

> > which allows master drivers to resume their DMA accesses.
> 
> Master drivers?

A driver which controls an entity which can access memory or other
shared resource with out control processor (CPU) intervention.

> > Some devices are part of smarter busses which have some notion of
these.
> > Others don't.  In general you provide the list entries in the
generic
> > structure.  Whether a specific device registers a local call back is
> > something else all together.
> 
> Even without understanding a lot of your terms, I think hat you're
talking
> about comes closer to system PM than runtime PM, in that involves a
> centrally-directed change to an entire subsystem.  It's not a case of
one
> driver deciding its device can be suspended and then propagating that
> information upward.

Yes, I'm talking about what it takes to do runtime power management of
shared clocks.  It at times does take a central coordinator to allow a
clock change.

Devices can auto idle at times or ask for gating of their local clocks.
This is the kind of thing which you must be thinking of.   Along with
idling/gating devices can scale their clocks to save power.

With scaling the CPU is the device which comes to mind first but need
not be the only case.  For many embedded systems, scaling the CPU also
means adjusting device clock notions.  In order to due this you need
coordination.  

A device can also request a clock speed change which also forces the
need for a sub tree recalculation if the request changes a common clock.
Related drivers may be able to react by adjusting local dividers if
given a chance.

> The situation you described involves a new concept: a driver that
cannot
> change its power usage without first asking all its clients to
temporarily
> suspend operations.  Note that the messages you described are not the
same
> kind of "notifications" as I've been talking about, because they go
down
> the tree instead of up.

Yes.  That is true.  I'm presently looking at some clock code, and going
up and down trees is an issue.  There are few possible use cases from
devices wanting a change which requires a notification going up which
cause a change coming back down to other drivers.  

To do run time frequency scaling of the CPU requires a notification
structure down to the drivers.  Why not use the same or extended
structure to propagate clock request from drivers.

Regards,
Richard W.



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

RE: Re: Runtime PM and device locking

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2095 bytes --]

On Mon, 8 Aug 2005, Woodruff, Richard wrote:

...

Thanks for explaining the terminology.

> Yes, I'm talking about what it takes to do runtime power management of
> shared clocks.  It at times does take a central coordinator to allow a
> clock change.
> 
> Devices can auto idle at times or ask for gating of their local clocks.
> This is the kind of thing which you must be thinking of.   Along with
> idling/gating devices can scale their clocks to save power.

Right, that's what I had in mind.  Centralized clock control is a 
different, more difficult problem -- as you know!

> With scaling the CPU is the device which comes to mind first but need
> not be the only case.  For many embedded systems, scaling the CPU also
> means adjusting device clock notions.  In order to due this you need
> coordination.  
> 
> A device can also request a clock speed change which also forces the
> need for a sub tree recalculation if the request changes a common clock.
> Related drivers may be able to react by adjusting local dividers if
> given a chance.
> 
> > The situation you described involves a new concept: a driver that
> cannot
> > change its power usage without first asking all its clients to
> temporarily
> > suspend operations.  Note that the messages you described are not the
> same
> > kind of "notifications" as I've been talking about, because they go
> down
> > the tree instead of up.
> 
> Yes.  That is true.  I'm presently looking at some clock code, and going
> up and down trees is an issue.  There are few possible use cases from
> devices wanting a change which requires a notification going up which
> cause a change coming back down to other drivers.  
> 
> To do run time frequency scaling of the CPU requires a notification
> structure down to the drivers.  Why not use the same or extended
> structure to propagate clock request from drivers.

At the moment I'm inclined to leave clock control somewhat separate from 
other aspects of runtime PM.  There are other people already working on 
it, as we've seen from recent activity in the mailing list.

Alan Stern


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

RE: Re: Runtime PM and device locking

[Preece Scott-PREECE]

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

As I understood it, the "parents" are simply things the device has
dependencies on. Since the dependencies are different, there is at least
potentially a benefit in being able to dismiss those dependencies
serially (that is, as the dependency on each device goes away, tell that
parental device that its parental role has been satisfied and that the
child is no longer depending on it as a parent).

scott

-----Original Message-----
From: linux-pm-bounces@lists.osdl.org
[mailto:linux-pm-bounces@lists.osdl.org] On Behalf Of Pavel Machek
Sent: Thursday, August 11, 2005 9:10 AM
To: Alan Stern
Cc: Linux-pm mailing list
Subject: Re: [linux-pm] Re: Runtime PM and device locking

Hi!

> > 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.
> 
> I'm looking forward to seeing it.  However, I think an iterative 
> algorithm may be impractical, to a greater or lesser extent.  (Not to 
> mention the fact that in any particular case we never need both pre- 
> and post-
> notifications.)
> 
> Consider a device that has many power parents (P1 - Pn).  A typical 
> power-state change for this device might have to go like this:
> 
> 	Do something to the device.
> 
> 	Notify P1.
> 
> 	Do some more to the device.
> 
> 	Notify P2.
> 
> 	Do some more to the device.
> 
> 	...
> 
> 	Notify Pn.
> 
> 	Do the last thing to the device.

Ouch, thats really ugly. Is it really neccessary to do something to the
device just after notifying parent?

I thought it would be more like

mouse
	"oh, I'm idle".
	power myself down. 
	tell all my parents that they can power down my cord.

If something is neccessary to be done after changing parent state, I'd
do it during call from parent.
								Pavel


--
if you have sharp zaurus hardware you don't need... you know my address


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

Re: Re: Runtime PM and device locking

[Pavel Machek]

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

Hi!

> As I understood it, the "parents" are simply things the device has
> dependencies on. Since the dependencies are different, there is at least
> potentially a benefit in being able to dismiss those dependencies

Power-consumption benefit?

> serially (that is, as the dependency on each device goes away, tell that
> parental device that its parental role has been satisfied and that the
> child is no longer depending on it as a parent).

This would lead to something pretty complex. Anyway, you can have
that, just introduce multiple states to the device. "Mouse is
idle". "Mouse is idle and no longer need clock". "Mouse is really idle
and no longer needs anything".

But I believe thats way too complex for most devices.
								Pavel

> scott
> 
> -----Original Message-----
> From: linux-pm-bounces@lists.osdl.org
> [mailto:linux-pm-bounces@lists.osdl.org] On Behalf Of Pavel Machek
> Sent: Thursday, August 11, 2005 9:10 AM
> To: Alan Stern
> Cc: Linux-pm mailing list
> Subject: Re: [linux-pm] Re: Runtime PM and device locking
> 
> Hi!
> 
> > > 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.
> > 
> > I'm looking forward to seeing it.  However, I think an iterative 
> > algorithm may be impractical, to a greater or lesser extent.  (Not to 
> > mention the fact that in any particular case we never need both pre- 
> > and post-
> > notifications.)
> > 
> > Consider a device that has many power parents (P1 - Pn).  A typical 
> > power-state change for this device might have to go like this:
> > 
> > 	Do something to the device.
> > 
> > 	Notify P1.
> > 
> > 	Do some more to the device.
> > 
> > 	Notify P2.
> > 
> > 	Do some more to the device.
> > 
> > 	...
> > 
> > 	Notify Pn.
> > 
> > 	Do the last thing to the device.
> 
> Ouch, thats really ugly. Is it really neccessary to do something to the
> device just after notifying parent?
> 
> I thought it would be more like
> 
> mouse
> 	"oh, I'm idle".
> 	power myself down. 
> 	tell all my parents that they can power down my cord.
> 
> If something is neccessary to be done after changing parent state, I'd
> do it during call from parent.
> 								Pavel
> 
> 
> --
> if you have sharp zaurus hardware you don't need... you know my address

-- 
if you have sharp zaurus hardware you don't need... you know my address

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

Re: Re: Runtime PM and device locking

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2458 bytes --]

On Thu, 11 Aug 2005, Pavel Machek wrote:

> Hi!
> 
> > As I understood it, the "parents" are simply things the device has
> > dependencies on. Since the dependencies are different, there is at least
> > potentially a benefit in being able to dismiss those dependencies
> 
> Power-consumption benefit?

Programming simplicity benefit.

> > serially (that is, as the dependency on each device goes away, tell that
> > parental device that its parental role has been satisfied and that the
> > child is no longer depending on it as a parent).
> 
> This would lead to something pretty complex. Anyway, you can have
> that, just introduce multiple states to the device. "Mouse is
> idle". "Mouse is idle and no longer need clock". "Mouse is really idle
> and no longer needs anything".
> 
> But I believe thats way too complex for most devices.

Exactly.  Straight-line code is much simpler than multiple intermediate 
states.


> > > Consider a device that has many power parents (P1 - Pn).  A typical 
> > > power-state change for this device might have to go like this:
> > > 
> > > 	Do something to the device.
> > > 
> > > 	Notify P1.
> > > 
> > > 	Do some more to the device.
> > > 
> > > 	Notify P2.
> > > 
> > > 	Do some more to the device.
> > > 
> > > 	...
> > > 
> > > 	Notify Pn.
> > > 
> > > 	Do the last thing to the device.
> > 
> > Ouch, thats really ugly. Is it really neccessary to do something to the
> > device just after notifying parent?

Sometimes it is.  For a resume transition, you need to tell the device
itself to wake up _after_ telling all the parents to resupply the
necessary power resources.

> > I thought it would be more like
> > 
> > mouse
> > 	"oh, I'm idle".
> > 	power myself down. 
> > 	tell all my parents that they can power down my cord.

For a mouse, this is indeed how a suspend would work.  My example above
was for a much more complex device; a mouse is a degenerate case where n
= 1 and the last step isn't needed for suspend (and the first step isn't
needed for resume).

> > If something is neccessary to be done after changing parent state, I'd
> > do it during call from parent.

But that call is to the parent's driver.  It can't be expected to modify 
settings on the child device.  To finish the mouse example, the resume 
code would look like this:

mouse
	"oh, something has happened".
	tell all my parents that they must power up my card.
	power myself up.

Hopefully this is all clear now.

Alan Stern


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

RE: Re: Runtime PM and device locking

[Preece Scott-PREECE]

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

Yes, there is a power-consumption benefit, in that parents might be able
to shut themselves down sooner if their part of the child's dependency
was satisfied. I agree it's a small advantage, but power consumption
tends to be made up of places where you can get small advantages.

I also agree that MOST devices would have a simpler model. It might be
good to have the interfaces allow for both simple situations (one
dependency, no complex semantics, avoid the extra notifications) and
complex ones (multiple, interacting dependencies, extra notifications
required).

scott 

-----Original Message-----
From: Pavel Machek [mailto:pavel@ucw.cz] 
Sent: Thursday, August 11, 2005 9:33 AM
To: Preece Scott-PREECE
Cc: Alan Stern; Linux-pm mailing list
Subject: Re: [linux-pm] Re: Runtime PM and device locking

Hi!

> As I understood it, the "parents" are simply things the device has 
> dependencies on. Since the dependencies are different, there is at 
> least potentially a benefit in being able to dismiss those 
> dependencies

Power-consumption benefit?

> serially (that is, as the dependency on each device goes away, tell 
> that parental device that its parental role has been satisfied and 
> that the child is no longer depending on it as a parent).

This would lead to something pretty complex. Anyway, you can have that,
just introduce multiple states to the device. "Mouse is idle". "Mouse is
idle and no longer need clock". "Mouse is really idle and no longer
needs anything".

But I believe thats way too complex for most devices.
								Pavel

> scott
> 
> -----Original Message-----
> From: linux-pm-bounces@lists.osdl.org
> [mailto:linux-pm-bounces@lists.osdl.org] On Behalf Of Pavel Machek
> Sent: Thursday, August 11, 2005 9:10 AM
> To: Alan Stern
> Cc: Linux-pm mailing list
> Subject: Re: [linux-pm] Re: Runtime PM and device locking
> 
> Hi!
> 
> > > 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.
> > 
> > I'm looking forward to seeing it.  However, I think an iterative 
> > algorithm may be impractical, to a greater or lesser extent.  (Not 
> > to mention the fact that in any particular case we never need both 
> > pre- and post-
> > notifications.)
> > 
> > Consider a device that has many power parents (P1 - Pn).  A typical 
> > power-state change for this device might have to go like this:
> > 
> > 	Do something to the device.
> > 
> > 	Notify P1.
> > 
> > 	Do some more to the device.
> > 
> > 	Notify P2.
> > 
> > 	Do some more to the device.
> > 
> > 	...
> > 
> > 	Notify Pn.
> > 
> > 	Do the last thing to the device.
> 
> Ouch, thats really ugly. Is it really neccessary to do something to 
> the device just after notifying parent?
> 
> I thought it would be more like
> 
> mouse
> 	"oh, I'm idle".
> 	power myself down. 
> 	tell all my parents that they can power down my cord.
> 
> If something is neccessary to be done after changing parent state, I'd

> do it during call from parent.
> 								Pavel
> 
> 
> --
> if you have sharp zaurus hardware you don't need... you know my 
> address

--
if you have sharp zaurus hardware you don't need... you know my address


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