ACPI vs DT at runtime

[Grant Likely]

On Fri, 15 Nov 2013 18:13:47 +0000, David Goodenough <david.goodenough at btconnect.com> wrote:
> On Friday 15 Nov 2013, Olof Johansson wrote:
> > > I'm not sure that translating ACPI tables to dt makes any sense. If AML
> > > is used (even sparingly), I do not believe that we can do any sensible
> > > conversion to device tree. My understanding is that AML includes
> > > functionality for modifying ACPI tables, and I don't see how we can
> > > possibly support that without having to add a lot of boilerplate to all
> > > the code handling AML to add a device tree backend...
> > 
> > We can definitely modify device tree contents at runtime, it's just that
> > nobody besides the POWER server guys are doing that today. So that's
> > not a strong argument in ACPI's favor. We should fix device-tree where
> > needed instead.
> Is this true.  On the Beagle Board/Bone there is extensive use of Device
> Tree Overlays, which feels like run time modification to me.  It gets 
> used to enable multiplexed pins to a particular configuration.

ACPI can load/unload an arbitrary number of SSDTs into the ACPI
namespace. They pretty much act in the same way as DT overlays. The hard
part is that the loading of an SSDT can be embedded into an AML method
so that it can be triggered by an event. I'm told that it is used for
things like hotplugging CPUs. This is what I meant in my earlier comment
that ACPI is oriented towards handling the difficult bits in the
platform. On a DT system we would describe the possible hotplugged
CPUs and expect a device driver to be present that knows when to perform
those operations.

g.