From owner-p4-projects@FreeBSD.ORG Tue Dec 9 17:59:14 2003 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id D919016A4D0; Tue, 9 Dec 2003 17:59:13 -0800 (PST) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF6BE16A4CE; Tue, 9 Dec 2003 17:59:13 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 622FA43D21; Tue, 9 Dec 2003 17:59:12 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id hBA1xBiV013989; Tue, 9 Dec 2003 18:59:11 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 09 Dec 2003 18:58:59 -0700 (MST) Message-Id: <20031209.185859.00003429.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: References: <20031208.175500.36934037.imp@bsdimp.com> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: perforce@FreeBSD.org cc: nate@root.org Subject: Re: PERFORCE change 43464 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2003 01:59:14 -0000 In message: John Baldwin writes: : : On 09-Dec-2003 M. Warner Losh wrote: : > In message: : > John Baldwin 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