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