> >>>>> 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) > > 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
