On Thu Aug 27 04:34, Rafael J. Wysocki wrote:
Hi Rafael,
> The issue at hand is that we need to be able to support hierarchical device
> properties in ACPI, like when the set of properties of an entity called "Fred"
> may include a subset called "dog" containing the properties of the Fred's dog
> rather than those of Fred himself. And it may make sense to have the same
> property, like "hair color", for both Fred and the dog, but with different
> values.
OK. I have a couple of questions.
> We (I, Darren and Dave at least) have explored many possible ways to deal with
> that in ACPI, but the majority of them turned out to be unattractive for various
> reasons. Our first take was to use ACPI device objects to make the "child"
> property sets available via _DSD, but that approach is generally incompatible
> with the PnP Manager in Windows following the notion that all device objects
> in ACPI tables are supposed to represent real devices. It can still be made
> work by adding _STA that returns 0 to those "property-only" device objects,
> but that leads to complications in other places and is error prone (if the _STA
> is forgotten, for example). Moreover, it adds quite a bit of overhead even in
> Linux (an ACPICA representation, struct acpi_device, driver core mechanics etc)
> for things that are only supposed to represent sets of device properties. And,
> in addition to that, we'd need to figure out how to give those things arbitrary
> names in a consistent way. All of that caused us to drop the approach based on
> device objects and look for other options.
What's the overhead/effect on Windows for an ACPI object without a _HID (_ADR
only)? That seems like a case where the OS shouldn't be expecting to load
another driver for the ACPI object and the _ADR gives each node a unique name
(even if it is an unfriendly integer)
> The idea is that _DSD may return a package containing the properties of the
> device it belongs to along with a directory of objects that need to be evaluated
> in order to obtain the "child" property sets of it. That directory needs to be
> present in a separate section of the _DSD package (after the new UUID defined in
> the above document) and is a list of two-element sub-packages (entries) where
> the first element is the name of the entry (the name of the "child" property set
> represented by it) and the second element is a "pointer" (essentially, a path
> or "namestring" in the ACPI terminology) to the control method or a static
> data package that needs to be evaluated to obtain the entry's data. The data
> returned by it is then interpreted in the same way as a _DSD return package,
> so it may also contain properties and a directory of its own "child" property
> sets.
Do you expect there to be cases where using an ACPI device object is more
desirable than hierarchical properties? Or is it just impossible given the PNP
manager in Windows?
The best example I can think of is perhaps a multi function device where each
sub-function really does look like a separate device and you probably want to
reference that sub-device, as a device, in other ASL code.
Stating the above more generally, by taking this approach you loose the ability
to reference these child nodes as a device object. In this LED example, I
think it would be nice to set the "trigger" for the led by adding a reference
to the LED from another device (such as a NIC).
Device (NIC0)
{
...
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"activity-led", LEDS.LEDM },
Package () {"link-led", LEDS.LEDH },
},
}
}
I'm not sure that's even supported in devicetree or LEDs are the best example
of this, but the pattern seems generally useful.
Without a device you're also forced to use a "label" property instead of a
_STR.
> As an example, consider the following ASL from an experimental MinnowBoard
> firmware:
>
> Device (LEDS)
> {
> Name (_HID, "PRP0001")
>
> Name (_CRS, ResourceTemplate () {
> GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
> "\\_SB.PCI0.LPC", 0, ResourceConsumer) {10}
> GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
> "\\_SB.PCI0.LPC", 0, ResourceConsumer) {11}
> })
>
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"compatible", Package () {"gpio-leds"}},
> },
> // Data extension
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () {
> Package () {"heartbeat", "LEDH"},
> Package () {"mmc-activity", "LEDM"},
I guess LEDH and LEDM have to be strings here. It would be nice if the
compiler could verify the path resolves. I suppose it's more incentive to keep
these in the same scope.
> Name (LEDH, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"label", "Heartbeat"},
> Package () {"gpios", Package () {^LEDS, 0, 0, 0}},
> Package () {"linux,default-trigger", "heartbeat"},
> Package () {"linux,default-state", "off"},
> Package () {"linux,retain-state-suspended", 1},
> }
> })
>
> Name (LEDM, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"label", Package () {"MMC0 Activity"}},
> Package () {"gpios", Package () {^LEDS, 1, 0, 0}},
> Package () {"linux,default-trigger", Package () {"mmc0"}},
> Package () {"linux,default-state", "off"},
> Package () {"linux,retain-state-suspended", 1},
> }
> })
> }
I suspect you've thought of all of this. Thanks in advance for any
explanations.
--Dustin
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
