Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964860AbbBDJly (ORCPT ); Wed, 4 Feb 2015 04:41:54 -0500 Received: from mail-pa0-f46.google.com ([209.85.220.46]:38686 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754572AbbBDJlt (ORCPT ); Wed, 4 Feb 2015 04:41:49 -0500 Message-ID: <54D1E954.4050003@linaro.org> Date: Wed, 04 Feb 2015 17:41:40 +0800 From: Hanjun Guo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Al Stone , Mark Rutland CC: Mark Langsdorf , "linaro-acpi@lists.linaro.org" , Catalin Marinas , Will Deacon , "wangyijing@huawei.com" , Rob Herring , Timur Tabi , Daniel Lezcano , "linux-acpi@vger.kernel.org" , "phoenix.liyi@huawei.com" , Robert Richter , Jason Cooper , Arnd Bergmann , Marc Zyngier , "jcm@redhat.com" , Mark Brown , Bjorn Helgaas , "linux-arm-kernel@lists.infradead.org" , Ashwin Chaugule , Randy Dunlap , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Olof Johansson Subject: Re: [Linaro-acpi] [PATCH v8 00/21] Introduce ACPI for ARM64 based on ACPI 5.1 References: <1422881149-8177-1-git-send-email-hanjun.guo@linaro.org> <20150203164727.GC32750@leverpostej> <54D108DD.6050509@linaro.org> In-Reply-To: <54D108DD.6050509@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3203 Lines: 76 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/