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

quoted

quoted

quoted

quoted

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)

quoted

quoted

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

quoted

quoted

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

quoted

quoted

(without single ID mapping flag)

quoted

and then we use the Platform MSI framework for all children devices of MC

bus.

quoted

Note that it would require the Platform MSI layer to correctly pass an input

id

quoted

quoted

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.

quoted

And then when MC child device is created, we search the "msi-parent"

property from the MC

quoted

DT node and get the ITS associated with MC bus. Then we search

DOMAIN_BUS_FSL_MC_MSI

quoted

on that ITS. Once we find the domain, we can call msi_domain_alloc_irqs for

that domain.

quoted

This is exactly what we tried to do initially with ACPI. But the searching

DOMAIN_BUS_FSL_MC_MSI

quoted

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)

Can you have a look at mbigen driver (drivers/irqchip/irq-mbigen.c) to see if
it helps you?

mbigen is an irq converter to convert device's wired interrupts into MSI
(connecting to ITS), which will alloc a bunch of MSIs from ITS platform MSI
domain at the setup.

Unfortunately this is not the same case as ours. As I see Hisilicon IORT table
Is using single id mapping with named components.

https://github.com/tianocore/edk2-platforms/blob/master/Silicon/Hisilicon/Hi1616/D05AcpiTables/D05Iort.asl#L300

while we are not:

https://source.codeaurora.org/external/qoriq/qoriq-components/edk2-platforms/tree/Platform/NXP/LX2160aRdbPkg/AcpiTables/Iort.aslc?h=LX2160_UEFI_ACPI_EAR1#n290

This is because as I said, we are trying to represent a bus in IORT via named components and
not individual devices connected to that bus.

Thanks
Hanjun