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

[Olof Johansson <olof@lixom.net>]

Hi,

[BTW, I forgot to mention that BenH of course would be one person we need
involved in all this. Adding him to the cc list here, but I know he's seen the
thread already :)]

On Sun, May 04, 2014 at 12:14:36PM +0100, Catalin Marinas wrote:
> On Sat, May 03, 2014 at 04:14:51PM +0100, Arnd Bergmann wrote:
> > On Saturday 03 May 2014 02:05:21 Rafael J. Wysocki wrote:
> > > On Friday, May 02, 2014 02:42:07 PM Olof Johansson wrote:
> > > > * Converting either of them to use platform device model
> > > > (platform_data) to register drivers, and leave them unaware of either
> > > > hardware description
> > > > * [... I'm likely missing something here as well]
> > 
> > Olof, funny you missed the proposal you made yourself:
> > 
> >  * convert ACPI data into DT format at boot time
> 
> I thought this was discussed at length and agreed it's not a way
> forward, given the differences between ACPI and DT, especially on the
> AML feature which DT does not have (making one-off boot-time conversion
> not feasible).

I'm explicitly choosing to not discuss the ARM64 situation here myself,
I am more interested in solving the issues around Intel's forage into
embedded.

ACPI on ARM64/SBSA is in many ways a different problem, and one that
I don't know what there is to talk about, to be honest. Mostly because
we're still talking hypotheticals and not-yet-published docs, and all
vendors are still under deep NDA on product plans and what they're
planning on doing. It means we're playing games of telephone right now
and it's better to just wait until we have something concrete to center
the discussions around.

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
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.

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.
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.

> > > For what it's worth, we are working on extending ACPI to allow DT-style
> > > information to be included into ACPI tables.
> > 
> > I think it's important to understand that we have people coming from
> > two sides here: Intel x86 embedded systems with ACPI wanting to the
> > same things we do on embbeded PowerPC and ARM systems with DT, and ARM64
> > servers trying to do the same things that x86 servers do by moving
> > to ACPI.
> > 
> > These two have very different requirements and while there is some
> > overlap, I suspect we will end up with different solutions as well.
> 
> I think the middle ground is that for x86 to get into embedded and ARM64
> into servers, the ACPI spec is not enough as hardware description.
> Traditionally, the x86 hardware is rather standard and ACPI didn't need
> to describe so many things. On ARM, OTOH, we have lots of variation and
> DT provides such flexibility. Even if ARM is pushing for more standard
> server hardware like SBSA, it's still relaxed enough not to look like a
> PC platform. So even if the aims are different, the x86 efforts on more
> hw description in ACPI help both Intel and ARM. Given the collaboration
> between the two on ACPI forums already, I think there are good chances
> of ending up with a common solution for Linux. Of course, x86 may decide
> to go the DT route all the way (and ARM in the other direction ;)).

I think it's very optimistic to assume that there will ever be a common
solution for both ends of the spectrum (embedded - enterprise), but we
should make sure we can stay sane and not have more solutions than we need
in parallel, and that things will work together where there is overlap.


-Olof