[PATCH 0/2] Correct SMMU register map

[PATCH 0/2] Correct SMMU register map

[Mark Zhang]

Current SMMU register map for Tegra30 and Tegra114 doesn't
match the TRM. So set to the correct values.

Mark Zhang (2):
  ARM: tegra: Correct Tegra30 SMMU register map
  ARM: tegra: Correct Tegra114 SMMU register map

 arch/arm/boot/dts/tegra114.dtsi | 9 ++++++---
 arch/arm/boot/dts/tegra30.dtsi  | 9 ++++++---
 2 files changed, 12 insertions(+), 6 deletions(-)

-- 
1.8.1.5

[PATCH 1/2] ARM: tegra: Correct Tegra30 SMMU register map

[Mark Zhang]

Correct Tegra30 SMMU register map.

Signed-off-by: Mark Zhang <markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra30.dtsi | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 2bd55cfd88ad..5f56243cc3f5 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -527,9 +527,12 @@
 
 	iommu {
 		compatible = "nvidia,tegra30-smmu";
-		reg = <0x7000f010 0x02c
-		       0x7000f1f0 0x010
-		       0x7000f228 0x05c>;
+		reg = <0x7000f010 0x014
+		       0x7000f030 0x00c
+		       0x7000f228 0x00c
+		       0x7000f238 0x024
+		       0x7000f264 0x010
+		       0x7000f278 0x00c>;
 		nvidia,#asids = <4>;		/* # of ASIDs */
 		dma-window = <0 0x40000000>;	/* IOVA start & length */
 		nvidia,ahb = <&ahb>;
-- 
1.8.1.5

[PATCH 2/2] ARM: tegra: Correct Tegra114 SMMU register map

[Mark Zhang]

Correct Tegra114 SMMU register map.

Signed-off-by: Mark Zhang <markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra114.dtsi | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 8d42787c8ff1..c79b1813c559 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -318,9 +318,12 @@
 
 	iommu {
 		compatible = "nvidia,tegra114-smmu", "nvidia,tegra30-smmu";
-		reg = <0x70019010 0x02c
-		       0x700191f0 0x010
-		       0x70019228 0x074>;
+		reg = <0x70019010 0x014
+		       0x70019030 0x00c
+		       0x70019228 0x00c
+		       0x70019238 0x024
+		       0x70019264 0x010
+		       0x70019278 0x00c>;
 		nvidia,#asids = <4>;
 		dma-window = <0 0x40000000>;
 		nvidia,swgroups = <0x18659fe>;
-- 
1.8.1.5

Re: [PATCH 0/2] Correct SMMU register map

[Hiroshi Doyu]

Mark Zhang <markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote @ Thu, 7 Nov 2013 04:58:24 +0100:

> Current SMMU register map for Tegra30 and Tegra114 doesn't
> match the TRM. So set to the correct values.

We may need to update TRM itself. I'll check this internally.

> Mark Zhang (2):
>   ARM: tegra: Correct Tegra30 SMMU register map
>   ARM: tegra: Correct Tegra114 SMMU register map
> 
>  arch/arm/boot/dts/tegra114.dtsi | 9 ++++++---
>  arch/arm/boot/dts/tegra30.dtsi  | 9 ++++++---
>  2 files changed, 12 insertions(+), 6 deletions(-)
> 
> -- 
> 1.8.1.5
> 

Re: [PATCH 1/2] ARM: tegra: Correct Tegra30 SMMU register map

[Stephen Warren]

On 11/06/2013 08:58 PM, Mark Zhang wrote:
> Correct Tegra30 SMMU register map.

Some more explanation is required here re: why this layout is more
correct than what's there.

Do you need to edit the reg property in Tegra30's memory-controller node
too; that's what all these reg ranges are interleaved with, so
presumably if there was a mistake in the SMMU ranges, there's the
equivalent inverse mistake in the MC's ranges?

The DT binding for nvidia,tegra30-smmu states that reg should include
precisely 3 entries. This patch no longer conforms to that. The binding
needs to be re-written to explain the interleaving issue, and say that
an arbitrary number of ranges may be provided. The same issue exists in
the nvidia,tegra30-mc DT binding.

I think I'm beginning to regret separating out the MC and SMMU into
separate DT nodes:-(

Re: [PATCH 1/2] ARM: tegra: Correct Tegra30 SMMU register map

[Mark Zhang]

Hiroshi has mentioned that the TRM should be revised. :)
Because there are some registers which are needed by SMMU driver while
they're not in TRM yet.

So this patch doesn't make sense now. Thanks for the review.

Mark
On 11/13/2013 03:19 AM, Stephen Warren wrote:
> On 11/06/2013 08:58 PM, Mark Zhang wrote:
>> Correct Tegra30 SMMU register map.
> 
> Some more explanation is required here re: why this layout is more
> correct than what's there.
> 
> Do you need to edit the reg property in Tegra30's memory-controller node
> too; that's what all these reg ranges are interleaved with, so
> presumably if there was a mistake in the SMMU ranges, there's the
> equivalent inverse mistake in the MC's ranges?
> 
> The DT binding for nvidia,tegra30-smmu states that reg should include
> precisely 3 entries. This patch no longer conforms to that. The binding
> needs to be re-written to explain the interleaving issue, and say that
> an arbitrary number of ranges may be provided. The same issue exists in
> the nvidia,tegra30-mc DT binding.
> 
> I think I'm beginning to regret separating out the MC and SMMU into
> separate DT nodes:-(
> 

Re: [PATCH 1/2] ARM: tegra: Correct Tegra30 SMMU register map

[Hiroshi Doyu]

On Tue, 12 Nov 2013 20:19:04 +0100
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:

> On 11/06/2013 08:58 PM, Mark Zhang wrote:
> > Correct Tegra30 SMMU register map.
> 
> Some more explanation is required here re: why this layout is more
> correct than what's there.
> 
> Do you need to edit the reg property in Tegra30's memory-controller node
> too; that's what all these reg ranges are interleaved with, so
> presumably if there was a mistake in the SMMU ranges, there's the
> equivalent inverse mistake in the MC's ranges?
> 
> The DT binding for nvidia,tegra30-smmu states that reg should include
> precisely 3 entries. This patch no longer conforms to that. The binding
> needs to be re-written to explain the interleaving issue, and say that
> an arbitrary number of ranges may be provided. The same issue exists in
> the nvidia,tegra30-mc DT binding.
> 
> I think I'm beginning to regret separating out the MC and SMMU into
> separate DT nodes:-(

What's difficult is that how to handle the undocumented register area.
If we get rid of undocumented/reserved register area, then the number
of banks in SMMU/MC would increase unnecessarily. But practically we
can handle MC/SMMU multi register banks by just identifying MC/SMMU
portion with checking undocumented ones.