Date: Mon, 06 Oct 2003 11:14:05 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Warner Losh <imp@FreeBSD.org> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: RE: PERFORCE change 39117 for review Message-ID: <XFMail.20031006111405.jhb@FreeBSD.org> In-Reply-To: <200310032259.h93Mxdn5018279@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03-Oct-2003 Warner Losh wrote: > http://perforce.freebsd.org/chv.cgi?CH=39117 > > Change 39117 by imp@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@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20031006111405.jhb>