On 14/04/16 12:37, okaya@xxxxxxxxxxxxxx wrote: > On 2016-04-14 03:36, Marc Zyngier wrote: >> On 14/04/16 08:20, Tomasz Nowicki wrote: >>> On 13.04.2016 23:18, Sinan Kaya wrote: >>>> On 4/13/2016 11:52 AM, Marc Zyngier wrote: >>>>>>> Sure. Please see: >>>>>>> http://infocenter.arm.com/help/topic/com.arm.doc.den0049a/DEN0049A_IO_Remapping_Table.pdf >>>>>>> 3.1.1.5 PCI root complex node >>>>>>> PCI Segment number -> The PCI segment number, as in MCFG and as >>>>>>> returned by _SEG in the namespace. >>>>>>> >>>>>>> So IORT spec states that pci_segment_number corresponds to the >>>>>>> segment >>>>>>> number from MCFG table and _SEG method. Here is my patch which >>>>>>> makes >>>>>>> sure pci_domain_nr(bus) is set properly: >>>>>>> https://lkml.org/lkml/2016/2/16/418 >>>>> Lovely. So this series is actually dependent on the PCI one. I guess >>>>> we >>>>> need to solve that one first, because IORT seems pretty pointless if >>>>> we >>>>> don't have PCI support. What's the plan? >>>> >>>> Would it be OK to split the PCI specific section of the patch and >>>> continue >>>> review? PCI is a user of the IORT table. Not the other way around. >>> >>> I need to disagree. What would be the use case for patches w/o "PCI >>> part" ? >> >> Quite. PCI (as a subsystem) doesn't need IORT at all, thank you very >> much. GIC (implementing MSI) and SMMU (implementing DMA) do, by virtue >> of RID/SID/DID being translated all over the place. >> >> So by the look of it, the dependency chain is GIC+SMMU->IORT->PCI. >> >> The GIC changes here are pretty mechanical, and not that interesting. >> The stuff that needs sorting quickly is PCI, because all this work is >> pointless if we don't have it. >> >> At the risk of sounding like a stuck record: What's the plan? >> >> Thanks, >> >> M. > > My answer is based on the spec definition. The spec defines named > components for other peripherals that are behind iommu and can > potentially implement msi. > > You could have used a basic device like platform sata to take care of > basic iort and smmu support. > > You can then come back and implement PCIe support. I could. You could do it too. Thankfully, the dependency is dictated by whoever is writing the code. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
