Re: ACPI vs DT at runtime

[Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>]

On Thu, Nov 21, 2013 at 09:58:22AM -0800, Olof Johansson wrote:
> On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote:
> > We are pushing a lot of boundaries and doing things on ACPI that have
> > never been done before. SPI, GPIOs, Clocks, Regulators, composite
> > devices, key-value properties. All brand new territory, and the Linux
> > world is driving a lot of it.
> 
> This is a bit of a surprise and a significant concern.
> 
> The whole point behind ACPI is that it's supposed to abstract away nearly
> all of that, and _not_ expose clocks, regulators and other things to
> the kernel. If we're going to expose it, then we might as well go all
> the way and do it with DT.

This depends what you want from ACPI, and what market ACPI is being
targetted at.

If ACPI is targetted at the embedded end, then having that information is
fundamental to good power management (think about it - if you're doing
hard power management where you need to turn on a clock from IRQ context,
can you do that by running some AML code from that context?)

If ACPI is targetted at just the server end, then at the moment it's
probably not something that's required, because fine-grained power
management isn't found on such platforms.

However, that could very well change - we are in a world where we've had
the golden years of cheap energy, and energy costs are going to go one
way and one way only - so for the server market, power management to the
same extent that we see in the embedded world will eventually transition
over into that market too.

At that point, the OS is probably going to have to know these kinds of
details so it can do fine grained power management from tricky contexts...
or we'll be running native code fragments provided by the vendor to do
that...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html