Date: Tue, 9 Dec 2003 22:31:30 -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: <20031209222111.B44633@root.org> In-Reply-To: <20031209.185859.00003429.imp@bsdimp.com> References: <20031208.175500.36934037.imp@bsdimp.com> <XFMail.20031209134426.jhb@FreeBSD.org> <20031209.185859.00003429.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ????
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031209222111.B44633>