ACPI

[Matthew Garrett]

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

Being consistent about our recommendations here would probably be 
helpful, but it seems like we don't have any kind of thought out story 
yet. That seems like a problem.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org