Date: Mon, 06 Oct 2003 12:13:39 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@freebsd.org Cc: perforce@freebsd.org Subject: Re: PERFORCE change 39117 for review Message-ID: <20031006.121339.127180127.imp@bsdimp.com> In-Reply-To: <XFMail.20031006111405.jhb@FreeBSD.org> References: <200310032259.h93Mxdn5018279@repoman.freebsd.org> <XFMail.20031006111405.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <XFMail.20031006111405.jhb@FreeBSD.org>
John Baldwin <jhb@freebsd.org> writes:
:
: 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.
I was thinking maybe a percentage that could be mapped to multiple
levels as the device sees fit. D1 and D2 states are ill defined at
best for most interfaces (although specific parts may be different).
D3 is well defined for most interfaces. I too am torn about making it
too 'this generation of power goo' specific.
I'd also like to distinguish between D3hot and D3cold somehow. The
cardbus bridge can be put into D3hot when there are no cards in use
and then power it to D0 when the insertion event happens... My one
worry is that we can't quiet the interrupt w/o writing to config
space. At fast/mpsafe land, maybe this is too expensive an
interrupt. Good thing it would be a very rare event. I'm less sure
about other drivers (sound cards can do similar things, I've been
told, when they are at d3 state: when play comes along it should put
it into d0).
This does get back to how we want the end system to look. Is there a
daemon that turns off idle devices? etc
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031006.121339.127180127.imp>