From owner-p4-projects@FreeBSD.ORG Wed Dec 10 08:11:59 2003 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id A4A5B16A4D2; Wed, 10 Dec 2003 08:11:59 -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 7E9CC16A4D0 for ; Wed, 10 Dec 2003 08:11:59 -0800 (PST) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CDEE43D09 for ; Wed, 10 Dec 2003 08:11:58 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 7727 invoked from network); 10 Dec 2003 16:11:57 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 Dec 2003 16:11:57 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id hBAGBsnd005297; Wed, 10 Dec 2003 11:11:54 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031209222111.B44633@root.org> Date: Wed, 10 Dec 2003 11:11:54 -0500 (EST) From: John Baldwin To: Nate Lawson X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: perforce@FreeBSD.org cc: "M. Warner Losh" 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 16:12:00 -0000 On 10-Dec-2003 Nate Lawson wrote: > On Tue, 9 Dec 2003, M. Warner Losh wrote: >> John Baldwin writes: >> : On 09-Dec-2003 M. Warner Losh wrote: >> : > 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 ???? > > 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, > noted below. Check the ACPI power resource code. It caches the current state, so it would only call the AML twice even if you do a pwr_switch_consumer() twice. One thing we might want to do at some point btw, is have the ACPI PCI bus driver toss all ACPI device_t's for devices that end up being enumerated as PCI devices under an ACPI PCI bus. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/