Antwort: Re: [PATCH v2 13/39] acpi: Add a binding for ACPI settings in the device tree

From: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
To: u-boot@lists.denx.de
Subject: Antwort: Re: [PATCH v2 13/39] acpi: Add a binding for ACPI settings in the device tree
Date: Thu, 12 Mar 2020 13:44:03 +0100	[thread overview]
Message-ID: <OF3E09D291.846E0B74-ONC1258529.00367812-C1258529.0045F390@br-automation.com> (raw)
In-Reply-To: <CAPnjgZ3K78oEhcX6hsdFtOMi9QSy8HxKokA6fyXrDathEVsxZA@mail.gmail.com>

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.

1) 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.

2) 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.    

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.

regards, Wolfgang