On Tue, May 13, 2014 at 03:08:29PM +0200, Arnd Bergmann wrote:
> On Tuesday 13 May 2014 13:11:48 Mark Brown wrote:

> > There's also the possibility that the driver is going to have to figure
> > out at runtime if it's on a system with active ACPI or a system with
> > passsive ACPI, though I expect we can just do something like check what
> > properties are there for that assuming people don't end up doing
> > mix'n'match type things.  People are interested in ACPI for embedded
> > cases outside of x86 to a large extent so that they don't have to deal
> > with two different firmware interfaces if they also work on the server
> > cases.

> To be clear, I was only talking about embedded x86 above, there is
> no reason to introduce ACPI on any new architecture really.

> While we will likely get ACPI on ARM64 in the future, I definitely don't
> want to have two incompatible ACPI implementations, especially for the
> same chip. While AMD recently announced they are also going after
> embedded markets with their ARM64 products, they should either
> just use DT in that case, or they should use the same firmware they
> have on their servers.

I'd heard mutterings like that from elsewhere (I don't know anything
about AMD's thoughts), and of course there's nothing stopping ARM people
just picking up the out of tree ACPI stuff and using that if they decide
they want to work that way.

In any case that was more a comment about it being an area of broader
interest than just some future Intel stuff - my main concern is that
we've already got upstream embedded ACPI stuff for x86 which doesn't
look *particularly* like what we do for DT but more like what seems
idiomatic for ACPI (some of the Haswell and Baytrail laptops have
embedded style audio subsystems) and as far as I am aware those systems
are in the active ACPI model rather than a passive ACPI model.