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

[Darren Vincent Hart]

On Sun, 2014-05-04 at 10:18 -0700, Olof Johansson wrote:

...


> Intel, on the other hand, are already shipping this hardware, and have
> a platforms to do the work on (Minnowboard and Galieo, for example).
> 
> So, to address Arnd's original question: 
> 
> Yes, it could make more sense to translate the data to a common
> format and use the existing accessors for that data format, instead
> of reinventing the accessors and still needing to represent the data

In my opinion, the common dev_get_property() interface which calls the
appropriate firmware accessor function makes the most sense. Creating
another intermediate format which we then have to make into something
useful (like pdata) strikes me as unnecessary and likely limiting. 

> some way. I think it depends on how some of the other things develop --
> I don't know enough about what Darren's current approach is, for example,
> to tell if it would be easier to do it that way.

Right, so let me give a trivial example indicating what this looks like.

In ASL (DSDT that ships with the board, or an SSDT that we add after the
fact - another discussion on how to integrate that at boot time, table
that for now), under the Device objection, you have a named object (not
a method) that provides a Package in a known format, something like:

Package () {
  Package (2) { "label", "foo" },
  Package (2) { "value", 1}
  Package (2) { "devs_indices", Package { _SB.DEV1, 1, _SB.DEV2, 0 }
}

NOTE: I've pared off some implementation detail above just to focus on
what's relevant to this discussion. We're in a mad rush right now
between working group meetings, writing documentation to explain all
this, and discussing things here while we have people's attention. All
important, all time sensitive. I apologize for not just having a
complete wiki page to point everyone to - but we'll have something a lot
more concrete *very* shortly.

When the platform driver discovers pdata is NULL and that there is
firmware to be probed (dev exists), it starts populating a pdata
structure with calls like:

pdata.label = dev_get_property_string("label");

This would go through ACPICA to get the property on this device, but
could also go through OF on a different system, without any change to
the driver.


> 
> Also, even if we do a common API with different backends, there will
> need to be some knowledge somewhere about custom bindings and what they mean,
> how to translate them and how the different descriptions correlate.


Of course there will be exceptions in the way certain things are
represented in each firmware type, but we already have accessors per
firmware type, so we have the groundwork to deal with those via
specific-property-type accessors.

> I personally think we're best off putting that in the drivers, instead of
> making some part of the driver core aware of a bunch of quirks/hooks for
> various devices.

Hrm, I was hoping to see it in the properties core (driver core I guess)
so we didn't have to see every driver. I suppose  we could approach this
like we do subsystems in general. If we see something repeated enough,
we abstract it and move it down a level :-)

For example, DT and ACPI handle device references differently - but that
isn't a quirky device-specific kind of thing, it's a firmware
representation thing, and that should be abstracted away from the driver
IMO.

GPIO is another example (which is actually dependent on the phandle/ACPI
namespace difference).

Thanks,

-- 
Darren