From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Masters Subject: Re: [PATCH v3 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support Date: Tue, 09 Sep 2014 02:27:24 -0400 Message-ID: <540E9DCC.4080903@redhat.com> References: <1409583475-6978-1-git-send-email-hanjun.guo@linaro.org> <5405BFE7.5060005@arm.com> <5406DEB6.1060705@linaro.org> <4895927.Zp4WL2AZAF@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com ([209.132.183.28]:23512 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753658AbaIIG2k (ORCPT ); Tue, 9 Sep 2014 02:28:40 -0400 In-Reply-To: <4895927.Zp4WL2AZAF@wuerfel> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Arnd Bergmann , Tomasz Nowicki Cc: Marc Zyngier , "hanjun.guo@linaro.org" , Catalin Marinas , "Rafael J. Wysocki" , Mark Rutland , Olof Johansson , "grant.likely@linaro.org" , "graeme.gregory@linaro.org" , Sudeep Holla , Will Deacon , Jason Cooper , Bjorn Helgaas , Daniel Lezcano , Mark Brown , Rob Herring , Robert Richter , Lv Zheng , Robert Moore , Lorenzo Pieralisi , Liviu Dudau , Randy Dunlap , Charles Garcia-Tobin On 09/03/2014 10:57 AM, Arnd Bergmann wrote: > On Wednesday 03 September 2014 11:26:14 Tomasz Nowicki wrote: > In particular, the ACPI tables describing the irqchip have no way to > identify the GIC at all, if I read the spec correctly, you have to > parse the tables, ioremap the registers and then read the ID to know > if you have GICv1/v2/v2m/v3/v4. There doesn't seem to be any "device" > for the GIC that a hypothetical probe function would be based on. (aside) I have already noticed this and am separately raising a request to have this dealt with in the specification at a later time. I believe it's fairly contrived, since I don't think it'll be at all common to have a GICv3/v4 IP implementation that has a CPU interface defined. The problem (not now, but in later implementations that actually have GICv3/v4 hardware is making assumptions since even a GICv3 or GICv4 system could implement a legacy compatibility mode in which the memory register interface is defined and mappable so you would be valid in having defined memory addresses in the MADT linked structures then. Jon. From mboxrd@z Thu Jan 1 00:00:00 1970 From: jcm@redhat.com (Jon Masters) Date: Tue, 09 Sep 2014 02:27:24 -0400 Subject: [PATCH v3 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support In-Reply-To: <4895927.Zp4WL2AZAF@wuerfel> References: <1409583475-6978-1-git-send-email-hanjun.guo@linaro.org> <5405BFE7.5060005@arm.com> <5406DEB6.1060705@linaro.org> <4895927.Zp4WL2AZAF@wuerfel> Message-ID: <540E9DCC.4080903@redhat.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 09/03/2014 10:57 AM, Arnd Bergmann wrote: > On Wednesday 03 September 2014 11:26:14 Tomasz Nowicki wrote: > In particular, the ACPI tables describing the irqchip have no way to > identify the GIC at all, if I read the spec correctly, you have to > parse the tables, ioremap the registers and then read the ID to know > if you have GICv1/v2/v2m/v3/v4. There doesn't seem to be any "device" > for the GIC that a hypothetical probe function would be based on. (aside) I have already noticed this and am separately raising a request to have this dealt with in the specification at a later time. I believe it's fairly contrived, since I don't think it'll be at all common to have a GICv3/v4 IP implementation that has a CPU interface defined. The problem (not now, but in later implementations that actually have GICv3/v4 hardware is making assumptions since even a GICv3 or GICv4 system could implement a legacy compatibility mode in which the memory register interface is defined and mappable so you would be valid in having defined memory addresses in the MADT linked structures then. Jon. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755825AbaIIG2m (ORCPT ); Tue, 9 Sep 2014 02:28:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23512 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753658AbaIIG2k (ORCPT ); Tue, 9 Sep 2014 02:28:40 -0400 Message-ID: <540E9DCC.4080903@redhat.com> Date: Tue, 09 Sep 2014 02:27:24 -0400 From: Jon Masters Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Arnd Bergmann , Tomasz Nowicki CC: Marc Zyngier , "hanjun.guo@linaro.org" , Catalin Marinas , "Rafael J. Wysocki" , Mark Rutland , Olof Johansson , "grant.likely@linaro.org" , "graeme.gregory@linaro.org" , Sudeep Holla , Will Deacon , Jason Cooper , Bjorn Helgaas , Daniel Lezcano , Mark Brown , Rob Herring , Robert Richter , Lv Zheng , Robert Moore , Lorenzo Pieralisi , Liviu Dudau , Randy Dunlap , Charles Garcia-Tobin , "linux-acpi@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support References: <1409583475-6978-1-git-send-email-hanjun.guo@linaro.org> <5405BFE7.5060005@arm.com> <5406DEB6.1060705@linaro.org> <4895927.Zp4WL2AZAF@wuerfel> In-Reply-To: <4895927.Zp4WL2AZAF@wuerfel> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/03/2014 10:57 AM, Arnd Bergmann wrote: > On Wednesday 03 September 2014 11:26:14 Tomasz Nowicki wrote: > In particular, the ACPI tables describing the irqchip have no way to > identify the GIC at all, if I read the spec correctly, you have to > parse the tables, ioremap the registers and then read the ID to know > if you have GICv1/v2/v2m/v3/v4. There doesn't seem to be any "device" > for the GIC that a hypothetical probe function would be based on. (aside) I have already noticed this and am separately raising a request to have this dealt with in the specification at a later time. I believe it's fairly contrived, since I don't think it'll be at all common to have a GICv3/v4 IP implementation that has a CPU interface defined. The problem (not now, but in later implementations that actually have GICv3/v4 hardware is making assumptions since even a GICv3 or GICv4 system could implement a legacy compatibility mode in which the memory register interface is defined and mappable so you would be valid in having defined memory addresses in the MADT linked structures then. Jon.