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

Groups > linux.kernel > #1320568 > unrolled thread

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

Started byMark Rutland <mark.rutland@arm.com>
First post2016-01-28 12:20 +0100
Last post2016-01-28 15:30 +0100
Articles 4 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node Mark Rutland <mark.rutland@arm.com> - 2016-01-28 12:20 +0100
    Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node Robin Murphy <robin.murphy@arm.com> - 2016-01-28 13:30 +0100
      Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node Arnd Bergmann <arnd@arndb.de> - 2016-01-28 15:20 +0100
        Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node Will Deacon <will.deacon@arm.com> - 2016-01-28 15:30 +0100

#1320568 — Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

FromMark Rutland <mark.rutland@arm.com>
Date2016-01-28 12:20 +0100
SubjectRe: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
Message-ID<qVSMh-2B1-5@gated-at.bofh.it>
On Wed, Jan 27, 2016 at 03:11:59PM -0600, Suravee Suthikulpanit wrote:
> From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> 
> Add PCIe SMMU device tree node for AMD Seattle SOC.
> 
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> ---
>  arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> index a7fc059..bfccfea 100644
> --- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> +++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> @@ -210,6 +210,7 @@
>  			device_type = "pci";
>  			bus-range = <0 0x7f>;
>  			msi-parent = <&v2m0>;
> +			#stream-id-cells = <16>;
>  			reg = <0 0xf0000000 0 0x10000000>;
>  
>  			interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> @@ -230,6 +231,28 @@
>  				<0x03000000 0x01 0x00000000 0x01 0x00000000 0x7f 0x00000000>;
>  		};
>  
> +		pcie0_smmu: smmu@e0a00000 {
> +			 compatible = "arm,mmu-401";
> +			 reg = <0 0xe0a00000 0 0x10000>;
> +			 #global-interrupts = <1>;
> +			 interrupts = /* Uses combined intr for both
> +				       * global and context
> +				       */
> +				      <0 333 4>,
> +				      <0 333 4>;
> +			/* Note:
> +			 * SID[2:0]  = PCIe function number
> +			 * SID[7:3]  = PCIe device number
> +			 * SID[14:8] = PCIe bus number
> +			 */
> +			 mmu-masters = <&pcie0
> +				/* 1:00:[0,3] */ 256 257 258 259
> +				/* 2:00:[0,3] */ 512 513 514 515
> +				/* 3:00:[0,3] */ 768 769 770 771
> +				/* 4:00:[0,3] */ 1024 1025 1026 1027
> +			 >;
> +		 };

This doesn't look right to me.

I didn't think that RID->SID mapping was actually defined by any
binding, so (how) are these numbers used?

I'm uncomfortable with this, given we should be moving towards the
generic IOMMU binding (and then we'd use the iommu-map binding [1] for
this).

Will, Robin, thoughts?

Mark.

[1] https://lkml.org/lkml/2015/7/23/561

[toc] | [next] | [standalone]

#1320620

FromRobin Murphy <robin.murphy@arm.com>
Date2016-01-28 13:30 +0100
Message-ID<qVTS2-3iP-11@gated-at.bofh.it>
In reply to#1320568
On 28/01/16 11:14, Mark Rutland wrote:
> On Wed, Jan 27, 2016 at 03:11:59PM -0600, Suravee Suthikulpanit wrote:
>> From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>>
>> Add PCIe SMMU device tree node for AMD Seattle SOC.
>>
>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>> ---
>>   arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 23 +++++++++++++++++++++++
>>   1 file changed, 23 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
>> index a7fc059..bfccfea 100644
>> --- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
>> +++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
>> @@ -210,6 +210,7 @@
>>   			device_type = "pci";
>>   			bus-range = <0 0x7f>;
>>   			msi-parent = <&v2m0>;
>> +			#stream-id-cells = <16>;
>>   			reg = <0 0xf0000000 0 0x10000000>;
>>
>>   			interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
>> @@ -230,6 +231,28 @@
>>   				<0x03000000 0x01 0x00000000 0x01 0x00000000 0x7f 0x00000000>;
>>   		};
>>
>> +		pcie0_smmu: smmu@e0a00000 {
>> +			 compatible = "arm,mmu-401";
>> +			 reg = <0 0xe0a00000 0 0x10000>;
>> +			 #global-interrupts = <1>;
>> +			 interrupts = /* Uses combined intr for both
>> +				       * global and context
>> +				       */
>> +				      <0 333 4>,
>> +				      <0 333 4>;
>> +			/* Note:
>> +			 * SID[2:0]  = PCIe function number
>> +			 * SID[7:3]  = PCIe device number
>> +			 * SID[14:8] = PCIe bus number
>> +			 */
>> +			 mmu-masters = <&pcie0
>> +				/* 1:00:[0,3] */ 256 257 258 259
>> +				/* 2:00:[0,3] */ 512 513 514 515
>> +				/* 3:00:[0,3] */ 768 769 770 771
>> +				/* 4:00:[0,3] */ 1024 1025 1026 1027
>> +			 >;
>> +		 };
>
> This doesn't look right to me.
>
> I didn't think that RID->SID mapping was actually defined by any
> binding, so (how) are these numbers used?
>
> I'm uncomfortable with this, given we should be moving towards the
> generic IOMMU binding (and then we'd use the iommu-map binding [1] for
> this).
>
> Will, Robin, thoughts?

Any IDs specified here would only apply to DMA by the "platform device" 
side of the host controller itself (as would an equivalent "iommus" 
property on pcie0 once I finish the SMMUv2 generic binding support I'm 
working on). In terms of PCI devices, the "mmu-masters" property is 
overloaded such that only its existence matters, to identify that there 
_is_ a relationship between the SMMU and the PCI bus(es) behind that 
host controller.

Really, the only binding that's going to make sense for that context is 
"iommu-map". I think that should be pretty straightforward to implement 
entirely in core OF/IOMMU code - we can already figure out a device's 
DMA alias as the host controller sees it, we just need the IOMMU drivers 
to be able to then run that through an additional downstream translation 
(which would be identity-mapped by default).

Robin.

>
> Mark.
>
> [1] https://lkml.org/lkml/2015/7/23/561
>

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

#1320717

FromArnd Bergmann <arnd@arndb.de>
Date2016-01-28 15:20 +0100
Message-ID<qVVAu-4Ce-9@gated-at.bofh.it>
In reply to#1320620
On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> >
> > Will, Robin, thoughts?
> 
> Any IDs specified here would only apply to DMA by the "platform device" 
> side of the host controller itself (as would an equivalent "iommus" 
> property on pcie0 once I finish the SMMUv2 generic binding support I'm 
> working on). In terms of PCI devices, the "mmu-masters" property is 
> overloaded such that only its existence matters, to identify that there 
> _is_ a relationship between the SMMU and the PCI bus(es) behind that 
> host controller.

I wasn't aware that this was actually still specified. I had hoped
we were getting rid of mmu-masters before anyone actually started
using it, but now I see it in ns2.dtsi and fsl-ls2080a.dtsi.

Does anyone know what happened to the plan to use the iommu DT binding
for the ARM SMMU instead? Do we now have to support both ways indefinitely?

	Arnd

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

#1320722

FromWill Deacon <will.deacon@arm.com>
Date2016-01-28 15:30 +0100
Message-ID<qVVK9-4Gz-11@gated-at.bofh.it>
In reply to#1320717
On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> > >
> > > Will, Robin, thoughts?
> > 
> > Any IDs specified here would only apply to DMA by the "platform device" 
> > side of the host controller itself (as would an equivalent "iommus" 
> > property on pcie0 once I finish the SMMUv2 generic binding support I'm 
> > working on). In terms of PCI devices, the "mmu-masters" property is 
> > overloaded such that only its existence matters, to identify that there 
> > _is_ a relationship between the SMMU and the PCI bus(es) behind that 
> > host controller.
> 
> I wasn't aware that this was actually still specified. I had hoped
> we were getting rid of mmu-masters before anyone actually started
> using it, but now I see it in ns2.dtsi and fsl-ls2080a.dtsi.
> 
> Does anyone know what happened to the plan to use the iommu DT binding
> for the ARM SMMU instead? Do we now have to support both ways indefinitely?

We always did -- Seattle used the mmu-masters binding before the generic
binding even existed. Robin has been working on patches to get of_xlate
up and running, but it got held up by Laurent's series which didn't end
up going anywhere.

Will

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web