ACPI

[Stefano Stabellini]

On Tue, 26 Nov 2013, Matthew Garrett wrote:
> On Tue, Nov 26, 2013 at 05:11:23PM -0600, Matt Sealey wrote:
> 
> > Before stabbing around adding ACPI and then having DT-in-ACPI isn't
> > there a use case for an an ARM Linux kernel actually being a good
> > citizen of UEFI?
> 
> That's work in progress. Patches have been posted and are getting pretty 
> close to being mergeable. You can already run VExpress with UEFI.
> 
> > Having UEFI pass along the DT as a configuration table as well as ACPI
> > tables should be the first order of business. It needn't be
> > DT-specific either - there's no reason that specific configuration
> > table can't define a thousand ways to boot Linux on ARM. But one or
> > two might be better for the sanity of the Linux kernel guys. In fact,
> > because UEFI hands information in the early boot process to the
> > 'application' (being the kernel), and has a very well defined API, it
> > would remove the need for weird out of band stuff like /memreserve/
> > entries in the DT and simplify and make the Linux early boot process
> > more robust and debuggable.
> 
> Passing both is somewhat problematic - if one is supposed to be 
> sufficient, why pass the other? It'd be pretty easy to end up with skew 
> between them, and unless we're clear on what happens in the event of 
> conflicting information then it's going to end badly.

Because I think that it is likely that we'll be able to convince them
that device tree is the right thing to do right now for Linux, Xen,
BSDes, etc.  However they might want to support ACPI in the future, if
nothing else to get other proprietary operating systems running.
So at some point one or more SoCs are going to come out with both.

In that case, I think that we should use the one we know has better
support in the kernel, that at the moment is device tree but in the
future might change.