From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752138AbbCLBuV (ORCPT ); Wed, 11 Mar 2015 21:50:21 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:46488 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751504AbbCLBuR (ORCPT ); Wed, 11 Mar 2015 21:50:17 -0400 Message-ID: <5500EFFF.2070807@huawei.com> Date: Thu, 12 Mar 2015 09:46:39 +0800 From: Hanjun Guo User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Jason Cooper , Grant Likely CC: Mark Rutland , linaro-acpi , Catalin Marinas , Will Deacon , Lorenzo Pieralisi , Timur Tabi , "ACPI Devel Mailing List" , Robert Richter , Arnd Bergmann , Marc Zyngier , "Jon Masters" , Tomasz Nowicki , "Mark Brown" , Thomas Gleixner , , Graeme Gregory , Ashwin Chaugule , "Rafael J. Wysocki" , Linux Kernel Mailing List , Hanjun Guo , "Suravee Suthikulanit" , Sudeep Holla , Olof Johansson Subject: Re: [PATCH v10 16/21] irqchip: Add GICv2 specific ACPI boot support References: <1426077587-1561-1-git-send-email-hanjun.guo@linaro.org> <1426077587-1561-17-git-send-email-hanjun.guo@linaro.org> <20150311231141.GG21998@io.lakedaemon.net> In-Reply-To: <20150311231141.GG21998@io.lakedaemon.net> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.17.188] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5500F021.0157,ss=1,re=0.001,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5f17721659af7bd2470a2343708b4ce1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015/3/12 7:11, Jason Cooper wrote: > Hey Grant, > > On Wed, Mar 11, 2015 at 06:04:50PM +0000, Grant Likely wrote: >> On 11 Mar 2015 12:42, "Hanjun Guo" wrote: >>> From: Tomasz Nowicki >>> >>> ACPI kernel uses MADT table for proper GIC initialization. It needs to >>> parse GIC related subtables, collect CPU interface and distributor >>> addresses and call driver initialization function (which is hardware >>> abstraction agnostic). In a similar way, FDT initialize GICv1/2. >>> >>> NOTE: This commit allow to initialize GICv1/2 basic functionality. >>> While now simple GICv2 init call is used, any further GIC features >>> require generic infrastructure for proper ACPI irqchip initialization. >>> That mechanism and stacked irqdomains to support GICv2 MSI/virtualization >>> extension, GICv3/4 and its ITS are considered as next steps. >>> >>> CC: Jason Cooper >>> CC: Marc Zyngier >>> CC: Thomas Gleixner >> BTW, Thomas is taking a bit of a break, do he is unlikely to give an ack >> here in a timely manner. I've not heard from Jason. Personally, I think we >> can proceed without their ack if everything else is in order (heck, I used >> to help with the irq subsystem, use me as an ack of you want). The patch is >> low impact and only had effect for ARM ACPI builds. > I'm not talking much, but I am tracking and collecting everything for irqchip. > We do have some other changes in this driver this time around. So it'd be nice > if I could take this. > > I had reached out to Olof for his thoughts on this and he hasn't had enough > cycles to look at it. iirc, Marc reviewed a previous version and was happy with > the changes. My only question I had for Olof I'll put below: Please allow me to explain a little bit before Olof's confirmation, please don't mind if any offended. > >>> diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c >>> index 0fe2f71..afd1af3 100644 >>> --- a/drivers/irqchip/irqchip.c >>> +++ b/drivers/irqchip/irqchip.c >>> @@ -8,6 +8,7 @@ >>> * warranty of any kind, whether express or implied. >>> */ >>> >>> +#include >>> #include >>> #include >>> #include >>> @@ -26,4 +27,6 @@ extern struct of_device_id __irqchip_of_table[]; >>> void __init irqchip_init(void) >>> { >>> of_irq_init(__irqchip_of_table); >>> + >>> + acpi_irq_init(); >>> } > Is this in line with Olof's idea that providing a dtb would override ACPI? Yes, it will. Since ACPI is default OFF (disabled), if a dtb provided, and no acpi=force passed in the early command line, dtb will be used as system configuration for boot (dtb is always the prior one for now) [1]. In acpi_gic_init() which called by acpi_irq_init(), it will return immediately if acpi disabled, so it will not parse any ACPI table for device configuration. [1]: [patch 08/21] ARM64 / ACPI: Introduce early_param "acpi=" to enable/disable ACPI Thanks Hanjun