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

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Friday, May 16, 2014 06:11:30 PM Darren Vincent Hart wrote:
> On Thu, 2014-05-15 at 14:05 +0200, Rafael J. Wysocki wrote:
> > On Wednesday, May 14, 2014 02:04:01 PM Mark Brown wrote:
> > > 
> > > 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.
> > 
> > For things that are not covered by ACPI either directly or indirectly today,
> > that seems to be the only approach feasible in a reasonable time frame.
> > 
> > For things that are covered by ACPI that is less clear.  Even in that case,
> > though, if there's a binding (defined as a set of keys and value data types
> > associated with them) that a driver expects to be used, it makes a little
> > sense to create a second binding for it just for the purpose of using it with
> > a different firmware interface.
> > 
> > Rafael
> > 
> 
> As Mark has pointed out, there are many ways in which ACPI is used (and
> sometimes abused), and we agree that "all" ACPI users may not want to
> use something that looks like DT. This gives us the flexibility to do
> so, and solves a couple critical issies.
> 
> What we are starting to see is people developing with ACPI-based systems
> that need to use both 1) drivers with some kind of parameterization that
> isn't explicitly covered in the ACPI specification and 2) DT-aware
> platform drivers without ACPI support.
> 
> For 1, without any kind of clear guiding principles like a DT Binding,
> we are seeing lots of custom non-reusable implementations ranging from
> all kinds of _DSM implementations to named objects (ACPI pdata
> basically), all with driver-specific validation, parsing, formats, etc.
> 
> For 2, we tend to see more board files.
> 
> With a standardized mechanism in ACPI to provide property data, we can
> enhance ACPI-aware drivers while abstracting the parsing, validation,
> etc. into something that can be shared across the drivers. The idea
> being we reduce code duplication and the associated bugs and maintenance
> overhead that brings with it.

I obviously agree. :-)

Rafael