-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Friday, February 14, 2020 11:20 PM
To: Pankaj Bansal <redacted>
Cc: Marc Zyngier <maz@kernel.org>; Ard Biesheuvel
[off-list ref]; Makarand Pawagi [off-list ref];
Calvin Johnson [off-list ref]; stuyoder@gmail.com;
nleeder@codeaurora.org; Ioana Ciornei [off-list ref]; Cristi
Sovaiala [off-list ref]; Hanjun Guo [off-list ref];
Will Deacon [off-list ref]; jon@solid-run.com; Russell King
[off-list ref]; ACPI Devel Maling List [off-list ref];
Len Brown [off-list ref]; Jason Cooper [off-list ref]; Andy
Wang [off-list ref]; Varun Sethi [off-list ref]; Thomas
Gleixner [off-list ref]; linux-arm-kernel <linux-arm-
kernel@lists.infradead.org>; Laurentiu Tudor [off-list ref]; Paul
Yang [off-list ref]; netdev@vger.kernel.org; Rafael J. Wysocki
[off-list ref]; Linux Kernel Mailing List [off-list ref];
Shameerali Kolothum Thodi [off-list ref];
Sudeep Holla [off-list ref]; Robin Murphy
[off-list ref]
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:

[...]

quoted

quoted

-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Friday, February 14, 2020 9:50 PM
To: Pankaj Bansal <redacted>
Cc: Marc Zyngier <maz@kernel.org>; Ard Biesheuvel
[off-list ref]; Makarand Pawagi

[off-list ref];

quoted

quoted

Calvin Johnson [off-list ref]; stuyoder@gmail.com;
nleeder@codeaurora.org; Ioana Ciornei [off-list ref]; Cristi
Sovaiala [off-list ref]; Hanjun Guo

[off-list ref];

quoted

quoted

Will Deacon [off-list ref]; jon@solid-run.com; Russell King
[off-list ref]; ACPI Devel Maling List <linux-

acpi@vger.kernel.org>;

quoted

quoted

Len Brown [off-list ref]; Jason Cooper [off-list ref];

Andy

quoted

quoted

Wang [off-list ref]; Varun Sethi [off-list ref]; Thomas
Gleixner [off-list ref]; linux-arm-kernel <linux-arm-
kernel@lists.infradead.org>; Laurentiu Tudor [off-list ref];

Paul

quoted

quoted

Yang [off-list ref]; netdev@vger.kernel.org; Rafael J. Wysocki
[off-list ref]; Linux Kernel Mailing List <linux-

kernel@vger.kernel.org>;

quoted

quoted

Shameerali Kolothum Thodi [off-list ref];
Sudeep Holla [off-list ref]; Robin Murphy
[off-list ref]
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 ?

quoted

quoted

On Fri, Feb 14, 2020 at 03:58:14PM +0000, Pankaj Bansal wrote:

[...]

quoted

quoted

Why should the device know about its own ID? That's a bus/interconnect

thing.

quoted

quoted

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

quoted

quoted

it, the fact that IORT allows mapping for named components do not

necessarily

quoted

quoted

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

quoted

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.

quoted

Now, we want to represent this BUS (not individual devices connected to bus)

in IORT table.

quoted

The only possible way right now we see is that we describe it as Named

components having a pool of ID mappings.

quoted

As and when devices are created and attached to bus, we sift through this pool

to correctly determine the output ID for the device.

quoted

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