[Ksummit-discuss] [TECH TOPIC] Driver model/resources, ACPI, DT, etc (sigh)

[Mark Brown]

On Thu, May 15, 2014 at 02:05:43PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, May 14, 2014 02:04:01 PM Mark Brown wrote:

> > Of course, and for all of these things other than GPIOs we already
> > handle the lookups without any DT code at all in the drivers (and GPIOs
> > are moving away from needing explicit code too).  Things like that just
> > aren't an issue and I'd say that if we are adding new fw_ interfaces for
> > resource lookup like you describe we're doing things wrong, we already
> > have the idiom of looking up by device and some key which works well.

> The "key" think doesn't really work in ACPI if it is a string, however.

> That's a real problem, because, for example, ACPI says "I have these GPIO
> connections between your device and controller X" and it gives you pin
> numbers.  Now the driver (or someone else) needs to figure out which pin
> is used for what.

> If there's only one pin per device, all is fine, but if there are more of
> them things get very ugly quite quickly.

> So in "native" ACPI something like gpiod_get() cannot really be implemented
> to use con_id and if you look at acpi_find_gpio() (the one in gpiolib.c),
> you'll see that it actually only uses the index for this very reason.

Surely all we need to do for these cases is provide a way for drivers to
supply the name to number mappings for usage with ACPI (probably with
per device and per board overrides possible due to all the failures
usually associated with numbers)?  That's much less invasive than making
new APIs.

> > It gets more interesting with compound devices like multimedia; there's
> > not really a clear general model for handling these in kernel in the
> > first place plus also some ongoing discussion about how they are best
> > represented in DT.  Those might well fall into the too hard to handle
> > generically category though.

> Well, that's hard to say wihtout looking at specific examples.

> If something proves too hard to be addressed in a common fashion, which is
> not unlikely, we'll need to find some other way to address it, but as long
> as we *can* do things in common ways, we should do that in my opinion.

That does make sense.  The complex examples I thinking of are things
like Documentation/devicetree/bindings/sound/simple-card.txt and the
more complex versions of such subsystems.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20140517/1afb8e4c/attachment.sig>