[Ksummit-2013-discuss] [ATTEND] ACPI vs DT

Rafael J. Wysocki rjw at sisk.pl
Tue Jul 23 22:19:52 UTC 2013


On Tuesday, July 23, 2013 12:44:36 AM Guenter Roeck wrote:
> On Tue, Jul 23, 2013 at 01:31:31AM +0200, Linus Walleij wrote:
> > On Mon, Jul 22, 2013 at 11:12 PM, Guenter Roeck <linux at roeck-us.net> wrote:
> > 
> > > Using ACPI does not work well for Super-IO chips - the chips are way too complex
> > > to handle with ACPI (or at least that is how it seems), and the available ACPI
> > > bindings are too limited. For example, a Super-IO chip may have dozens of
> > > registers to program sophistitaced fan control. If accessed through ACPI,
> > > all one can typically do is to turn a fan on or off.
> > 
> > I was more thinking along the lines of atleast defining the base address
> > or IO-port in the ACPI DSDT, not trying to abstract everything and its
> > dog. Isn't it possible to just have ACPI provide some basics?

There is a number of ways in which devices can be identified in the ACPI tables
(_HID, _CID, _UID, _ADR) and then _CRS (_PRS, _SRS) can be used to get
information about the device's resources.  Yes, the drvier needs to know
what _HID corresponds to what physical device, for example, but a PCI driver
also needs to know the device IDs of the devices it's going to handle.

> If ACPI reserves (and presumably uses) the IO space, the various drivers
> trying to use it typically just fail to load. No idea if there is a means
> to handle this better than today.

Well, what you means by "ACPI reserves" actually refers to the situation in
which there is an Operation Region defined for the given IO range.  That means
that the AML in the ACPI tables expects to be the owner of the given IO ranges.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


More information about the Ksummit-2013-discuss mailing list