Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1378710
| From | okaya@codeaurora.org |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support. |
| Date | 2016-04-14 13:40 +0200 |
| Message-ID | <rnNMS-Ww-25@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <rnv3A-3mt-7@gated-at.bofh.it> <rnvmW-3u7-17@gated-at.bofh.it> <rnAmC-7DR-11@gated-at.bofh.it> <rnJSW-6wh-3@gated-at.bofh.it> <rnK2C-6Al-29@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH V4 0/7] Introduce ACPI world to ITS irqchip Tomasz Nowicki <tn@semihalf.com> - 2016-04-04 11:00 +0200
[PATCH V4 7/7] acpi, gicv3, its: Use MADT ITS subtable to do PCI/MSI domain initialization. Tomasz Nowicki <tn@semihalf.com> - 2016-04-04 11:00 +0200
[PATCH V4 2/7] irqchip, GICv3, ITS: Cleanup for ITS domain initialization. Tomasz Nowicki <tn@semihalf.com> - 2016-04-04 11:00 +0200
Re: [PATCH V4 2/7] irqchip, GICv3, ITS: Cleanup for ITS domain initialization. Marc Zyngier <marc.zyngier@arm.com> - 2016-04-13 16:20 +0200
[PATCH V4 5/7] irqchip, gicv3, its: Probe ITS in the ACPI way. Tomasz Nowicki <tn@semihalf.com> - 2016-04-04 11:00 +0200
Re: [PATCH V4 5/7] irqchip, gicv3, its: Probe ITS in the ACPI way. Marc Zyngier <marc.zyngier@arm.com> - 2016-04-14 11:10 +0200
[PATCH V4 3/7] irqchip, GICv3, ITS: Refator ITS DT init code to prepare for ACPI. Tomasz Nowicki <tn@semihalf.com> - 2016-04-04 11:00 +0200
Re: [PATCH V4 3/7] irqchip, GICv3, ITS: Refator ITS DT init code to prepare for ACPI. Tomasz Nowicki <tn@semihalf.com> - 2016-04-12 12:20 +0200
Re: [PATCH V4 3/7] irqchip, GICv3, ITS: Refator ITS DT init code to prepare for ACPI. Marc Zyngier <marc.zyngier@arm.com> - 2016-04-13 17:10 +0200
[PATCH V4 6/7] its, pci, msi: Factor out code that might be reused for ACPI. Tomasz Nowicki <tn@semihalf.com> - 2016-04-04 11:00 +0200
[PATCH V4 1/7] acpi, pci: Setup MSI domain on a per-devices basis. Tomasz Nowicki <tn@semihalf.com> - 2016-04-04 11:00 +0200
Re: [PATCH V4 1/7] acpi, pci: Setup MSI domain on a per-devices basis. Marc Zyngier <marc.zyngier@arm.com> - 2016-04-13 12:20 +0200
Re: [PATCH V4 1/7] acpi, pci: Setup MSI domain on a per-devices basis. Tomasz Nowicki <tn@semihalf.com> - 2016-04-13 12:50 +0200
[PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support. Tomasz Nowicki <tn@semihalf.com> - 2016-04-04 11:00 +0200
Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support. Marc Zyngier <marc.zyngier@arm.com> - 2016-04-13 17:30 +0200
Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support. Tomasz Nowicki <tn@semihalf.com> - 2016-04-13 17:40 +0200
Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support. Marc Zyngier <marc.zyngier@arm.com> - 2016-04-13 18:00 +0200
Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support. Sinan Kaya <okaya@codeaurora.org> - 2016-04-13 23:20 +0200
Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support. Tomasz Nowicki <tn@semihalf.com> - 2016-04-14 09:30 +0200
Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support. Marc Zyngier <marc.zyngier@arm.com> - 2016-04-14 09:40 +0200
Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support. okaya@codeaurora.org - 2016-04-14 13:40 +0200
Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support. Marc Zyngier <marc.zyngier@arm.com> - 2016-04-14 13:50 +0200
Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support. Tomasz Nowicki <tn@semihalf.com> - 2016-04-14 09:40 +0200
Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support. Marc Zyngier <marc.zyngier@arm.com> - 2016-04-14 09:50 +0200
Re: [PATCH V4 0/7] Introduce ACPI world to ITS irqchip Tomasz Nowicki <tn@semihalf.com> - 2016-04-12 09:40 +0200
csiph-web