From owner-p4-projects@FreeBSD.ORG Tue Dec 9 22:31:31 2003 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 0EFD116A4D0; Tue, 9 Dec 2003 22:31:31 -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 C4EBF16A4CE for ; Tue, 9 Dec 2003 22:31:30 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 42DA743D28 for ; Tue, 9 Dec 2003 22:31:28 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 44656 invoked by uid 1000); 10 Dec 2003 06:31:30 -0000 Date: Tue, 9 Dec 2003 22:31:30 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20031209.185859.00003429.imp@bsdimp.com> Message-ID: <20031209222111.B44633@root.org> References: <20031208.175500.36934037.imp@bsdimp.com> <20031209.185859.00003429.imp@bsdimp.com> 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:31:31 -0000 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. Device (LID) Device (SLPB) Device (PCI0) Device (LPC) Device (SIO) Device (PIC) // i8259 Device (TIMR) Device (KBD) // atkbd0 Device (MOU) // psm0 Device (FDC) // Call _PS0, fdc0 Device (FDD0) Device (UART) // Call _PS0 Device (LPT) // lpt0 Device (ECP) Device (FIR) // ir port Device (EC) // Call _PS0, embedded controller Device (BAT0) Device (BAT1) Device (AC) Device (HKEY) Device (AGP) // agp0 Device (VID) Device (LCD0) Device (CRT0) Device (TV0) Device (PCI1) Device (CBS0) // cardbus0 Device (CBS1) // cardbus1 Device (DOCK) Device (IDE1) Device (PRIM) Device (MSTR) Device (CBS2) // cardbus2 Device (CBS3) So I guess my question is what to do about things like the AGP card or the cardbus slots, especially the ones that are accessible through a dock. I know about all these via acpi. However, we don't want to duplicate calling power methods through both cardbus and acpi, for instance. This tree doesn't exactly map to the devinfo tree: nexus0 npx0 acpi0 acpi_ec0 acpi_timer0 acpi_cpu0 acpi_tz0 acpi_lid0 acpi_button0 pcib0 pci0 hostb0 pcib1 pci1 pcib2 pci2 cbb0 cardbus0 pccard0 cbb1 cardbus1 pccard1 fxp0 miibus0 inphy0 isab0 isa0 pmtimer0 sc0 vga0 orm0 atapci0 ata0 ata1 ichsmb0 smbus0 pcm0 acpi_sysresource0 atpic0 attimer0 atdma0 npxisa0 attimer1 atkbdc0 atkbd0 psm0 psmcpnp0 fdc0 fd0 sio0 ppc0 ppbus0 plip0 lpt0 ppi0 sio1 acpi_cmbat0 acpi_cmbat1 acpi_acad0 Anyway, I'd love to hear how the ACPI AML and devinfo trees map to the fact that we need to call _PSx on all devices, eject uses _EJx, etc. -Nate