ACPI vs DT at runtime

David Goodenough david.goodenough at btconnect.com
Mon Nov 18 17:47:03 EST 2013


On Monday 18 Nov 2013, Grant Likely wrote:
> On Mon, 18 Nov 2013 11:09:29 -0800, Olof Johansson <olof at lixom.net> wrote:
> > On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote:
> > 
> > I'm looking at the quality of the initial submissions (very poor and
> > confused), the readiness of the kernel in general (none so far),
> > the way the involved parties are doing development (away from the
> > community and in their own little world). I also look at some of the
> > bottlenecks we've had with device tree (reviewer bandwidth, slow-moving
> > consensus/standards-driven approval process) and how it compares to the
> > ACPI counterparts (standards forum).
> > 
> > The conclusion is that we're about to embark onto something that isn't
> > going to be done right in the short to medium term. It just isn't. The
> > sooner we own up to that, the sooner we can course-correct and get back
> > to something that's likely to work.
> > 
> > The alternative is signing onto a setup that _will_ stumble right out
> > of the door, which in turn will mean that the high-end ARM play will be
> > off to a rough start instead of running as smoothly as possible.
> 
> I completely agree here. The DT conversion was hard and it took a lot of
> years. There was a lot of getting the code into shape and a lot of
> people trying to get their heads around it. ACPI is exactly the same
> problem. We don't know what we're doing and we don't know how to do it
> yet.
> 
> I fully support getting ACPI up on ARM and the current work is good.
> However, it cannot short-circuit the kernel development process.
> Absolutely, push back hard on the ACPI and UEFI patches where the code
> is not ready.
> 
> g.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Would it not be possible to have ACPI read the hardware configuration
from the DT, and provide whatever services it wants, while also allowing
the kernel to retain the DT for its hardware config?  I suppose the only
thing that would be needed would be some way to mark paricular bits of
hardware (I am largely thinking of the things lmsensors deals with) as
being used by ACPI and being off limits to the kernel.

David




More information about the linux-arm-kernel mailing list