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

[Darren Vincent Hart <darren@dvhart.com>]

On Thu, 2014-05-08 at 13:27 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2014-05-07 at 12:05 +0100, David Woodhouse wrote:
> > On Mon, 2014-05-05 at 18:39 +1000, Benjamin Herrenschmidt wrote:
> > > 
> > > The other option is to have both the DT representation and the ACPI
> > > representation reach the drivers and leave it to the them (the drivers) to get
> > > through two different functions at probe time to "translates" that into a
> > > "3rd" driver private one (a structure, in a way akin to the old platform data
> > > but of course completely local to the driver scope).
> > 
> > I don't like that much. For "leaf-node" device drivers, I think we're
> > better off with a simple set of "device_get_property" functions which
> > are a little more type-safe than the existing of_* ones, thus helping us
> > to deal with the details of 32-bit cells vs. ACPI integers, etc.
> 
> Fair enough. I was mostly putting all options on the table. It is still
> not completely clear on my mind how we'll get the properties from ACPI
> (via that new scheme Darren's working on ?) and how good we'll manage to
> keep the bindings in sync sufficiently to avoid a bunch of:
> 
> 	if (OF)
> 		get_property("foo"...)
> 	else
> 		get_property("bar"...)
> 
> Because of subtle differences in property names, format, content, etc...
> 

Right, we have to avoid this. I'd rather see:

get_of_pdata() and get_acpi_pdata() than a slew of if/else blocks
implementing slightly skewed schemas.


> It might end up working out ... but it's going to be a constant battle
> at least initially.
> 

For the of-capable platform devices we have today, the above doesn't
even become an option. We switch to the new API dev_get_property("foo")
and people wanting to use these drivers with ACPI WILL use that schema.
I'm talking with a few of these folks a lot lately, and they absolutely
do not want to have to special case / rewrite all these drivers. All
they will have to do is add the DEVICE and Package() to the ASL and the
driver works. So it is in their best interest NOT to fragment the
schema. 

> I'm mostly concerned here about device specific random attributes. I

Right, and this the area we're focused on with the new ACPI properties
mechanism. If ACPI already provides a specific object type, like for
GPIO, we continue to use that.

> think we all agree that the "common" stuff such as memory and irq is
> going to be translated by the core into Linux native representation.
> 
> Of course there is going to be a pile of work defining the right
> representation & translation for some of that "common" stuff in areas
> like clocks, gpios, etc...

Nodding... :-)


-- 
Darren