RE: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc

[Pankaj Bansal]

> -----Original Message-----
> From: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
> Sent: Friday, February 14, 2020 11:20 PM
> To: Pankaj Bansal <pankaj.bansal@xxxxxxx>
> Cc: Marc Zyngier <maz@xxxxxxxxxx>; Ard Biesheuvel
> <ard.biesheuvel@xxxxxxxxxx>; Makarand Pawagi <makarand.pawagi@xxxxxxx>;
> Calvin Johnson <calvin.johnson@xxxxxxx>; stuyoder@xxxxxxxxx;
> nleeder@xxxxxxxxxxxxxx; Ioana Ciornei <ioana.ciornei@xxxxxxx>; Cristi
> Sovaiala <cristian.sovaiala@xxxxxxx>; Hanjun Guo <guohanjun@xxxxxxxxxx>;
> Will Deacon <will@xxxxxxxxxx>; jon@xxxxxxxxxxxxx; Russell King
> <linux@xxxxxxxxxxxxxxx>; ACPI Devel Maling List <linux-acpi@xxxxxxxxxxxxxxx>;
> Len Brown <lenb@xxxxxxxxxx>; Jason Cooper <jason@xxxxxxxxxxxxxx>; Andy
> Wang <Andy.Wang@xxxxxxx>; Varun Sethi <V.Sethi@xxxxxxx>; Thomas
> Gleixner <tglx@xxxxxxxxxxxxx>; linux-arm-kernel <linux-arm-
> kernel@xxxxxxxxxxxxxxxxxxx>; Laurentiu Tudor <laurentiu.tudor@xxxxxxx>; Paul
> Yang <Paul.Yang@xxxxxxx>; netdev@xxxxxxxxxxxxxxx; Rafael J. Wysocki
> <rjw@xxxxxxxxxxxxx>; Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>;
> Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx>;
> Sudeep Holla <sudeep.holla@xxxxxxx>; Robin Murphy
> <robin.murphy@xxxxxxx>
> 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 <lorenzo.pieralisi@xxxxxxx>
> > > Sent: Friday, February 14, 2020 9:50 PM
> > > To: Pankaj Bansal <pankaj.bansal@xxxxxxx>
> > > Cc: Marc Zyngier <maz@xxxxxxxxxx>; Ard Biesheuvel
> > > <ard.biesheuvel@xxxxxxxxxx>; Makarand Pawagi
> <makarand.pawagi@xxxxxxx>;
> > > Calvin Johnson <calvin.johnson@xxxxxxx>; stuyoder@xxxxxxxxx;
> > > nleeder@xxxxxxxxxxxxxx; Ioana Ciornei <ioana.ciornei@xxxxxxx>; Cristi
> > > Sovaiala <cristian.sovaiala@xxxxxxx>; Hanjun Guo
> <guohanjun@xxxxxxxxxx>;
> > > Will Deacon <will@xxxxxxxxxx>; jon@xxxxxxxxxxxxx; Russell King
> > > <linux@xxxxxxxxxxxxxxx>; ACPI Devel Maling List <linux-
> acpi@xxxxxxxxxxxxxxx>;
> > > Len Brown <lenb@xxxxxxxxxx>; Jason Cooper <jason@xxxxxxxxxxxxxx>;
> Andy
> > > Wang <Andy.Wang@xxxxxxx>; Varun Sethi <V.Sethi@xxxxxxx>; Thomas
> > > Gleixner <tglx@xxxxxxxxxxxxx>; linux-arm-kernel <linux-arm-
> > > kernel@xxxxxxxxxxxxxxxxxxx>; Laurentiu Tudor <laurentiu.tudor@xxxxxxx>;
> Paul
> > > Yang <Paul.Yang@xxxxxxx>; netdev@xxxxxxxxxxxxxxx; Rafael J. Wysocki
> > > <rjw@xxxxxxxxxxxxx>; Linux Kernel Mailing List <linux-
> kernel@xxxxxxxxxxxxxxx>;
> > > Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx>;
> > > Sudeep Holla <sudeep.holla@xxxxxxx>; Robin Murphy
> > > <robin.murphy@xxxxxxx>
> > > 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&amp;data=02%7C0
> 1%7Cpankaj.bansal%40nxp.com%7Cf1bcfc907a42463b617408d7b1764f0f%7C6
> 86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637172993997763634&am
> p;sdata=fPcC2UfsHoS25oYGmxJmsbPXxb1brKxP1i2qJfPdRpk%3D&amp;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