On Tuesday, November 04, 2014 02:48:40 PM Grant Likely wrote:
> On Mon, Nov 3, 2014 at 9:52 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
> > On Monday, November 03, 2014 04:25:08 PM Rafael J. Wysocki wrote:
> >> On Sunday, November 02, 2014 08:49:37 PM Darren Hart wrote:
> >> >
> >> > On 11/1/14 4:11, Grant Likely wrote:
> >> > > On Tue, 28 Oct 2014 22:59:57 +0100
> >> > > , "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
> >> > > wrote:
> >> > >> On Tuesday, October 28, 2014 01:15:27 PM Mika Westerberg wrote:
> >> > >>> acpi_dev_add_driver_gpios() makes it possible to set up mapping between
> >> > >>> properties and ACPI GpioIo resources in a driver, so we can take index
> >> > >>> parameter in acpi_find_gpio() into use with _DSD device properties now.
> >> > >>>
> >> > >>> This index can be used to select a GPIO from a property with multiple
> >> > >>> GPIOs:
> >> > >>>
> >> > >>> Package () {
> >> > >>> "data-gpios",
> >> > >>> Package () {
> >> > >>> \_SB.GPIO, 0, 0, 0,
> >> > >>> \_SB.GPIO, 1, 0, 0,
> >> > >>> \_SB.GPIO, 2, 0, 1,
> >> > >>> }
> >> > >>> }
> >> > >>>
> >> > >>> In order to retrieve the last GPIO from a driver we can simply do:
> >> > >>>
> >> > >>> desc = devm_gpiod_get_index(dev, "data", 2);
> >> > >>>
> >> > >>> and so on.
> >> > >>>
> >> > >>> Signed-off-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
> >> > >>
> >> > >> Cool. :-)
> >> > >>
> >> > >> Any objections anyone?
> >> > >
> >> > > Actually, I do. Not in the idea, but in the implementation. The way this gets encoded:
> >> > >
> >> > > Package () {
> >> > > \_SB.GPIO, 0, 0, 0,
> >> > > \_SB.GPIO, 1, 0, 0,
> >> > > \_SB.GPIO, 2, 0, 1,
> >> > > }
> >> > >
> >> > > Means that decoding each GPIO tuple requires the length of a tuple to be
> >> > > fixed, or to implement a DT-like #gpio-cells. If it is fixed, then there
> >> > > is no way to expand the binding later. Can this be done in the following
> >> > > way instead?
> >> > >
> >> > > Package () {
> >> > > Package () { \_SB.GPIO, 0, 0, 0 },
> >> > > Package () { \_SB.GPIO, 1, 0, 0 },
> >> > > Package () { \_SB.GPIO, 2, 0, 1 },
> >> > > }
> >> > >
> >> > > This is one of the biggest pains in device tree. We don't have any way
> >> > > to group tuples so it requires looking up stuff across the tree to
> >> > > figure out how to parse each multi-item property.
> >> > >
> >> > > I know that last year we talked about how bios vendors would get
> >> > > complicated properties wrong, but I think there is little risk in this
> >> > > case. If the property is encoded wrong, the driver simply won't work and
> >> > > it is unlikely to get shipped before being fixed.
> >> >
> >> > This particular nesting of Packages is expressly prohibited by the
> >> > Device Properties UUID for the reasons you mention.
> >> >
> >> > http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
> >>
> >> Also we don't use properties where single name is assigned to multiple GPIOs
> >> anywhere in the current device-properties patchset, so this is not relevant at
> >> the moment.
> >>
> >> Moreover, even if we were to use them, we would need to ensure that this:
> >>
> >> Package () {
> >> \_SB.GPIO, 0, 0, 0
> >> }
> >>
> >> was equivalent to
> >>
> >> Package () {
> >> Package () { \_SB.GPIO, 0, 0, 0 }
> >> }
> >>
> >> This is not impossible to do and I suppose we could even explain that in the
> >> implementation guide document in a sensible way, but that would require the
> >> document linked above to be changed first and *then* we can think about writing
> >> kernel code to it. Not the other way around, please.
> >>
> >> So Grant, do you want us to proceed with that?
> >
> > Before you reply, one more observation that seems to be relevant.
> >
> > In ACPI, both this:
> >
> > Package () {
> > \_SB.GPIO, 0, 0, 0,
> > \_SB.GPIO, 1, 0, 0,
> > \_SB.GPIO, 2, 0, 1,
> > }
> >
> > and this:
> >
> > Package () {
> > Package () { \_SB.GPIO, 0, 0, 0 },
> > Package () { \_SB.GPIO, 1, 0, 0 },
> > Package () { \_SB.GPIO, 2, 0, 1 },
> > }
> >
> > carry the same information, because every element of a package has a type,
> > so there is no danger of confusing an ACPI_TYPE_LOCAL_REFERENCE with
> > ACPI_TYPE_INTEGER. Thus one can easily count the number of GPIOs represented
> > by the first package by counting the number of reference elements in it.
> > The second one has more structure which in this particular case is arguably
> > redundant.
>
> Okay, this make sense. I'm okay with this approach, and I would
> recommend making that the only valid method for parsing in
> acpi_dev_get_property_reference(). Get rid of the *size_prop argument
> so that it always behaves the same way and users aren't tempted to do
> something clever.
OK, I'll send a followup patch to remove the size_prop arg from
acpi_dev_get_property_reference().
> > Of course, that's not the case for list properties where each item consists
> > of a bunch of integers, like
> >
> > Package () {
> > Package () { 0, 0, 0 },
> > Package () { 1, 0, 0 },
> > Package () { 2, 0, 1 },
> > }
> >
> > but I'm not sure if this is relevant at all.
>
> Probably not. With a pure list it isn't implicitly referencing data in
> another node. In the ref+args pattern the length of each tuple can
> vary based on which node it references, but on a simple list the
> parsing is going to be a lot simpler.
OK
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
