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. -- ciao, al ----------------------------------- Al Stone Software Engineer Linaro Enterprise Group al.stone@xxxxxxxxxx ----------------------------------- -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
