On Mon, 2015-10-19 at 16:43 +0100, Russell King - ARM Linux wrote:

On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:

quoted

I don't know that there *is* a coherent plan here to address it
all.

Certainly, we *will* need subsystems to have firmware-specific
knowledge in some cases. Take GPIO as an example; ACPI *has* a way
to
describe GPIO, and properties which reference GPIO pins are
intended to
work through that — while in DT, properties which reference GPIO
pins
will have different contents. They'll be compatible at the driver
level, in the sense that there's a call to get a given GPIO given
the
property name, but the subsystems *will* be doing different things
behind the scenes.

It's a bit ironic that you've chosen GPIO as an example there.  The
"new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
gpio descriptor.  There's no of_* method.

I think that part is already being worked on, but...

If ACPI already handles GPIOs internally, then I'm left wondering
why GPIO descriptor stuff went down the fwnode route at all - it
seems rather pointless in this case, 

ACPI already had a way for a given device to say that it uses certain
other GPIOs. But until we had device properties in ACPI, it could say
*what* it used them for. So sure, we could say that we used GPIO#15
from <this> controller and GPIOs #27 and #31 from <that> controller.
But there was no way to say that the former was the shotdown pin and
the latter was the reset pin.

While a GPIO property in DT will contain a phandle and basically be a
complete reference to find the pin you're after, the same property
represented in ACPI will just be an index into the resources that ACPI
could already refer to.

So referring to the example in Documentation/acpi/gpio-properties.txt:

      Name (_CRS, ResourceTemplate ()
      {
          GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                  "\\_SB.GPO0", 0, ResourceConsumer) {15}
          GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                  "\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
      })

That part, ACPI already had. But..

      Name (_DSD, Package ()
      {
          ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
          Package ()
          {
              Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
              Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
          }
      })

...this part is new, and allows us the full flexibility of device
properties. And the appropriate gpiod_get* function is supposed to
transparently work on either DT or ACPI.


-- 
dwmw2