Re: [RFD] Automatic suspend

[Alan Stern]

On Tue, 17 Feb 2009, Rafael J. Wysocki wrote:

> On Monday 16 February 2009, Alan Stern wrote:
> > On Mon, 16 Feb 2009, Rafael J. Wysocki wrote:
> > 
> > > OK, so I think there are two things that user space may be allowed to do as
> > > far as putting devices into low power states is concerned:
> > > * disable/enable the automatic power management of the device (provided that
> > >   the driver supports the automatic PM)
> > 
> > Set the automatic PM parameters (idle timeout, state to go to, etc.).  
> 
> Yes.  I'm not sure about the state part, though.

Maybe, maybe not.  IMO it's too early to tell whether anyone will need 
this ability, so we shouldn't rule it out.

> > What about situations where we want to distinguish between the power 
> > state of the device itself and the power state of the link?  For a disk 
> > drive we may want to power the link on and off quite a lot, as that 
> > has low latency, but spinning the disk up and down takes a long time 
> > and so should have a longer idle-time value.
> 
> Well, I'm not sure at the moment.
> 
> Do you have any suggestions?

Not very well fleshed-out ones.  I've got a vague idea for allowing a
disk to have a 3-level power arrangement: full power, link disabled but
drive still spinning, and device suspended.  Arranging for automatic
transitions among those states will be a little clumsy but it can be
done.  As an example of the clumsiness, this scheme requires that the
drive has _two_ idle-timeout values, one for the link and one for the
drive itself.

Another possibility is to set up independent runtime PM for the
transport and the device.  This means allowing the possibility that the
transport is suspended while its child (the device) is not.  This is a
little simpler (there's only one idle-timeout per device, since the
link is treated as an independent device), but it violates the
principle of never suspending a parent while there is an active child.

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/