Date: Tue, 09 Dec 2003 18:58:59 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@FreeBSD.org Cc: nate@root.org Subject: Re: PERFORCE change 43464 for review Message-ID: <20031209.185859.00003429.imp@bsdimp.com> In-Reply-To: <XFMail.20031209134426.jhb@FreeBSD.org> References: <20031208.175500.36934037.imp@bsdimp.com> <XFMail.20031209134426.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <XFMail.20031209134426.jhb@FreeBSD.org>
John Baldwin <jhb@FreeBSD.org> writes:
:
: On 09-Dec-2003 M. Warner Losh wrote:
: > In message: <XFMail.20031208155247.jhb@FreeBSD.org>
: > John Baldwin <jhb@freebsd.org> writes:
: >:
: >: On 05-Dec-2003 Nate Lawson wrote:
: >: > On Fri, 5 Dec 2003, John Baldwin wrote:
: >: >> Change 43464 by jhb@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 ????
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031209.185859.00003429.imp>