Thread (1 message) 1 message, 1 author, 2013-11-20

ACPI vs DT at runtime

From: Olof Johansson <hidden>
Date: 2013-11-20 17:47:24
Also in: linux-devicetree

On Wed, Nov 20, 2013 at 9:43 AM, Stefano Stabellini
[off-list ref] wrote:
On Wed, 20 Nov 2013, Grant Likely wrote:
quoted
On Fri, 15 Nov 2013 09:57:17 +0000, Mark Rutland [off-list ref] wrote:
quoted
On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
quoted
The more I start to see early UEFI/ACPI code, the more I am certain
that we want none of that crap in the kernel. It's making things
considerably messier, while we're already very busy trying to convert
everything over and enable DT -- we'll be preempting that effort just
to add even more boilerplate everywhere and total progress will be
hurt.
We are certainly under a lot of pressure with the device tree migration,
and I agree that adding another information source is going to be a
source of pain. However, I'd argue that we're going to encounter pain
regardless of which approach we take.

I'm of the opinion that the only way we should support ACPI is as a
first-class citizen. We don't need to modify every driver and subsystem
to support ACPI, only those necessary to support the minimal set of
platforms using ACPI. ACPI is new in the arm space, and we can enforce
quality standards on ACPI _now_ above what we're allowing for DT, and
avoid future problems.
Translated ACPI tables really don't make any sense at all. While the
models are similar in some regards, they are very different in others
and any translator (I suspect) would become very complicated to deal
with all the edge cases.
If it turns out that we can't translate the ACPI tables dynamically, we
could maintain a repository of "manually" translated DTSes for all the
systems that do not ship with device tree.  Given that DTBs are fairly
small, we could stick them all in an initrd or another binary loaded by
the bootloader so that Linux and/or Xen can select the right one at boot
time.
There are many possible ways to solve this, and I think we'll have to
wait and see how it ends up being used before we decide what to do.
Again, it's better to let things settle out for a few generations
instead of trying to support everything from the very beginning, given
that we're expecting turmoil in this area.


-Olof
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help