[Linaro-acpi] [PATCH v8 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[hanjun.guo@linaro.org (Hanjun Guo)]

On 2015?02?04? 01:43, Al Stone wrote:
> On 02/03/2015 09:47 AM, Mark Rutland wrote:
>> On Mon, Feb 02, 2015 at 12:45:28PM +0000, Hanjun Guo wrote:
>>> Hi,
>>>
>>> This is the v8 of ACPI core patches for ARM64 based on ACPI 5.1, there are
>>> some updates since v7:
>>>
>>>   - Add two more documantation to explain why we need ACPI in ARM64 servers
>>>     by Grant, and recommendations and prohibitions on the use of the numerous
>>>     ACPI tables and objects by Al Stone.
>>>
>>>   - Add two patches which is need to map acpi tables after acpi_gbl_permanent_mmap
>>>     is set
>>>
>>>   - Add another patch "dt / chosen: Add linux,uefi-stub-generated-dtb property"
>>>     to address that if firmware providing no dtb, we can try ACPI configuration data
>>>     even if no "acpi=force" is passed in early parameters. (I think ACPI for XEN and
>>>     kexec need consider sperately as disscussed, correct me if I'm wrong).
>>>
>>>   - Add CC in the patch to the subsystem maintainers and modify the subject
>>>     of the patch to explicitly show the subsystem touched by this patch set,
>>>     please help us to review and ack them if they make sense, thanks.
>>>
>>>   - Add Tested-by from Qualcomm and Redhat;
>>>
>>>   - Make ACPI depends on PCI suggested by Catalin;
>>>
>>>   - Clean up SMP init function as Lorenzo suggested, remove physical
>>>     CPU hot-plug code in the patch;
>>>
>>>   - Address some comments from Marc and explicitly state that will
>>>     implment statcked irqdomain and GIC init framework when GICv3 and
>>>     ITS, GICv2m are implemented;
>>>
>>>   - Rebased on top of 3.19-rc7.
>>>
>>> previous version is here:
>>> v7: https://lkml.org/lkml/2015/1/14/586
>>> v6: https://lkml.org/lkml/2015/1/4/40
>>>
>>> Any comments are welcome :)
>>
>> I note that for ACPI the PMU interrupt information is stored in the GICC
>> (as "Performance Interrupt" and "Performance Interrupt Mode"), but I
>> don't see any code for handling that as part of this series.
>>
>> Is anyone currently looking into that?
>
> Yes.  IIRC, it's a pretty small patch that I'll be including in the
> Seattle patches that build on top of this core set.
>
>> For those systems ACPI is being developed on do we know that the GICC
>> information for the PMU interrupts is sane?
>
> Yes.  We know this works for Seattle platforms, using their latest firmware.
>
>> I'm slightly worried about the prospect of adding support later only to
>> find that the performance interrupt data in contemporary GICC tables is
>> invalid; it's going to be extremely painful to detect that being the
>> case in order to perform any kind of workaround.
>
> That will depend on the error, of course.  It was pretty straightforward
> when the interrupt value was set to zero in some of the early tables we
> used.

If we are not worrying about too much patch in this series, I can
cherry-pick Mark Salter's ACPI PMU patch for Seattle in next version.

Thanks
Hanjun