[PATCH 19/19] Documentation: ACPI for ARM64

On Mon, Aug 18, 2014 at 10:29:26AM +0100, Hanjun Guo wrote:

On 2014-8-15 18:01, Catalin Marinas wrote:

quoted

Hanjun,

Hi Catalin,

quoted

On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:

quoted

On 2014-8-14 18:27, Catalin Marinas wrote:

quoted

On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:

quoted

On 2014-8-14 7:41, Rafael J. Wysocki wrote:

quoted

On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:

quoted

If we consider ACPI unusable on ARM but we still want to start merging
patches, we should rather make the config option depend on BROKEN
(though if it is that unusable that no real platform can use it, I would
rather not merge it at all at this stage).

I agree here.

I would recommend creating a separate branch for that living outside of the
mainline kernel and merging it when there are real users.

Real users will coming soon, we already tested this patch set on real hardware
(ARM64 Juno platform),

I don't consider Juno a server platform ;) (but it's good enough for
development).

quoted

and I think ARM64 server chips and platforms will show up before 3.18
is released.

That's what I've heard/seen. The questions I have are (a) whether
current ACPI patchset is enough to successfully run Linux on such
_hardware_ platform (maybe not fully optimised, for example just WFI
cpuidle) and (b) whether we still want to mandate a DT in the kernel for
such platforms.

For (a), this patch set is only for ARM64 core, not including platform
specific device drivers, it will be covered by the binding of _DSD or
explicit definition of PNP ID/ACPI ID(s).

So we go back to the discussions we had few months ago in Macau. I'm not
concerned about the core ARM and architected peripherals covered by ACPI
5.1 (as long as the current patches get positive technical review). But
I'm concerned about the additional bits needed for a real SoC like _DSD
definitions, how they get reviewed/accepted (or is it just the vendor's
problem?).

As the _DSD patch set sent out by Intel folks, _DSD definitions are just
DT definitions. To use _DSD or not, I think it depends on OEM use cases,
we can bring up Juno without _DSD (Graeme is working on that, still need
some time to clean up the code).

Let's not confuse matters by saying that _DSD is DT. DSD allows for
key-value pairs, and has a reference mechanism roughly equivalent to
phandles. That does not make them the same thing.

Not having any guidelines for vendors is an extremely bad idea. The DT
bindings we get a chance to review often have major issues. I do not
believe that vendors will do things sanely without good guidance and
strong incentives.

[...]

quoted

quoted

For ACPI 5.1, it fixes many problems for ARM:
- weak definition for GIC, so we introduce visualization, v2m and
  part of GICv3/4 (redistributors) support.
- No support for PSCI. Fix it to support PSCI 0.2+;
- Not support for Always-on timer and SBSA-L1 watchdog.

These are all good, that's why we shouldn't even talk about ACPI 5.0 in
the ARM context.

quoted

- How to describe device properties, so _DSD is introduced for
  device probe.

For the last bullet, is there any review process (at least like what we
have for DT bindings)? On top of such process, do we have guidelines and
example code on how the Linux support should be implemented. As Olof
mentioned, should we see how the DT and ACPI probing paths work
together? I really think we should be very clear here and not let
vendors invent their own independent methods.

As said above, Intel folks provided some good examples for that, and
clarified a lot of things:

https://lkml.org/lkml/2014/8/17/10

Quite frankly, the examples provided in the _DSD series are atrocious.
They constitute a trivial mapping of some existing DT bindings to ACPI
which do not appear to have gone through any sort of review w.r.t.
remaining idiomatic.

Thanks,
Mark.