PERFORCE change 39117 for review

[John Baldwin]

On 03-Oct-2003 Warner Losh wrote:
> http://perforce.freebsd.org/chv.cgi?CH=39117
> 
> Change 39117 by imp at imp_koguchi on 2003/10/03 15:59:36
> 
>       Add comments to jhb's latest additions.
> 
> Affected files ...
> 
> .. //depot/projects/power/notes#6 edit
> 
> Differences ...
> 
> ==== //depot/projects/power/notes#6 (text+ko) ====
> 
> @@ -22,10 +22,19 @@
>        our power shadow tree in the acpi_SetPowerState() function.
>  - define a bus method for powering up/down devices
>    - bus_set_powerstate(parent, child, state) where state is on or off
> +  # actually on/off is insufficient for a power management daemon that
> +  # wants to actively manage the D level of a device.  We should make
> +  # this more flexible so that it can be mapped into states that are
> +  # neither on or off.

What I'm worried about is making it too PCI or ACPI specific.  I just
want to make sure we have a workable abstraction.

> @@ -34,12 +43,22 @@
>    - Convert device_power() to use this method to look up the child device
>      if the name contains a colon instead of treating the name as a pure
>      name of the child device
> +  # We have almost what we need now in the location_str stuff.  However,
> +  # that's more of a 'long string' rather than the short string that's
> +  # wanted for this.
>  - Perhaps rename device_power() to device_command() to allow for other
>    commands like eject, etc.
> +  # methods should be unique.  Command interfaces to userland should dispatch
> +  # the right method.  Otherwise we've reinvented ioctl :-)

I was talking about the syscall here, not the method.  I think the method
should be 'device_[set/get]_powerstate() perhaps.

>  - convert to a model of suspending the device via device_suspend()/resume()
>    rather than detach()/attach()
>    - This may require fixes to drivers so that they continue to function
>      appropriately when their hardware has been suspended
> +  # NO.  This cannot be implemented reliably.  pccard bridges do not tell
> +  # us that a device has been removed while the system was asleep.  That's
> +  # why we detach/reattach on suspend/resume for devices on pccard/cardbus
> +  # bridges.  usb bridges can tell about this, and they properly use the
> +  # suspend/resume functions.
>  
>  The second stage will be to make the powering off of devices more automated.
>  This is still in early design stage.  It may involve a powerd, it may

All the world is not a pccard bridge. :)  The example I am thinking of
is that maybe I want to turn off my soundcard but still have the logical
device hang around and allow, e.g., kde to open it and attach to it when
logging in, and then turn my soundcard back on when I want to play some
MP3s w/o having to restart KDE for it to open the soundcard.  What we
would want to do in that case probably is have a way to ask the device
if it is ok to just suspend/resume it for a power down and have the
default method be to use detach/attach() unless the device says it is ok
to use suspend/resume.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/