From owner-p4-projects@FreeBSD.ORG Tue Dec 9 22:32:47 2003 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 79C2C16A4D1; Tue, 9 Dec 2003 22:32:47 -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 532EA16A4CE for ; Tue, 9 Dec 2003 22:32:47 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 8CD7643D29 for ; Tue, 9 Dec 2003 22:32:45 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 44668 invoked by uid 1000); 10 Dec 2003 06:32:47 -0000 Date: Tue, 9 Dec 2003 22:32:47 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20031209222111.B44633@root.org> Message-ID: <20031209223150.M44633@root.org> References: <20031208.175500.36934037.imp@bsdimp.com> <20031209222111.B44633@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: perforce@FreeBSD.org cc: jhb@FreeBSD.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 06:32:48 -0000 On Tue, 9 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 ???? Oh, and I like the idea of using 0-3 and having them #defined. This is common to PCI and ACPI D-states. -Nate