Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Dec 2003 11:11:54 -0500 (EST)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Nate Lawson <nate@root.org>
Cc:        "M. Warner Losh" <imp@bsdimp.com>
Subject:   Re: PERFORCE change 43464 for review
Message-ID:  <XFMail.20031210111154.jhb@FreeBSD.org>
In-Reply-To: <20031209222111.B44633@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On 10-Dec-2003 Nate Lawson wrote:
> 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.

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 <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20031210111154.jhb>