Antwort: Re: [PATCH 013/108] acpi: Add a binding for ACPI settings in the device tree
wolfgang.wallner at br-automation.com
Mon Feb 3 10:52:55 CET 2020
> -----"Simon Glass" <sjg at chromium.org> schrieb: -----
> Hi Wolfgang,
> On Fri, 31 Jan 2020 at 01:18, Wolfgang Wallner
> <wolfgang.wallner at br-automation.com> wrote:
> > Hi Simon,
> > > +Devices
> > > +=======
> > > +
> > > +Device bindings are described by their own individual binding files.
> > > +
> > > +U-Boot provides for some optional properties which are documented here.
> > > +
> > > + - acpi,has-power-resource : (boolean) true if this device has a power resource.
> > > + This causes a PRIC (ACPI PowerResource) to be written containing the
> > > + properties provided by this binding, to describe how to handle powering the
> > > + device up and down using GPIOs
> > > + - acpi,cid : Contains the string to use as the compatible ID (_CID)
> > > + - acpi,compatible : compatible string to report
> > > + - acpi,desc : Contains the string to use as the _DDN (DOS (Disk Operating
> > > + System) Device Name)
> > > + - acpi,hid : Contains the string to use as the HID (Human Interface Device)
> > > + identifier _HID
> > Nit: "_HID" in ACPI stands for "Hardware ID"
> OK thank you, will fix. I am trying to write things out in full since
> it is very hard to find out what all these different things mean.
I appreciate that, it makes it easier for to follow the text.
> > > + - acpi,hid-desc-reg-offset : HID register offset (for Human Interface Devices)
> > > + - acpi,probed : Tells U-Boot to add 'linux,probed' to the ACPI tables so that
> > > + Linux will not re-init the device
> > > + - acpi,uid : _UID value for device
> > Would it make sense to automatically infer ACPI properties from existing
> > device tree properties?
> > E.g. if the compatible string contains "hid-over-i2c", then _CID could be set
> > to "PNP0C50".
> Yes we could do that. So is that true for all devices that use this i2c driver?
As far as I understand the ids "PNP0C50" and "hid-over-i2c" serve the same
purpose, just in two different description languages.
Devicetree: If an I2C over HID device is described in Devicetree, it should
have a compatible string of "hid-over-i2c" (see  for details).
ACPI: If an I2C over HID device is described in ACPI, it should have a
_CID of "PNP0C50" (See  for details).
As both identifiers are standardized, I think we could infer one from the
I'm not sure whether inferring ACPI-properties from Devicetree properties is
worth it, but I wanted to bring up the idea for discussion as adding new
properties for someting where we already have something similar feels
> > And a "hid-over-i2c" device would also have a "hid-descr-addr" device tree
> > property for the offset of the HID descriptor register which could be passed
> > on in ACPI as part of the _DSM method.
> Are you suggesting renaming acpi,hid-desc-reg-offset to hid-descr-addr?
An ACPI "PNP0C50"-device has a _DSM (Device Specific Method) which provides the
HID descriptor offset (for UUID "3CDFF6F7-4267-4555-AD05-B30A3D8938DE").
A Devicetree "hid-over-i2c"-device has a property "hid-descr-addr" which
provides the HID descriptor offset.
So instead of adding a new "acpi,hid-desc-reg-offset" I think we could also
use the existing "hid-descr-addr" property.
Interrupts are another topic that need to be described in both worlds:
ACPI: "_CRS"-method (Current Resource Settings)
Maybe we could also infer that description too?
More information about the U-Boot