On Thu, Dec 19, 2013 at 02:01:26PM +0000, Arnd Bergmann wrote:

On Thursday 19 December 2013, Graeme Gregory wrote:

quoted

Hopefully the documenation of what real armv8 server architecture will look
like will come in the new year. Things like regulators and clocks I do not
have answers to yet as obviously in Intel world these things are hidden
from view, I do not know what the plan is for armv8 silicon/motherboards.

The clocks and regulators (and a handful of other subsystems) are
the key thing to work out IMHO. For all I know these are either completely
static (turned on by firmware at boot time) on current servers, or they
are done in a way that each device can manage itself using power states
in the PCI configuration space. If you have on-chip devices that do not
look like PCI devices to software, or that interact with other on-chip
controllers at run-time as on typical arm32 embedded SoCs, you are in
trouble to start with, and there are two possible ways to deal with this
in theory:

a) Hide all the register-level setup behind AML code and make Linux only
   aware of the possible device states that it can ask for, which would
   make this look similar to today's servers.

b) Model all the soc-internal registers as devices and write OS-specific
   SoC-specific device drivers for them, using yet-to-be-defined ACPI
   extensions to describe the interactions between devices. This would
   be modeled along the lines of what we do today with DT, and what Intel
   wants to do on their embedded SoCs with ACPI in the future.

I think anybody would agree that we should not try to mix the two models
in a single system, as that would create an endless source of bugs when
you have two drivers fighting over the same hardware. There is also a
rough consensus that we really only want a) and not b) on ARM, but there
have been indications that people are already working on b), which I
think is a bit worrying. I would argue that anyone who wants b) on 
ARM should not use ACPI at all but rather describe the hardware using
DT as we do today. This could possibly change if someone shows that a)
is actually not a realistic model at all, but I also think that doing b)
properly will depend on doing a major ACPI-6.0 or ACPI-7.0 release
to actually specify a standard model for the extra subsystems.

I'm inclined to say that (ARM) Linux should only support stuff captured
in an ACPI spec but I'm not familiar enough with this to assess its
feasibility.

Choosing between a) and b) depends when where you place the maintenance
burden. Point a) pretty much leaves this with the hw vendors. They get a
distro with a kernel supporting ACPI-x and (PCI) device drivers they
need but other SoC specific is handled by firmware or AML. It is their
responsibility to work on firmware and AML until getting it right
without changing the kernel (well, unless they find genuine bugs with
the code).

Point b) is simpler for kernel developers as we know how to debug and
maintain kernel code but I agree with you that we should rather use FDT
here than duplicate the effort just for the sake of ACPI.

Waiting for OS distros and vendors to clarify but I think RH are mainly
looking at a). My (mis)understanding is based based on pro-ACPI
arguments I heard like being able to use newer hardware with older
kernels (and b) would always require new SoC drivers and bindings).

-- 
Catalin