From: Tomasz Nowicki <tomasz.nowicki@linaro.org>
To: Marc Zyngier <marc.zyngier@arm.com>, Arnd Bergmann <arnd@arndb.de>
Cc: "linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Liviu Dudau <Liviu.Dudau@arm.com>, Lv Zheng <lv.zheng@intel.com>,
Rob Herring <robh@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Robert Moore <robert.moore@intel.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
Robert Richter <rric@kernel.org>,
Jason Cooper <jason@lakedaemon.net>,
Will Deacon <Will.Deacon@arm.com>,
Mark Brown <broonie@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Randy Dunlap <rdunlap@infradead.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Olof Johansson <olof@lixom.net>
Subject: Re: [Linaro-acpi] [PATCH v3 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support
Date: Fri, 05 Sep 2014 12:49:52 +0200 [thread overview]
Message-ID: <54099550.5080902@linaro.org> (raw)
In-Reply-To: <540992EA.6020209@arm.com>
On 05.09.2014 12:39, Marc Zyngier wrote:
> On 05/09/14 11:13, Arnd Bergmann wrote:
>> On Friday 05 September 2014 10:47:30 Marc Zyngier wrote:
>>>>
>>>> I still prefer being explicit here for the same reason I mentioned earlier:
>>>> I want it to be very clear that we don't support arbitrary irqchips other
>>>> than the ones in the APCI specification. The infrastructure exists on DT
>>>> because we have to support a large number of incompatible irqchips.
>>>
>>> I'm not suggesting that we should support more than the ACPI spec says.
>>> And that's certainly the whole point of a spec, isn't it? ACPI says what
>>> we support, and we're not going any further. I'm just saying that we
>>> shouldn't make the maintenance burden heavier, and the code nothing
>>> short of disgusting. Using our current infrastructure doesn't mean we're
>>> going to support GIcv2.37.
>>
>> Ok
>>
>>>> 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.
>>>
>>> This is not the way I read the spec. Table 5-46 (Interrupt Controller
>>> Structure) tells you if you have a CPU interface (GICv1/v2) or a
>>> redistributor (GICv3/v4). That's enough to know whether or not you
>>> should carry on probing a particular controller.
>>
>> Ah, good. I missed that.
>>
>>> The various GIC versions don't really have a unified memory map anyway
>>> (well, none that you can rely on), and you really have to rely on ACPI
>>> to tell you what you have.
>>
>> So we are back to needing to support two different irqchip drivers
>> (v1/v2/v2m and v3/v4), instead of five or more, right?
>
> As long as we make sure that the variants are directly probed from the
> "canonical" driver (v2m from v2, ITS and v4 from v3), then we're OK.
Yes, that is our intention.
>
>>>> It does seem wrong to parse the tables in the irq-gic.c file though:
>>>> that part can well be common across the various gic versions and then
>>>> call into either irq-gic.c or irq-gic-v3.c for the version specific
>>>> parts. Whether we put that common code into drivers/irqchip/irqchip.c,
>>>> drivers/irqchip/gic-common.c, drivers/irqchip/irq-acpi-gic.c or
>>>> drivers/acpi/irq-gic.c I don't care at all.
>>>
>>> I don't think so you can make that common code very easily. The
>>> information required by both drivers is organized differently.
>>> If it was, I'd have done that for the DT binding.
>>
>> I see, and that's also what Tomasz just explained. So can we just
>> have one an irqchip_init() function doing this:?
>>
>> if (dt)
>> of_irq_init(__irqchip_of_table);
>> else if (acpi) {
>> read cpu-interface and redistributor address from acpi tables
>> if (cpu-interface)
>> gic_v2_acpi_init(table);
>> else if(redistributor)
>> gic_v3_acpi_init(table)
>> }
>
> That'd be better, but that only considers the basic architecture. GICv2m
> and GICv3's ITS bring additional complexity (and their own table
> parsing). At that stage, I'm not sure how much commonality we're left with.
Right, my local ACPI GICv3 support assumes to probe ITS from
gic_v3_acpi_init() body.
Tomasz
next prev parent reply other threads:[~2014-09-05 10:49 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-01 14:57 [PATCH v3 00/17] Introduce ACPI for ARM64 based on ACPI 5.1 Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 01/17] ARM64: Move the init of cpu_logical_map(0) before unflatten_device_tree() Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 02/17] ARM64 / ACPI: Get RSDP and ACPI boot-time tables Hanjun Guo
2014-09-09 16:26 ` Catalin Marinas
2014-09-09 16:41 ` Jon Masters
2014-09-09 16:44 ` Jon Masters
2014-09-09 17:15 ` Mark Rutland
2014-09-09 17:33 ` Jon Masters
2014-09-09 17:50 ` Lorenzo Pieralisi
2014-09-09 18:05 ` Sudeep Holla
2014-09-09 19:06 ` Jon Masters
2014-09-10 11:13 ` Hanjun Guo
2014-09-10 12:33 ` Catalin Marinas
2014-09-10 21:51 ` Grant Likely
2014-09-11 11:01 ` Catalin Marinas
2014-09-14 15:40 ` Grant Likely
2014-09-14 21:59 ` Catalin Marinas
2014-09-15 3:53 ` Grant Likely
2014-09-16 5:29 ` Zheng, Lv
2014-09-10 21:41 ` Grant Likely
2014-09-09 16:54 ` Mark Rutland
2014-09-10 7:30 ` Hanjun Guo
2014-09-10 21:37 ` Grant Likely
2014-09-01 14:57 ` [PATCH v3 03/17] ARM64 / ACPI: Introduce lowlevel suspend function Hanjun Guo
2014-09-09 16:35 ` Catalin Marinas
2014-09-09 22:04 ` Graeme Gregory
2014-09-01 14:57 ` [PATCH v3 04/17] ARM64 / ACPI: Introduce early_param for "acpi" Hanjun Guo
2014-09-09 16:37 ` Catalin Marinas
2014-09-09 17:17 ` Bjorn Helgaas
2014-09-09 22:14 ` Jon Masters
2014-09-10 13:04 ` Will Deacon
2014-09-10 13:21 ` Bjorn Helgaas
2014-09-10 18:30 ` Will Deacon
2014-09-10 21:58 ` Grant Likely
2014-09-01 14:57 ` [PATCH v3 05/17] ARM64 / ACPI: If we chose to boot from acpi then disable FDT Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 06/17] ARM64 / ACPI: Make PCI optional for ACPI on ARM64 Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 07/17] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 08/17] ACPI / table: Print GIC information when MADT is parsed Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 09/17] ARM64 / ACPI: Parse MADT for SMP initialization Hanjun Guo
2014-09-03 17:21 ` Lorenzo Pieralisi
2014-09-04 15:29 ` Hanjun Guo
2014-09-09 4:29 ` Jon Masters
2014-09-09 5:11 ` Hanjun Guo
2014-09-09 5:34 ` Jon Masters
2014-09-09 16:52 ` Lorenzo Pieralisi
2014-09-09 17:00 ` Jon Masters
2014-09-09 17:02 ` Jon Masters
2014-09-09 4:23 ` Jon Masters
2014-09-09 4:57 ` Hanjun Guo
2014-09-09 5:44 ` Jon Masters
2014-09-09 16:00 ` Hanjun Guo
2014-09-09 16:04 ` Jon Masters
2014-09-09 16:14 ` Hanjun Guo
2014-09-11 14:15 ` Will Deacon
2014-09-12 21:30 ` Jon Masters
2014-09-11 10:24 ` Grant Likely
2014-09-01 14:57 ` [PATCH v3 10/17] ACPI / processor: Make it possible to get CPU hardware ID via GICC Hanjun Guo
2014-09-03 16:27 ` Lorenzo Pieralisi
2014-09-08 13:10 ` Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 11/17] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi Hanjun Guo
2014-09-11 11:08 ` Grant Likely
2014-09-11 11:34 ` Grant Likely
2014-09-12 9:42 ` Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 12/17] ACPI / table: Add new function to get table entries Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support Hanjun Guo
2014-09-01 17:35 ` Marc Zyngier
2014-09-02 8:28 ` [Linaro-acpi] " Alexander Spyridakis
2014-09-02 11:48 ` Tomasz Nowicki
2014-09-02 13:02 ` Marc Zyngier
2014-09-02 15:45 ` Hanjun Guo
2014-09-02 15:59 ` Marc Zyngier
2014-09-02 16:11 ` Sudeep Holla
2014-09-03 10:30 ` Marc Zyngier
2014-09-03 11:17 ` Hanjun Guo
2014-09-04 14:03 ` Hanjun Guo
2014-09-09 6:21 ` Jon Masters
2014-09-03 9:26 ` Tomasz Nowicki
2014-09-03 14:57 ` Arnd Bergmann
2014-09-05 8:52 ` Tomasz Nowicki
2014-09-05 9:47 ` Marc Zyngier
2014-09-05 10:13 ` [Linaro-acpi] " Arnd Bergmann
2014-09-05 10:36 ` Tomasz Nowicki
2014-09-05 10:39 ` Marc Zyngier
2014-09-05 10:49 ` Tomasz Nowicki [this message]
2014-09-09 6:27 ` Jon Masters
2014-09-11 13:43 ` Grant Likely
2014-09-02 16:34 ` Catalin Marinas
2014-09-11 11:48 ` Grant Likely
2014-09-11 12:01 ` Marc Zyngier
2014-09-09 6:14 ` Jon Masters
2014-09-03 18:42 ` Arnd Bergmann
2014-09-04 10:10 ` Tomasz Nowicki
2014-09-04 10:14 ` Arnd Bergmann
2014-09-04 10:39 ` Tomasz Nowicki
2014-09-09 6:35 ` Jon Masters
2014-09-01 14:57 ` [PATCH v3 14/17] ARM64 / ACPI: Parse GTDT to initialize arch timer Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 15/17] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 16/17] ARM64 / ACPI: Enable ARM64 in Kconfig Hanjun Guo
2014-09-11 15:18 ` Lorenzo Pieralisi
2014-09-01 14:57 ` [PATCH v3 17/17] Documentation: ACPI for ARM64 Hanjun Guo
2014-09-11 13:29 ` [PATCH v3 00/17] Introduce ACPI for ARM64 based on ACPI 5.1 Grant Likely
2014-09-11 13:49 ` Will Deacon
2014-09-12 21:38 ` Jon Masters
2014-09-12 21:43 ` Jon Masters
2014-09-15 4:21 ` Grant Likely
2014-09-11 14:23 ` Rafael J. Wysocki
2014-09-11 14:04 ` Grant Likely
2014-09-11 15:37 ` Catalin Marinas
2014-09-11 15:57 ` Sudeep Holla
2014-09-11 16:06 ` Graeme Gregory
2014-09-11 16:14 ` Sudeep Holla
2014-09-15 4:31 ` Grant Likely
2014-09-15 9:15 ` Catalin Marinas
2014-09-15 22:48 ` Grant Likely
2014-09-16 10:12 ` Catalin Marinas
2014-09-11 16:05 ` Olof Johansson
2014-09-15 4:37 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54099550.5080902@linaro.org \
--to=tomasz.nowicki@linaro.org \
--cc=Catalin.Marinas@arm.com \
--cc=Liviu.Dudau@arm.com \
--cc=Will.Deacon@arm.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=broonie@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=jason@lakedaemon.net \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=marc.zyngier@arm.com \
--cc=olof@lixom.net \
--cc=rdunlap@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=robert.moore@intel.com \
--cc=robh@kernel.org \
--cc=rric@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).