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?

For those systems ACPI is being developed on do we know that the GICC
information for the PMU interrupts is sane?

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.

Thanks,
Mark.