[PATCH v2 13/39] acpi: Add a binding for ACPI settings in the device tree
sjg at chromium.org
Fri Mar 13 01:36:06 CET 2020
On Thu, 12 Mar 2020 at 06:44, Wolfgang Wallner
<wolfgang.wallner at br-automation.com> wrote:
> Hi Simon,
> -----"Simon Glass" <sjg at chromium.org> schrieb: -----
> > > > + 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 ,
> > > 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
I have done the hid-over-i2c compatible string (automatically setting
CID to PNP0C50) as we have two coral drivers that do that.
More information about the U-Boot