[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <384eb5378ee2b240d6ab7d89aef2d5c7@kernel.org>
Date: Mon, 17 Feb 2020 15:35:01 +0000
From: Marc Zyngier <maz@...nel.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Cc: Pankaj Bansal <pankaj.bansal@....com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Makarand Pawagi <makarand.pawagi@....com>,
Calvin Johnson <calvin.johnson@....com>, stuyoder@...il.com,
nleeder@...eaurora.org, Ioana Ciornei <ioana.ciornei@....com>,
Cristi Sovaiala <cristian.sovaiala@....com>,
Hanjun Guo <guohanjun@...wei.com>,
Will Deacon <will@...nel.org>, jon@...id-run.com,
Russell King <linux@...linux.org.uk>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Len Brown <lenb@...nel.org>,
Jason Cooper <jason@...edaemon.net>,
Andy Wang <Andy.Wang@....com>, Varun Sethi <V.Sethi@....com>,
Thomas Gleixner <tglx@...utronix.de>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Laurentiu Tudor <laurentiu.tudor@....com>,
Paul Yang <Paul.Yang@....com>, netdev@...r.kernel.org,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Shameerali Kolothum Thodi
<shameerali.kolothum.thodi@...wei.com>,
Sudeep Holla <sudeep.holla@....com>,
Robin Murphy <robin.murphy@....com>
Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
On 2020-02-17 15:25, Lorenzo Pieralisi wrote:
> On Mon, Feb 17, 2020 at 12:35:12PM +0000, Pankaj Bansal wrote:
Hi Lorenzo,
[...]
>> > Side note: can you explain to me please how the MSI allocation flow
>> > and kernel data structures/drivers are modeled in DT ? I had a quick
>> > look at:
>> >
>> > drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
>> >
>> > and to start with, does that code imply that we create a
>> > DOMAIN_BUS_FSL_MC_MSI on ALL DT systems with an ITS device node ?
>>
>> Yes. It's being done for all DT systems having ITS node.
>
> This does not seem correct to me, I will let Marc comment on
> the matter.
Unfortunately, there isn't a very good way to avoid that ATM,
other than defering the registration of the irqdomain until
we know that a particular bus (for example a PCIe RC) is registered.
I started working on that at some point, and ended up nowhere because
no bus (PCI, FSL, or anything else) really give us the right information
when it is actually required (when a device starts claiming interrupts).
I *think* we could try a defer it until a bus root is found, and that
this bus has a topological link to an ITS. probably invasive though,
as you would need a set of "MSI providers" for each available irqchip
node.
In short, messy. But I'd be happy to revive this and have a look again.
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists