cvs commit: src/sys/dev/acpica acpi_if.m

Nate Lawson nate at root.org
Tue Dec 7 22:42:00 PST 2004


John Baldwin wrote:
> On Thursday 02 December 2004 03:04 am, Nate Lawson wrote:
>>
>>  Modified files:
>>    sys/dev/acpica       acpi_if.m
>>  Log:
>>  Add the ACPI_PWR_FOR_SLEEP method.  It takes a device and outputs the
>>  appropriate power (Dx) state, if the BIOS suggests one.
> 
> Should this really be ACPI specific?  Why not add a method that pci bridges 
> pass to their parent that will bubble up to the host-pci bridge's parent 
> (acpi0, legacy0, etc.) that determines which sleep state should be used?  
> This would let open firmware machines manage this stuff in their nexus0 for 
> example if they wanted.  It would be a pci bus method that the platform 
> drivers would implement as well in that model, and wouldn't be ACPI specific.

It's a good discussion to have.  In this case, I think it should be 
"ACPI_PWR_FOR_SLEEP" since there is no other mechanism I know for 
getting a Sx to Dx mapping (sleep state to device power state).  The 
method is not acpi specific anyway.  It just takes a device_t and 
outputs an integer.  Machines with openfirmware could implement the same 
method as long as the implementation could conform to these semantics 
and interface.

We have this issue elsewhere in that ACPI is not a PCI bus but it 
implements the PCI_SET_POWERSTATE method.  This is ok though since the 
method has PCI semantics even though the ACPI legacy bus (i.e., ISA) is 
not PCI in other ways.  We could call this POWER_SET_STATE to be more 
generic, but then if there was another set of semantics for some other 
system, we'd have a namespace collision.  I prefer method names to 
conform to the interface, as in "operates the same as PCI power state 
setting".

A completely separate problem is the fact that acpi_if.m has lots of 
ACPI-specific types as parameters.  To clean it up, I plan to 
forward-declare the ACPI types so this file can be self-contained and 
included without prerequisites.

-- 
Nate


More information about the cvs-src mailing list