Date: Tue, 9 Dec 2003 22:32:47 -0800 (PST) From: Nate Lawson <nate@root.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: jhb@FreeBSD.org Subject: Re: PERFORCE change 43464 for review Message-ID: <20031209223150.M44633@root.org> In-Reply-To: <20031209222111.B44633@root.org> References: <20031208.175500.36934037.imp@bsdimp.com> <XFMail.20031209134426.jhb@FreeBSD.org> <20031209222111.B44633@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 9 Dec 2003, Nate Lawson wrote: > On Tue, 9 Dec 2003, M. Warner Losh wrote: > > John Baldwin <jhb@FreeBSD.org> writes: > > : On 09-Dec-2003 M. Warner Losh wrote: > > : > 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 ???? Oh, and I like the idea of using 0-3 and having them #defined. This is common to PCI and ACPI D-states. -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031209223150.M44633>