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

[Mark Brown]

On Tue, May 13, 2014 at 11:19:00PM +0200, Rafael J. Wysocki wrote:

> Of course, ACPI "support" can be shoehorned into a limited number of things
> this way, but it really doesn't scale and very often the result is really
> disgusting.  Also ACPI in its current form may not even be able to provide
> information expected by device drivers in the first place, because ACPI
> doesn't have means to encode that information in any sensible way today
> (that includes clocks, voltage regulators, PWMs, pin control and even GPIOs
> to some extent).

> If ACPI is extended so that such information can be put into the tables,
> there is no reason why the interface for extracting it should be much different
> from the of_ one, except that instead of calling of_get_something(device_node, ...)
> drivers will call fw_get_something(device, ...).  And that can use the old good
> of_ for systems with DT, so it really is a matter of getting the ACPI side of
> things to match it.

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.

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.

> And if you're asking why things are currently done in different ways, the
> reason is simple: ACPI has not been extended yet and the fw_get_something(device, ...)
> interface doesn't exist, so people have to use what is available today and there are
> products to support in the meatime.

Not really, the issue is more about the model and applies just as much
to things like device specific properties as it does to resource lookup
(to be honest resource lookup is the easiest thing here - it's not a
relevant issue with the in tree stuff).

Active ACPI systems have the idea that the firmware is going to go and
interact with the hardware directly itself, one of the goals being to
allow the hardware to be extended in ways that the OS would otherwise
need to be modified to support.  In contrast FDT and the new passive
ACPI model you are describing just provide data and leave everything up
to the OS in terms of interacting with the hardware.  What's tasteful
and what system integrators expect to work with both seem to vary
between the two - one of the most common I'm seeing is that with active
firmware configuration written into the device on startup may actually
be real and worth paying attention to while with passive firmware it's
usually best to ignore the device state.

Some of what's going on is limitations in current ACPI and it does make
sense to address those in as generic a fashion as possible but it isn't
clear to me that all ACPI users want to have something that looks like
DT.
-------------- 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/20140514/a30ac519/attachment.sig>