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

From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [PATCH v2 13/39] acpi: Add a binding for ACPI settings in the device tree
Date: Thu, 12 Mar 2020 18:36:06 -0600	[thread overview]
Message-ID: <CAPnjgZ2uscUOo7KkRJd6=YLiFJo-XFDQjStOCVU453FQnzdQsQ@mail.gmail.com> (raw)
In-Reply-To: <OF3E09D291.846E0B74-ONC1258529.00367812-C1258529.0045F390@br-automation.com>

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

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

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

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