[PATCH 19/19] Documentation: ACPI for ARM64

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

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).

Given the answer to (a) and what other features are needed, we may or
may not mandate (b). We were pretty clear few months ago that (b) is
still required but at the time we were only openly talking about ACPI
5.0 which was lacking many features. I think we need to revisit that
position based on how usable ACPI 5.1 for ARM (and current kernel
implementation) is. Would you mind elaborating what an ACPI-only
platform miss?

Do you mean something still missing? We still miss some features for
ARM in ACPI, but I think they are not critical, here is the list I can
remember:
- ITS for GICv3/4;
- SMMU support;
- CPU idle control.

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.
- How to describe device properties, so _DSD is introduced for
  device probe.

I would expect a new server platform designed with ACPI in mind to
require minimal SoC specific code, so we may only see a few patches
under drivers/ for such platforms adding ACPI-specific probing (possibly
new drivers as well if it's a new component).

quoted

For this patch set, DT is the first class citizen at now:

a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;

Not just off but, based on maturity, depend on EXPERT.

Ok. And don't set ACPI default off (pass acpi=on to enable it)?

quoted

b) Even if we set CONFIG_ACPI=Y, we also can use DT as normal:

  - Pass DT blob without (valid) ACPI tables (just as we boot the kernel now),
    ACPI will disabled in the very early stage and FDT will still to be
    unflattened, so will not break DT booting.

  - We can pass ACPI=off to disable ACPI and use DT even if we got valid
    ACPI tables (in the v1 patch set);

So it is safe for people who want to use DT, and didn't change any behavior
of DT booting except some extra test of if(acpi_disabled).

But should we require SoC firmware to provide both valid DT and ACPI
tables so that the user can decide which one to select at boot-time?

No, I think only one of them should be provided on real platforms.

Thanks
Hanjun