Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo <hanjun.guo@linaro.org>]

On 2014-8-14 18:27, Catalin Marinas wrote:
> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>>>> 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).
> 
>> 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).
> 
>> 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)?

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