> -----Original Message-----
> From: Lorenzo Pieralisi <[email protected]>
> Sent: Friday, February 14, 2020 9:50 PM
> To: Pankaj Bansal <[email protected]>
> Cc: Marc Zyngier <[email protected]>; Ard Biesheuvel
> <[email protected]>; Makarand Pawagi <[email protected]>;
> Calvin Johnson <[email protected]>; [email protected];
> [email protected]; Ioana Ciornei <[email protected]>; Cristi
> Sovaiala <[email protected]>; Hanjun Guo <[email protected]>;
> Will Deacon <[email protected]>; [email protected]; Russell King
> <[email protected]>; ACPI Devel Maling List <[email protected]>;
> Len Brown <[email protected]>; Jason Cooper <[email protected]>; Andy
> Wang <[email protected]>; Varun Sethi <[email protected]>; Thomas
> Gleixner <[email protected]>; linux-arm-kernel <linux-arm-
> [email protected]>; Laurentiu Tudor <[email protected]>; Paul
> Yang <[email protected]>; [email protected]; Rafael J. Wysocki
> <[email protected]>; Linux Kernel Mailing List <[email protected]>;
> Shameerali Kolothum Thodi <[email protected]>;
> Sudeep Holla <[email protected]>; Robin Murphy
> <[email protected]>
> Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
>
> On Fri, Feb 14, 2020 at 03:58:14PM +0000, Pankaj Bansal wrote:
>
> [...]
>
> > > Why should the device know about its own ID? That's a bus/interconnect
> thing.
> > > And nothing should be passed *to* IORT. IORT is the source.
> >
> > IORT is translation between Input IDs <-> Output IDs. The Input ID is still
> expected to be passed to parse IORT table.
>
> Named components use an array of single mappings (as in entries with single
> mapping flag set) - Input ID is irrelevant.
>
> Not sure what your named component is though and what you want to do with
> it, the fact that IORT allows mapping for named components do not necessarily
> mean that it can describe what your system really is, on that you need to
> elaborate for us to be able to help.
Details about MC bus can be read from here:
https://elixir.bootlin.com/linux/latest/source/Documentation/networking/device_drivers/freescale/dpaa2/overview.rst#L324
As stated above, in Linux MC is a bus (just like PCI bus, AMBA bus etc)
There can be multiple devices attached to this bus. Moreover, we can dynamically create/destroy these devices.
Now, we want to represent this BUS (not individual devices connected to bus) in IORT table.
The only possible way right now we see is that we describe it as Named components having a pool of ID mappings.
As and when devices are created and attached to bus, we sift through this pool to correctly determine the output ID for the device.
Now the input ID that we provide, can come from device itself.
Then we can use the Platform MSI framework for MC bus devices.
>
> Lorenzo
On Fri, Feb 14, 2020 at 04:35:10PM +0000, Pankaj Bansal wrote:
[...]
> > -----Original Message-----
> > From: Lorenzo Pieralisi <[email protected]>
> > Sent: Friday, February 14, 2020 9:50 PM
> > To: Pankaj Bansal <[email protected]>
> > Cc: Marc Zyngier <[email protected]>; Ard Biesheuvel
> > <[email protected]>; Makarand Pawagi <[email protected]>;
> > Calvin Johnson <[email protected]>; [email protected];
> > [email protected]; Ioana Ciornei <[email protected]>; Cristi
> > Sovaiala <[email protected]>; Hanjun Guo <[email protected]>;
> > Will Deacon <[email protected]>; [email protected]; Russell King
> > <[email protected]>; ACPI Devel Maling List <[email protected]>;
> > Len Brown <[email protected]>; Jason Cooper <[email protected]>; Andy
> > Wang <[email protected]>; Varun Sethi <[email protected]>; Thomas
> > Gleixner <[email protected]>; linux-arm-kernel <linux-arm-
> > [email protected]>; Laurentiu Tudor <[email protected]>; Paul
> > Yang <[email protected]>; [email protected]; Rafael J. Wysocki
> > <[email protected]>; Linux Kernel Mailing List <[email protected]>;
> > Shameerali Kolothum Thodi <[email protected]>;
> > Sudeep Holla <[email protected]>; Robin Murphy
> > <[email protected]>
> > Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Side note: would you mind removing the email headers (as above) in your
replies please ?
> > On Fri, Feb 14, 2020 at 03:58:14PM +0000, Pankaj Bansal wrote:
> >
> > [...]
> >
> > > > Why should the device know about its own ID? That's a bus/interconnect
> > thing.
> > > > And nothing should be passed *to* IORT. IORT is the source.
> > >
> > > IORT is translation between Input IDs <-> Output IDs. The Input ID is still
> > expected to be passed to parse IORT table.
> >
> > Named components use an array of single mappings (as in entries with single
> > mapping flag set) - Input ID is irrelevant.
> >
> > Not sure what your named component is though and what you want to do with
> > it, the fact that IORT allows mapping for named components do not necessarily
> > mean that it can describe what your system really is, on that you need to
> > elaborate for us to be able to help.
>
> Details about MC bus can be read from here:
> https://elixir.bootlin.com/linux/latest/source/Documentation/networking/device_drivers/freescale/dpaa2/overview.rst#L324
>
> As stated above, in Linux MC is a bus (just like PCI bus, AMBA bus etc)
> There can be multiple devices attached to this bus. Moreover, we can dynamically create/destroy these devices.
> Now, we want to represent this BUS (not individual devices connected to bus) in IORT table.
> The only possible way right now we see is that we describe it as Named components having a pool of ID mappings.
> As and when devices are created and attached to bus, we sift through this pool to correctly determine the output ID for the device.
> Now the input ID that we provide, can come from device itself.
> Then we can use the Platform MSI framework for MC bus devices.
So are you asking me if that's OK ? Or there is something you can't
describe with IORT ?
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 ?
I *think* you have a specific API to allocate MSIs for MC devices:
fsl_mc_msi_domain_alloc_irqs()
which hook into the IRQ domain created in the file above that handles
the cascading to an ITS domain, correct ?
Thanks,
Lorenzo
> -----Original Message-----
> From: Lorenzo Pieralisi <[email protected]>
> Sent: Friday, February 14, 2020 11:20 PM
> To: Pankaj Bansal <[email protected]>
> Cc: Marc Zyngier <[email protected]>; Ard Biesheuvel
> <[email protected]>; Makarand Pawagi <[email protected]>;
> Calvin Johnson <[email protected]>; [email protected];
> [email protected]; Ioana Ciornei <[email protected]>; Cristi
> Sovaiala <[email protected]>; Hanjun Guo <[email protected]>;
> Will Deacon <[email protected]>; [email protected]; Russell King
> <[email protected]>; ACPI Devel Maling List <[email protected]>;
> Len Brown <[email protected]>; Jason Cooper <[email protected]>; Andy
> Wang <[email protected]>; Varun Sethi <[email protected]>; Thomas
> Gleixner <[email protected]>; linux-arm-kernel <linux-arm-
> [email protected]>; Laurentiu Tudor <[email protected]>; Paul
> Yang <[email protected]>; [email protected]; Rafael J. Wysocki
> <[email protected]>; Linux Kernel Mailing List <[email protected]>;
> Shameerali Kolothum Thodi <[email protected]>;
> Sudeep Holla <[email protected]>; Robin Murphy
> <[email protected]>
> Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
>
> On Fri, Feb 14, 2020 at 04:35:10PM +0000, Pankaj Bansal wrote:
>
> [...]
>
> > > -----Original Message-----
> > > From: Lorenzo Pieralisi <[email protected]>
> > > Sent: Friday, February 14, 2020 9:50 PM
> > > To: Pankaj Bansal <[email protected]>
> > > Cc: Marc Zyngier <[email protected]>; Ard Biesheuvel
> > > <[email protected]>; Makarand Pawagi
> <[email protected]>;
> > > Calvin Johnson <[email protected]>; [email protected];
> > > [email protected]; Ioana Ciornei <[email protected]>; Cristi
> > > Sovaiala <[email protected]>; Hanjun Guo
> <[email protected]>;
> > > Will Deacon <[email protected]>; [email protected]; Russell King
> > > <[email protected]>; ACPI Devel Maling List <linux-
> [email protected]>;
> > > Len Brown <[email protected]>; Jason Cooper <[email protected]>;
> Andy
> > > Wang <[email protected]>; Varun Sethi <[email protected]>; Thomas
> > > Gleixner <[email protected]>; linux-arm-kernel <linux-arm-
> > > [email protected]>; Laurentiu Tudor <[email protected]>;
> Paul
> > > Yang <[email protected]>; [email protected]; Rafael J. Wysocki
> > > <[email protected]>; Linux Kernel Mailing List <linux-
> [email protected]>;
> > > Shameerali Kolothum Thodi <[email protected]>;
> > > Sudeep Holla <[email protected]>; Robin Murphy
> > > <[email protected]>
> > > Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
> Side note: would you mind removing the email headers (as above) in your
> replies please ?
>
> > > On Fri, Feb 14, 2020 at 03:58:14PM +0000, Pankaj Bansal wrote:
> > >
> > > [...]
> > >
> > > > > Why should the device know about its own ID? That's a bus/interconnect
> > > thing.
> > > > > And nothing should be passed *to* IORT. IORT is the source.
> > > >
> > > > IORT is translation between Input IDs <-> Output IDs. The Input ID is still
> > > expected to be passed to parse IORT table.
> > >
> > > Named components use an array of single mappings (as in entries with single
> > > mapping flag set) - Input ID is irrelevant.
> > >
> > > Not sure what your named component is though and what you want to do
> with
> > > it, the fact that IORT allows mapping for named components do not
> necessarily
> > > mean that it can describe what your system really is, on that you need to
> > > elaborate for us to be able to help.
> >
> > Details about MC bus can be read from here:
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.boo
> tlin.com%2Flinux%2Flatest%2Fsource%2FDocumentation%2Fnetworking%2Fdev
> ice_drivers%2Ffreescale%2Fdpaa2%2Foverview.rst%23L324&data=02%7C0
> 1%7Cpankaj.bansal%40nxp.com%7Cf1bcfc907a42463b617408d7b1764f0f%7C6
> 86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637172993997763634&am
> p;sdata=fPcC2UfsHoS25oYGmxJmsbPXxb1brKxP1i2qJfPdRpk%3D&reserved
> =0
> >
> > As stated above, in Linux MC is a bus (just like PCI bus, AMBA bus etc)
> > There can be multiple devices attached to this bus. Moreover, we can
> dynamically create/destroy these devices.
> > Now, we want to represent this BUS (not individual devices connected to bus)
> in IORT table.
> > The only possible way right now we see is that we describe it as Named
> components having a pool of ID mappings.
> > As and when devices are created and attached to bus, we sift through this pool
> to correctly determine the output ID for the device.
> > Now the input ID that we provide, can come from device itself.
> > Then we can use the Platform MSI framework for MC bus devices.
>
> So are you asking me if that's OK ? Or there is something you can't
> describe with IORT ?
I am asking if that would be acceptable?
i.e. we represent MC bus as Named component is IORT table with a pool of IDs (without single ID mapping flag)
and then we use the Platform MSI framework for all children devices of MC bus.
Note that it would require the Platform MSI layer to correctly pass an input id for a platform device to IORT layer.
And IORT layer ought to retrieve the output id based on single ID mapping flag as well as input id.
>
> 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.
The domain creation is handled in drivers/bus/fsl-mc/fsl-mc-msi.c
>
> I *think* you have a specific API to allocate MSIs for MC devices:
>
> fsl_mc_msi_domain_alloc_irqs()
>
> which hook into the IRQ domain created in the file above that handles
> the cascading to an ITS domain, correct ?
We associate the above created domain with dpaa2 device here:
https://elixir.bootlin.com/linux/latest/source/drivers/bus/fsl-mc/dprc-driver.c#L640
Then fsl_mc_msi_domain_alloc_irqs, retrieves the domain associated with device and calls the msi_prepare
API from its_fsl_mc_msi_prepare.
>
> Thanks,
> Lorenzo
On Mon, Feb 17, 2020 at 12:35:12PM +0000, Pankaj Bansal wrote:
>
>
> > -----Original Message-----
> > From: Lorenzo Pieralisi <[email protected]>
> > Sent: Friday, February 14, 2020 11:20 PM
> > To: Pankaj Bansal <[email protected]>
> > Cc: Marc Zyngier <[email protected]>; Ard Biesheuvel
> > <[email protected]>; Makarand Pawagi <[email protected]>;
> > Calvin Johnson <[email protected]>; [email protected];
> > [email protected]; Ioana Ciornei <[email protected]>; Cristi
> > Sovaiala <[email protected]>; Hanjun Guo <[email protected]>;
> > Will Deacon <[email protected]>; [email protected]; Russell King
> > <[email protected]>; ACPI Devel Maling List <[email protected]>;
> > Len Brown <[email protected]>; Jason Cooper <[email protected]>; Andy
> > Wang <[email protected]>; Varun Sethi <[email protected]>; Thomas
> > Gleixner <[email protected]>; linux-arm-kernel <linux-arm-
> > [email protected]>; Laurentiu Tudor <[email protected]>; Paul
> > Yang <[email protected]>; [email protected]; Rafael J. Wysocki
> > <[email protected]>; Linux Kernel Mailing List <[email protected]>;
> > Shameerali Kolothum Thodi <[email protected]>;
> > Sudeep Holla <[email protected]>; Robin Murphy
> > <[email protected]>
> > Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
> >
> > On Fri, Feb 14, 2020 at 04:35:10PM +0000, Pankaj Bansal wrote:
> >
> > [...]
> >
> > > > -----Original Message-----
> > > > From: Lorenzo Pieralisi <[email protected]>
> > > > Sent: Friday, February 14, 2020 9:50 PM
> > > > To: Pankaj Bansal <[email protected]>
> > > > Cc: Marc Zyngier <[email protected]>; Ard Biesheuvel
> > > > <[email protected]>; Makarand Pawagi
> > <[email protected]>;
> > > > Calvin Johnson <[email protected]>; [email protected];
> > > > [email protected]; Ioana Ciornei <[email protected]>; Cristi
> > > > Sovaiala <[email protected]>; Hanjun Guo
> > <[email protected]>;
> > > > Will Deacon <[email protected]>; [email protected]; Russell King
> > > > <[email protected]>; ACPI Devel Maling List <linux-
> > [email protected]>;
> > > > Len Brown <[email protected]>; Jason Cooper <[email protected]>;
> > Andy
> > > > Wang <[email protected]>; Varun Sethi <[email protected]>; Thomas
> > > > Gleixner <[email protected]>; linux-arm-kernel <linux-arm-
> > > > [email protected]>; Laurentiu Tudor <[email protected]>;
> > Paul
> > > > Yang <[email protected]>; [email protected]; Rafael J. Wysocki
> > > > <[email protected]>; Linux Kernel Mailing List <linux-
> > [email protected]>;
> > > > Shameerali Kolothum Thodi <[email protected]>;
> > > > Sudeep Holla <[email protected]>; Robin Murphy
> > > > <[email protected]>
> > > > Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
> > Side note: would you mind removing the email headers (as above) in your
> > replies please ?
Read the question above please.
[...]
> > > As stated above, in Linux MC is a bus (just like PCI bus, AMBA bus etc)
> > > There can be multiple devices attached to this bus. Moreover, we can
> > dynamically create/destroy these devices.
> > > Now, we want to represent this BUS (not individual devices connected to bus)
> > in IORT table.
> > > The only possible way right now we see is that we describe it as Named
> > components having a pool of ID mappings.
> > > As and when devices are created and attached to bus, we sift through this pool
> > to correctly determine the output ID for the device.
> > > Now the input ID that we provide, can come from device itself.
> > > Then we can use the Platform MSI framework for MC bus devices.
> >
> > So are you asking me if that's OK ? Or there is something you can't
> > describe with IORT ?
>
> I am asking if that would be acceptable?
> i.e. we represent MC bus as Named component is IORT table with a pool of IDs (without single ID mapping flag)
> and then we use the Platform MSI framework for all children devices of MC bus.
> Note that it would require the Platform MSI layer to correctly pass an input id for a platform device to IORT layer.
How is this solved in DT ? You don't seem to need any DT binding on top
of the msi-parent property, which is equivalent to IORT single mappings
AFAICS so I would like to understand the whole DT flow (so that I
understand how this FSL bus works) before commenting any further.
> And IORT layer ought to retrieve the output id based on single ID mapping flag as well as input id.
>
> >
> > 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.
> The domain creation is handled in drivers/bus/fsl-mc/fsl-mc-msi.c
Thanks,
Lorenzo
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...
On Mon, Feb 17, 2020 at 03:35:01PM +0000, Marc Zyngier wrote:
> 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.
Yes I see, it is not trivial - I just raised the point while reading the
code to understand how the IRQ domain structures are connected in the DT
bootstrap case, I don't think that's an urgent issue to solve, just
noticed and reported it to make sure you are aware.
Thanks !
Lorenzo
> -----Original Message-----
> From: Lorenzo Pieralisi <[email protected]>
> Sent: Monday, February 17, 2020 8:55 PM
> To: Pankaj Bansal <[email protected]>
> Cc: Marc Zyngier <[email protected]>; Ard Biesheuvel
> <[email protected]>; Makarand Pawagi <[email protected]>;
> Calvin Johnson <[email protected]>; [email protected];
> [email protected]; Ioana Ciornei <[email protected]>; Cristi
> Sovaiala <[email protected]>; Hanjun Guo <[email protected]>;
> Will Deacon <[email protected]>; [email protected]; Russell King
> <[email protected]>; ACPI Devel Maling List <[email protected]>;
> Len Brown <[email protected]>; Jason Cooper <[email protected]>; Andy
> Wang <[email protected]>; Varun Sethi <[email protected]>; Thomas
> Gleixner <[email protected]>; linux-arm-kernel <linux-arm-
> [email protected]>; Laurentiu Tudor <[email protected]>; Paul
> Yang <[email protected]>; [email protected]; Rafael J. Wysocki
> <[email protected]>; Linux Kernel Mailing List <[email protected]>;
> Shameerali Kolothum Thodi <[email protected]>;
> Sudeep Holla <[email protected]>; Robin Murphy
> <[email protected]>
> Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
>
> On Mon, Feb 17, 2020 at 12:35:12PM +0000, Pankaj Bansal wrote:
> >
> >
> > > -----Original Message-----
> > > From: Lorenzo Pieralisi <[email protected]>
> > > Sent: Friday, February 14, 2020 11:20 PM
> > > To: Pankaj Bansal <[email protected]>
> > > Cc: Marc Zyngier <[email protected]>; Ard Biesheuvel
> > > <[email protected]>; Makarand Pawagi
> <[email protected]>;
> > > Calvin Johnson <[email protected]>; [email protected];
> > > [email protected]; Ioana Ciornei <[email protected]>; Cristi
> > > Sovaiala <[email protected]>; Hanjun Guo
> <[email protected]>;
> > > Will Deacon <[email protected]>; [email protected]; Russell King
> > > <[email protected]>; ACPI Devel Maling List <linux-
> [email protected]>;
> > > Len Brown <[email protected]>; Jason Cooper <[email protected]>;
> Andy
> > > Wang <[email protected]>; Varun Sethi <[email protected]>; Thomas
> > > Gleixner <[email protected]>; linux-arm-kernel <linux-arm-
> > > [email protected]>; Laurentiu Tudor <[email protected]>;
> Paul
> > > Yang <[email protected]>; [email protected]; Rafael J. Wysocki
> > > <[email protected]>; Linux Kernel Mailing List <linux-
> [email protected]>;
> > > Shameerali Kolothum Thodi <[email protected]>;
> > > Sudeep Holla <[email protected]>; Robin Murphy
> > > <[email protected]>
> > > Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
> > >
> > > On Fri, Feb 14, 2020 at 04:35:10PM +0000, Pankaj Bansal wrote:
> > >
> > > [...]
> > >
> > > > > -----Original Message-----
> > > > > From: Lorenzo Pieralisi <[email protected]>
> > > > > Sent: Friday, February 14, 2020 9:50 PM
> > > > > To: Pankaj Bansal <[email protected]>
> > > > > Cc: Marc Zyngier <[email protected]>; Ard Biesheuvel
> > > > > <[email protected]>; Makarand Pawagi
> > > <[email protected]>;
> > > > > Calvin Johnson <[email protected]>; [email protected];
> > > > > [email protected]; Ioana Ciornei <[email protected]>; Cristi
> > > > > Sovaiala <[email protected]>; Hanjun Guo
> > > <[email protected]>;
> > > > > Will Deacon <[email protected]>; [email protected]; Russell King
> > > > > <[email protected]>; ACPI Devel Maling List <linux-
> > > [email protected]>;
> > > > > Len Brown <[email protected]>; Jason Cooper <[email protected]>;
> > > Andy
> > > > > Wang <[email protected]>; Varun Sethi <[email protected]>;
> Thomas
> > > > > Gleixner <[email protected]>; linux-arm-kernel <linux-arm-
> > > > > [email protected]>; Laurentiu Tudor
> <[email protected]>;
> > > Paul
> > > > > Yang <[email protected]>; [email protected]; Rafael J. Wysocki
> > > > > <[email protected]>; Linux Kernel Mailing List <linux-
> > > [email protected]>;
> > > > > Shameerali Kolothum Thodi <[email protected]>;
> > > > > Sudeep Holla <[email protected]>; Robin Murphy
> > > > > <[email protected]>
> > > > > Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
> > > Side note: would you mind removing the email headers (as above) in your
> > > replies please ?
>
> Read the question above please.
>
> [...]
>
> > > > As stated above, in Linux MC is a bus (just like PCI bus, AMBA bus etc)
> > > > There can be multiple devices attached to this bus. Moreover, we can
> > > dynamically create/destroy these devices.
> > > > Now, we want to represent this BUS (not individual devices connected to
> bus)
> > > in IORT table.
> > > > The only possible way right now we see is that we describe it as Named
> > > components having a pool of ID mappings.
> > > > As and when devices are created and attached to bus, we sift through this
> pool
> > > to correctly determine the output ID for the device.
> > > > Now the input ID that we provide, can come from device itself.
> > > > Then we can use the Platform MSI framework for MC bus devices.
> > >
> > > So are you asking me if that's OK ? Or there is something you can't
> > > describe with IORT ?
> >
> > I am asking if that would be acceptable?
> > i.e. we represent MC bus as Named component is IORT table with a pool of IDs
> (without single ID mapping flag)
> > and then we use the Platform MSI framework for all children devices of MC
> bus.
> > Note that it would require the Platform MSI layer to correctly pass an input id
> for a platform device to IORT layer.
>
> How is this solved in DT ? You don't seem to need any DT binding on top
> of the msi-parent property, which is equivalent to IORT single mappings
> AFAICS so I would like to understand the whole DT flow (so that I
> understand how this FSL bus works) before commenting any further.
In DT case, we create the domain DOMAIN_BUS_FSL_MC_MSI for MC bus and it's children.
And then when MC child device is created, we search the "msi-parent" property from the MC
DT node and get the ITS associated with MC bus. Then we search DOMAIN_BUS_FSL_MC_MSI
on that ITS. Once we find the domain, we can call msi_domain_alloc_irqs for that domain.
This is exactly what we tried to do initially with ACPI. But the searching DOMAIN_BUS_FSL_MC_MSI
associated to an ITS, is something that is part of drivers/acpi/arm64/iort.c.
(similar to DOMAIN_BUS_PLATFORM_MSI and DOMAIN_BUS_PCI_MSI)
>
> > And IORT layer ought to retrieve the output id based on single ID mapping flag
> as well as input id.
> >
> > >
> > > 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.
>
> > The domain creation is handled in drivers/bus/fsl-mc/fsl-mc-msi.c
>
> Thanks,
> Lorenzo