ACPI

[Grant Likely]

On Tue, 26 Nov 2013 18:33:44 +0000, Matthew Garrett <mjg59 at srcf.ucam.org> wrote:
> On Tue, Nov 26, 2013 at 12:55:10PM +0000, Grant Likely wrote:
> > On Tue, Nov 26, 2013 at 12:43 PM, Linus Walleij
> > <linus.walleij at linaro.org> wrote:
> > > I have a feeling we should not recommend ARM implementers
> > > to go and do things like this.
> > 
> > ACPI5 defines a binding for serial busses (i2c & spi) which allows
> > real device drivers to drive the bus and allows ACPI and the kernel to
> > share the bus safely. Using that binding means some i2c devices can be
> > 'owned' by ACPI and others owned by the kernel.
> 
> Right, we shouldn't see a problem in this specific case. But it does 
> leave a wider philosophical concern - there are still components that 
> can't be exposed to the OS via ACPI in standardised ways, and the 
> traditional way of dealing with that on x86 is to just add the 
> functionality via ASL. It seems that we have three basic options:
> 
> 1) Encourage vendors to add functionality to their DSDTs
> 2) Encourage vendors to use existing kernel functionality, exposing 
> information via either DT-in-ACPI or some other custom method
> 3) Encourage vendors to continue using DT until this functionality is 
> standardised

I think pushing for #3 is the correct thing to do right now. Even if the
core ACPI support were to get merged in the next merge window, it is
going to take time to work out best practices. Exactly how much of the
topology should be exposed in ACPI is a big question. Having real ARM
server machines commercially available will be important anyway to
actually figure out what ARM ACPI should look like.

g.