Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1370462 > unrolled thread

[PATCH V4 0/7] Introduce ACPI world to ITS irqchip

Started byTomasz Nowicki <tn@semihalf.com>
First post2016-04-04 11:00 +0200
Last post2016-04-12 09:40 +0200
Articles 5 on this page of 25 — 4 participants

Back to article view | Back to linux.kernel

Contents

  [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

Page 2 of 2 — ← Prev page 1 [2]

#1378710 — Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support.

Fromokaya@codeaurora.org
Date2016-04-14 13:40 +0200
SubjectRe: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support.
Message-ID<rnNMS-Ww-25@gated-at.bofh.it>
In reply to#1378553
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.

[toc] | [prev] | [next] | [standalone]

#1378712 — Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support.

FromMarc Zyngier <marc.zyngier@arm.com>
Date2016-04-14 13:50 +0200
SubjectRe: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support.
Message-ID<rnNWy-10h-5@gated-at.bofh.it>
In reply to#1378710
On 14/04/16 12:37, okaya@codeaurora.org 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...

[toc] | [prev] | [next] | [standalone]

#1378554 — Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support.

FromTomasz Nowicki <tn@semihalf.com>
Date2016-04-14 09:40 +0200
SubjectRe: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support.
Message-ID<rnK2C-6Al-31@gated-at.bofh.it>
In reply to#1378065
On 13.04.2016 17:52, Marc Zyngier wrote:
> On 13/04/16 16:36, Tomasz Nowicki wrote:
>> On 13.04.2016 17:23, Marc Zyngier wrote:
>>> On 04/04/16 09:52, Tomasz Nowicki wrote:
>>>> IORT shows representation of IO topology for ARM based systems.
>>>> It describes how various components are connected together on
>>>> parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
>>>>
>>>> Initial support allows to:
>>>> - register ITS MSI chip along with ITS translation ID and domain token
>>>> - deregister ITS MSI chip based on ITS translation ID
>>>> - find registered domain token based on ITS translation ID
>>>> - map MSI RID based on PCI device and requester ID
>>>> - find domain token based on PCI device and requester ID
>>>>
>>>> To: Rafael J. Wysocki <rjw@rjwysocki.net>
>>>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>>>> ---
>>>>    drivers/acpi/Kconfig    |   3 +
>>>>    drivers/acpi/Makefile   |   1 +
>>>>    drivers/acpi/iort.c     | 335 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>    drivers/irqchip/Kconfig |   1 +
>>>>    include/linux/iort.h    |  31 +++++
>>>>    5 files changed, 371 insertions(+)
>>>>    create mode 100644 drivers/acpi/iort.c
>>>>    create mode 100644 include/linux/iort.h
>>>>
>>>
>>> [...]
>>>
>>>> +static acpi_status
>>>> +iort_find_dev_callback(struct acpi_iort_node *node, void *context)
>>>> +{
>>>> +	struct acpi_iort_root_complex *pci_rc;
>>>> +	struct device *dev = context;
>>>> +	struct pci_bus *bus;
>>>> +
>>>> +	switch (node->type) {
>>>> +	case ACPI_IORT_NODE_PCI_ROOT_COMPLEX:
>>>> +		bus = to_pci_bus(dev);
>>>> +		pci_rc = (struct acpi_iort_root_complex *)node->node_data;
>>>> +
>>>> +		/*
>>>> +		 * It is assumed that PCI segment numbers maps one-to-one
>>>> +		 * with root complexes. Each segment number can represent only
>>>> +		 * one root complex.
>>>> +		 */
>>>> +		if (pci_rc->pci_segment_number == pci_domain_nr(bus))
>>>> +			return AE_OK;
>>>
>>> What guarantees that this is ever valid? As far as I know, pci_domain_nr
>>> is completely arbitrary, and depends both on the probe order and the
>>> phase of the moon. If you want this to be reliable, you need to allocate
>>> the domain number from pci_segment_number.
>>>
>>> I must be missing something. Care to shed some light on this?
>>>
>> 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?
>

The plan is to make this series ready for being merged. Once we get PCI 
series upstream, we can just retest ITS final series and pull it in, if 
you agree. PCI domain assignment is settled so it will not be the reason 
for fundamental changes here. What do you think?

Tomasz

[toc] | [prev] | [next] | [standalone]

#1378556 — Re: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support.

FromMarc Zyngier <marc.zyngier@arm.com>
Date2016-04-14 09:50 +0200
SubjectRe: [PATCH V4 4/7] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support.
Message-ID<rnKch-6EY-3@gated-at.bofh.it>
In reply to#1378554
On 14/04/16 08:39, Tomasz Nowicki wrote:
> On 13.04.2016 17:52, Marc Zyngier wrote:
>> On 13/04/16 16:36, Tomasz Nowicki wrote:
>>> On 13.04.2016 17:23, Marc Zyngier wrote:
>>>> On 04/04/16 09:52, Tomasz Nowicki wrote:
>>>>> IORT shows representation of IO topology for ARM based systems.
>>>>> It describes how various components are connected together on
>>>>> parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
>>>>>
>>>>> Initial support allows to:
>>>>> - register ITS MSI chip along with ITS translation ID and domain token
>>>>> - deregister ITS MSI chip based on ITS translation ID
>>>>> - find registered domain token based on ITS translation ID
>>>>> - map MSI RID based on PCI device and requester ID
>>>>> - find domain token based on PCI device and requester ID
>>>>>
>>>>> To: Rafael J. Wysocki <rjw@rjwysocki.net>
>>>>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>>>>> ---
>>>>>    drivers/acpi/Kconfig    |   3 +
>>>>>    drivers/acpi/Makefile   |   1 +
>>>>>    drivers/acpi/iort.c     | 335 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>    drivers/irqchip/Kconfig |   1 +
>>>>>    include/linux/iort.h    |  31 +++++
>>>>>    5 files changed, 371 insertions(+)
>>>>>    create mode 100644 drivers/acpi/iort.c
>>>>>    create mode 100644 include/linux/iort.h
>>>>>
>>>>
>>>> [...]
>>>>
>>>>> +static acpi_status
>>>>> +iort_find_dev_callback(struct acpi_iort_node *node, void *context)
>>>>> +{
>>>>> +	struct acpi_iort_root_complex *pci_rc;
>>>>> +	struct device *dev = context;
>>>>> +	struct pci_bus *bus;
>>>>> +
>>>>> +	switch (node->type) {
>>>>> +	case ACPI_IORT_NODE_PCI_ROOT_COMPLEX:
>>>>> +		bus = to_pci_bus(dev);
>>>>> +		pci_rc = (struct acpi_iort_root_complex *)node->node_data;
>>>>> +
>>>>> +		/*
>>>>> +		 * It is assumed that PCI segment numbers maps one-to-one
>>>>> +		 * with root complexes. Each segment number can represent only
>>>>> +		 * one root complex.
>>>>> +		 */
>>>>> +		if (pci_rc->pci_segment_number == pci_domain_nr(bus))
>>>>> +			return AE_OK;
>>>>
>>>> What guarantees that this is ever valid? As far as I know, pci_domain_nr
>>>> is completely arbitrary, and depends both on the probe order and the
>>>> phase of the moon. If you want this to be reliable, you need to allocate
>>>> the domain number from pci_segment_number.
>>>>
>>>> I must be missing something. Care to shed some light on this?
>>>>
>>> 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?
>>
> 
> The plan is to make this series ready for being merged. Once we get PCI 
> series upstream, we can just retest ITS final series and pull it in, if 
> you agree. PCI domain assignment is settled so it will not be the reason 
> for fundamental changes here. What do you think?

As long as you are making progress on the PCI front, and that we
establish that PCI must go in first, I'm OK with that.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[toc] | [prev] | [next] | [standalone]

#1376532

FromTomasz Nowicki <tn@semihalf.com>
Date2016-04-12 09:40 +0200
Message-ID<rn15v-3qc-1@gated-at.bofh.it>
In reply to#1370462
Hi Marc, Bjorn, Rafael,

Can you please have a look at this series? Thanks in advance.

Tomasz


On 04.04.2016 10:52, Tomasz Nowicki wrote:
> The following git branch contains submitted patches along with
> the useful patches from the test point of view (mainly ACPI ARM64 PCI support).
> https://github.com/semihalf-nowicki-tomasz/linux.git (its-acpi-v4)
>
> Series has been tested on Cavium ThunderX and Qualcomm QDF2xxx server.
>
> v3 -> v4
> - rebased against v4.5
> - add ACPI support for IRQ domain handling on a per-device basis
> - reorder domain setup step
> - improve error handling
> - code style improvements
>
> v2 -> v3
> - rebased on top of 4.4
> - fixes and improvements for redistributor init via GICC structures
> - fixes as per kbuild reports
>
> v1 -> v2
> - rebased on top of 4.4-rc4
> - use pci_msi_domain_get_msi_rid for requester ID to device ID translation
>
> Tomasz Nowicki (7):
>    acpi, pci: Setup MSI domain on a per-devices basis.
>    irqchip, GICv3, ITS: Cleanup for ITS domain initialization.
>    irqchip, GICv3, ITS: Refator ITS DT init code to prepare for ACPI.
>    ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support.
>    irqchip, gicv3, its: Probe ITS in the ACPI way.
>    its, pci, msi: Factor out code that might be reused for ACPI.
>    acpi, gicv3, its: Use MADT ITS subtable to do PCI/MSI domain
>      initialization.
>
>   drivers/acpi/Kconfig                     |   3 +
>   drivers/acpi/Makefile                    |   1 +
>   drivers/acpi/iort.c                      | 335 +++++++++++++++++++++++++++++++
>   drivers/irqchip/Kconfig                  |   1 +
>   drivers/irqchip/irq-gic-v3-its-pci-msi.c |  87 ++++++--
>   drivers/irqchip/irq-gic-v3-its.c         | 188 ++++++++++++-----
>   drivers/irqchip/irq-gic-v3.c             |   7 +-
>   drivers/pci/msi.c                        |  10 +-
>   drivers/pci/pci-acpi.c                   |  77 +++++++
>   include/linux/iort.h                     |  31 +++
>   include/linux/irqchip/arm-gic-v3.h       |   2 +-
>   include/linux/pci.h                      |  11 +
>   12 files changed, 678 insertions(+), 75 deletions(-)
>   create mode 100644 drivers/acpi/iort.c
>   create mode 100644 include/linux/iort.h
>

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web