PERFORCE change 43464 for review
nate at root.org
Tue Dec 9 22:31:31 PST 2003
On Tue, 9 Dec 2003, M. Warner Losh wrote:
> John Baldwin <jhb at FreeBSD.org> writes:
> : On 09-Dec-2003 M. Warner Losh wrote:
> : > 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 ????
It may hurt to switch a device on twice, depending on how state is kept in
the AML. In the ACPI case, there are several things that need to happen,
Device (PIC) // i8259
Device (KBD) // atkbd0
Device (MOU) // psm0
Device (FDC) // Call _PS0, fdc0
Device (UART) // Call _PS0
Device (LPT) // lpt0
Device (FIR) // ir port
Device (EC) // Call _PS0, embedded controller
Device (AGP) // agp0
Device (CBS0) // cardbus0
Device (CBS1) // cardbus1
Device (CBS2) // cardbus2
So I guess my question is what to do about things like the AGP card or the
cardbus slots, especially the ones that are accessible through a dock. I
know about all these via acpi. However, we don't want to duplicate
calling power methods through both cardbus and acpi, for instance. This
tree doesn't exactly map to the devinfo tree:
Anyway, I'd love to hear how the ACPI AML and devinfo trees map to the
fact that we need to call _PSx on all devices, eject uses _EJx, etc.
More information about the p4-projects