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:
> > 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
