PERFORCE change 43464 for review

[John Baldwin]

On 10-Dec-2003 M. Warner Losh wrote:
> In message: <XFMail.20031209134426.jhb at FreeBSD.org>
>             John Baldwin <jhb at FreeBSD.org> writes:
>: 
>: On 09-Dec-2003 M. Warner Losh wrote:
>: > In message: <XFMail.20031208155247.jhb at FreeBSD.org>
>: >             John Baldwin <jhb at freebsd.org> writes:
>: >: 
>: >: On 05-Dec-2003 Nate Lawson wrote:
>: >: > On Fri, 5 Dec 2003, John Baldwin wrote:
>: >: >> Change 43464 by jhb at jhb_blue on 2003/12/05 12:59:01
>: >: >>
>: >: >>      More updates.  Closer to working than I thought.  In theory
>: >: >>      PCI devices should all just work now.
>: >: > 
>: >: > This handles PCI.  Are you ok with me adding the call to
>: >: > acpi_pwr_switch_consumer() for non-PCI devices like the embedded
>: >: > controller?  I think we need to do this at the top \\_SB level.  I'm a bit
>: >: > confused as to the handoff between the general tree walk and the ACPI-PCI
>: >: > driver though.
>: >: 
>: >: It won't hurt to switch a device on twice.  It should be ok to
>: >: do a top-level tree walk of all device objects and turn them on
>: >: before probing child devices I think.  ACPI shouldn't turn off
>: >: devices that don't probe like PCI does though because ACPI has
>: >: duplicate objects of things like the entire PCI device tree. :-/
>: > 
>: > Actually, there can be times when you don't want to turn on devices at
>: > all.  Walking the whole tree turning them on might be the wrong to
>: > do...
>: > 
>: > Sometimes I think that things in the newbus tree should have a pointer
>: > to the acpi power methods that are used in coordination with the bus
>: > code that is 'activating' the device before the 'probe' and 'attach'
>: > happens.
>: 
>: I think having a 'bus_set_power_state()' method in the bus layer
>: and having device_probe_and_attach() do 'bus_set_power_state(child, ON)'
>: would be sufficient.  ACPI busses would then perform the correct hooks
>: via their bus_set_power_state() methods.
> 
> That is very close to what I had in mind.  My only 'debate' was 0/1 or
> 0,1,2,3 or ????

POWERSTATE_ON = 0
POWERSTATE_OFF = 10  (or 100)

Busses may define meanings for values 1 through 9 (for example, ACPI
and PCI would use D1/D2 for 1, and 2), but only ON and OFF are
constant across the tree.

Also, I was thinking in the shower and would like to have the following:

device_check_powerstate(u_int new_state).
  - Called by the bus on a device when the bus has deteremined that the
    device supports having its powerstate changed and is about to change
    it.  Gives device a chance to veto device change.  Default routine
    is to not veto.  For PCI-PCI bridges, this would perhaps check to
    see if all child devices support powering down for example.  Maybe
    it would do the powering down of child devices, not sure.  It probably
    shouldn't though.

device_set_powerstate(u_int new_state)
  - Called by the bus just before lowering the state and after raising
    the state.

These would replace device_suspend/device_resume() eventually.

For example, when ACPI wants to invoke S1, it would try to send all
its devices to D1.  This would trickle down to PCI via the ACPI Host
to PCI bridges, etc.

I've also wondered if it's worth adding a cached powerstate variable
to device_t that device_get_powerstate() would return.

-- 

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