Hi Wolfgang,
On Thu, 12 Mar 2020 at 06:44, Wolfgang Wallner wolfgang.wallner@br-automation.com wrote:
Hi Simon,
-----"Simon Glass" sjg@chromium.org schrieb: -----
[snip]
- properties provided by this binding, to describe how to handle powering the
- device up and down using GPIOs
- acpi,compatible : compatible string to report
What does "compatible string" mean in this context? Does it refer to the "Compatible ID" (_CID) of ACPI? As stated in the previous mail thread [1], I think we could infer many of the ACPI properties from existing device tree properties. Especially I suspect that ACPI's _CID could have a 1:1 mapping to the compatible property in device tree. E.g. a driver which states that it is compatible with "hid-over-i2c" in its device tree description would know (implement internally) that it is also compatible with ACPI's _CID "PNP0C50", thus we would not have to add this information in the device tree.
This is described to in the Linux binding file:
Documentation/acpi/enumeration.txt
The special DT namespace link device ID, PRP0001, provides a means to use the existing DT-compatible device identification in ACPI and to satisfy the above requirements following from the ACPI specification at the same time. Namely, if PRP0001 is returned by _HID, the ACPI subsystem will look for the "compatible" property in the device object's _DSD and will use the value of that property to identify the corresponding device in analogy with the original DT device identification algorithm. If the "compatible" property is not present or its value is not valid, the device will not be enumerated by the ACPI subsystem. Otherwise, it will be enumerated automatically as a platform device (except when an I2C or SPI link from the device to its parent is present, in which case the ACPI core will leave the device enumeration to the parent's driver) and the identification strings from the "compatible" property value will be used to find a driver for the device along with the device IDs listed by _CID (if present).
So we set acpi,hid to "PRP0001" and acpi,compatible to the device-tree compatible string.
I think there are different cases that can be distinguished in which we need to translate between ACPI and device tree.
- The OS has an existing ACPI binding for the device. U-Boot uses device tree for device description, but the OS uses ACPI (e.g. Linux on x86). We need a way to tell U-Boot how to create the appropriate ACPI descriptons.
For now I'd like to do this in the U-Boot driver. We have so few drivers doing it that I don't think we can generalise this yet. If we start to see a pattern then we might start with some common code...
- There is no existing ACPI binding for the device in the OS, but there is already an existing device tree binding. As stated in the Linux documentation you have referred to, it would not make sense to introduce a new ACPI binding that would just be the same as the existing device tree one. As I understand this is what the "PRP0001" tag was introduced for (to reuse existing device tree descriptions and save redundant work).
Handling case 2: PRP0001 allows to wire existing device tree properties into ACPI descriptions, and I think it provides a solution for most of case 2. So for case 2 I think most of the ACPI description can be autogenerated:
Set _HID to "PRP0001"
Pack all existing device tree properties into the ACPI _DSD method (this also implies that no additional "acpi,compatible" property is required, as we can reuse the existing "compatible" property)
I say "most of" because I don't know how to map certain parts between device tree and ACPI, e.g. interrupt descriptions.
...and perhaps end up with something like this. But I really don't feel comfortable trying to build out something like this with so few use cases. We don't even have one* in coral yet.
Handling case 1: Case 1 is more tricky, and up to now I was assuming you are targeting case 1 with the new additional properties. It might not be as straigt forward as in case 2, but I think also in this case we can infer most of the ACPI properties from the existing device tree properties without adding new ones. This is the example from the previous mail discussions where e.g. from a device tree "compatible" property "hid-over-i2c" we could infer the ACPI _HID "PNP0C50" without adding new properties in the device tree.
Again, I have left out more complex things like interrupts in this description.
Anyway, my experience with both device tree as well as ACPI is limited, so please take all my statements with a grain of salt.
I suspect they may be some things we can do here to automate this. But again, this is for the future when we actually start to see these cases.
I have done the hid-over-i2c compatible string (automatically setting CID to PNP0C50) as we have two coral drivers that do that.
Regards, Simon