lkml.org 
[lkml]   [2015]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Linaro-acpi] [PATCH v8 00/21] Introduce ACPI for ARM64 based on ACPI 5.1
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


\
 
 \ /
  Last update: 2015-02-04 11:01    [W:0.119 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site