| Message ID | 20120413.132205.1766846402066131036.hdoyu@nvidia.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
* Hiroshi Doyu wrote: > From: Hiroshi DOYU <hdoyu@nvidia.com> > > Add device tree support for Tegra30 IOMMU(SMMU). > > Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com> > --- > .../devicetree/bindings/arm/tegra/tegra30-smmu.txt | 19 +++++++++++++++++++ > arch/arm/boot/dts/tegra30.dtsi | 10 ++++++++++ > 2 files changed, 29 insertions(+), 0 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/tegra/tegra30-smmu.txt b/Documentation/devicetree/bindings/arm/tegra/tegra30-smmu.txt > new file mode 100644 > index 0000000..4bd8cd0 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/tegra/tegra30-smmu.txt > @@ -0,0 +1,19 @@ > +NVIDIA Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit) > + > +Required properties: > +- compatible : "nvidia,tegra30-smmu" > +- reg : Should contain MC registers location and length > +- reg : Should contain AHB Arbitration registers and length > +- reg : Should contain virtual address space range > +- interrupts : Should contain MC General interrupt > + > +Example: > + smmu: smmu@7000f000 { > + compatible = "nvidia,tegra30-smmu"; > + reg = < 0x7000f000 0x400 /* controller registers */ > + 0x6000c000 0x150 /* AHB Arbitration registers */ > + 0x00001000 0x3ffff000 >;/* Virtual address space range > + * Exclude the 1st & last page > + */ > + interrupts = < 0 13 0x40 >; > + }; > diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi > index 62a7b39..c640a5b 100644 > --- a/arch/arm/boot/dts/tegra30.dtsi > +++ b/arch/arm/boot/dts/tegra30.dtsi > @@ -183,4 +183,14 @@ > reg = < 0x70000868 0xd0 /* Pad control registers */ > 0x70003000 0x3e0 >; /* Mux registers */ > }; > + > + smmu: smmu@7000f000 { > + compatible = "nvidia,tegra30-smmu"; > + reg = < 0x7000f000 0x400 /* controller registers */ > + 0x6000c000 0x150 /* AHB Arbitration registers */ > + 0x00001000 0x3ffff000 >;/* Virtual address space range > + * Exclude the 1st & last page > + */ > + interrupts = < 0 13 0x40 >; > + }; > }; Why is the virtual address space range limited to 1 GiB? What is the reason for the exclusion of the first and last pages? Thierry
Hi Thierry, From: Thierry Reding <thierry.reding@avionic-design.de> Subject: Re: [PATCH 1/1] arm/dts: Tegra30: Add device tree support for SMMU Date: Fri, 13 Apr 2012 13:03:32 +0200 Message-ID: <20120413110331.GA11605@avionic-0098.mockup.avionic-design.de> > * PGP Signed by an unknown key > > * Hiroshi Doyu wrote: > > From: Hiroshi DOYU <hdoyu@nvidia.com> > > > > Add device tree support for Tegra30 IOMMU(SMMU). > > > > Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com> > > --- > > .../devicetree/bindings/arm/tegra/tegra30-smmu.txt | 19 +++++++++++++++++++ > > arch/arm/boot/dts/tegra30.dtsi | 10 ++++++++++ > > 2 files changed, 29 insertions(+), 0 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/arm/tegra/tegra30-smmu.txt b/Documentation/devicetree/bindings/arm/tegra/tegra30-smmu.txt > > new file mode 100644 > > index 0000000..4bd8cd0 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/tegra/tegra30-smmu.txt > > @@ -0,0 +1,19 @@ > > +NVIDIA Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit) > > + > > +Required properties: > > +- compatible : "nvidia,tegra30-smmu" > > +- reg : Should contain MC registers location and length > > +- reg : Should contain AHB Arbitration registers and length > > +- reg : Should contain virtual address space range > > +- interrupts : Should contain MC General interrupt > > + > > +Example: > > + smmu: smmu@7000f000 { > > + compatible = "nvidia,tegra30-smmu"; > > + reg = < 0x7000f000 0x400 /* controller registers */ > > + 0x6000c000 0x150 /* AHB Arbitration registers */ > > + 0x00001000 0x3ffff000 >;/* Virtual address space range > > + * Exclude the 1st & last page > > + */ > > + interrupts = < 0 13 0x40 >; > > + }; > > diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi > > index 62a7b39..c640a5b 100644 > > --- a/arch/arm/boot/dts/tegra30.dtsi > > +++ b/arch/arm/boot/dts/tegra30.dtsi > > @@ -183,4 +183,14 @@ > > reg = < 0x70000868 0xd0 /* Pad control registers */ > > 0x70003000 0x3e0 >; /* Mux registers */ > > }; > > + > > + smmu: smmu@7000f000 { > > + compatible = "nvidia,tegra30-smmu"; > > + reg = < 0x7000f000 0x400 /* controller registers */ > > + 0x6000c000 0x150 /* AHB Arbitration registers */ > > + 0x00001000 0x3ffff000 >;/* Virtual address space range > > + * Exclude the 1st & last page > > + */ > > + interrupts = < 0 13 0x40 >; > > + }; > > }; > > Why is the virtual address space range limited to 1 GiB? What is the reason > for the exclusion of the first and last pages? It's because physical RAM is located 2-4GB, and we may want to use those area 1-1(V==P) mapping in some cases. This could be extended with larger RAM without 1-1 mapping theoretically. So far 1GB seems to be enough. The 1st page for AVP vector, and the last one is required by another H/W entity. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Hiroshi Doyu wrote: > Thierry Reding wrote: > > * Hiroshi Doyu wrote: > > > + smmu: smmu@7000f000 { > > > + compatible = "nvidia,tegra30-smmu"; > > > + reg = < 0x7000f000 0x400 /* controller registers */ > > > + 0x6000c000 0x150 /* AHB Arbitration registers */ > > > + 0x00001000 0x3ffff000 >;/* Virtual address space range > > > + * Exclude the 1st & last page > > > + */ > > > + interrupts = < 0 13 0x40 >; > > > + }; > > > }; > > > > Why is the virtual address space range limited to 1 GiB? What is the reason > > for the exclusion of the first and last pages? > > It's because physical RAM is located 2-4GB, and we may want to use > those area 1-1(V==P) mapping in some cases. This could be extended > with larger RAM without 1-1 mapping theoretically. So far 1GB seems to > be enough. I'm thinking that this would be better off in a separate property so that it's easier for boards to override it. > The 1st page for AVP vector, and the last one is required by another > H/W entity. I would expect such peculiarities to be handled by the driver internally. That way users wouldn't have to know or care about these kind of details. If it can't be handled by the driver then at least it should be mentioned explicitly in the binding documentation. Thierry
On 04/13/2012 06:15 AM, Thierry Reding wrote: > * Hiroshi Doyu wrote: >> Thierry Reding wrote: >>> * Hiroshi Doyu wrote: >>>> + smmu: smmu@7000f000 { >>>> + compatible = "nvidia,tegra30-smmu"; >>>> + reg = < 0x7000f000 0x400 /* controller registers */ >>>> + 0x6000c000 0x150 /* AHB Arbitration registers */ >>>> + 0x00001000 0x3ffff000 >;/* Virtual address space range >>>> + * Exclude the 1st & last page >>>> + */ >>>> + interrupts = < 0 13 0x40 >; >>>> + }; >>>> }; >>> >>> Why is the virtual address space range limited to 1 GiB? What is the reason >>> for the exclusion of the first and last pages? >> >> It's because physical RAM is located 2-4GB, and we may want to use >> those area 1-1(V==P) mapping in some cases. This could be extended >> with larger RAM without 1-1 mapping theoretically. So far 1GB seems to >> be enough. > > I'm thinking that this would be better off in a separate property so that > it's easier for boards to override it. Yes, and for another reason: The entries in the reg property are supposed to be within the bus address space that contains the device, whereas here this 3rd reg entry is being used to define something about an entirely unrelated address space - the virtual address space seen by SMMU clients. >> The 1st page for AVP vector, and the last one is required by another >> H/W entity. > > I would expect such peculiarities to be handled by the driver internally. > That way users wouldn't have to know or care about these kind of details. > If it can't be handled by the driver then at least it should be mentioned > explicitly in the binding documentation. I agree, but: Why do those pages even need special handling? Doesn't the AVP get its own address space ID, and then can set it up however it wants? -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/13/2012 04:22 AM, Hiroshi Doyu wrote: > From: Hiroshi DOYU <hdoyu@nvidia.com> > > Add device tree support for Tegra30 IOMMU(SMMU). > +++ b/Documentation/devicetree/bindings/arm/tegra/tegra30-smmu.txt I personally like the documentation to be named after the full compatible value, so nvidia,tegra30-smmu.txt. > @@ -0,0 +1,19 @@ > +NVIDIA Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit) > + > +Required properties: > +- compatible : "nvidia,tegra30-smmu" > +- reg : Should contain MC registers location and length > +- reg : Should contain AHB Arbitration registers and length > +- reg : Should contain virtual address space range This looks like 3 properties with the same name. It seems common to write something more like: reg : Should contain the register address and length for each fo the MC and AHB arbitration registers. But why does the SMMU driver expect to control the AHB arbitration registers? They seem unrelated to the SMMU. As I said in my previous email, I think the VA space size should be a separate property. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Stephen Warren <swarren@wwwdotorg.org> Subject: Re: [PATCH 1/1] arm/dts: Tegra30: Add device tree support for SMMU Date: Fri, 13 Apr 2012 21:33:47 +0200 Message-ID: <4F887F9B.700@wwwdotorg.org> > On 04/13/2012 04:22 AM, Hiroshi Doyu wrote: > > From: Hiroshi DOYU <hdoyu@nvidia.com> > > > > Add device tree support for Tegra30 IOMMU(SMMU). > > > +++ b/Documentation/devicetree/bindings/arm/tegra/tegra30-smmu.txt > > I personally like the documentation to be named after the full > compatible value, so nvidia,tegra30-smmu.txt. OK > > @@ -0,0 +1,19 @@ > > +NVIDIA Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit) > > + > > +Required properties: > > +- compatible : "nvidia,tegra30-smmu" > > +- reg : Should contain MC registers location and length > > +- reg : Should contain AHB Arbitration registers and length > > +- reg : Should contain virtual address space range > > This looks like 3 properties with the same name. It seems common to > write something more like: > > reg : Should contain the register address and length for each fo the MC > and AHB arbitration registers. OK, this looks better. > But why does the SMMU driver expect to control the AHB arbitration > registers? They seem unrelated to the SMMU. It's necessary to inform AHB that SMMU is ready to use. There's a dedicated bit for SMMU in this AHB arbitration register. > As I said in my previous email, I think the VA space size should be a > separate property. OK, I'll update. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Stephen Warren <swarren@wwwdotorg.org> Subject: Re: [PATCH 1/1] arm/dts: Tegra30: Add device tree support for SMMU Date: Fri, 13 Apr 2012 21:25:20 +0200 Message-ID: <4F887DA0.8030103@wwwdotorg.org> > On 04/13/2012 06:15 AM, Thierry Reding wrote: > > * Hiroshi Doyu wrote: > >> Thierry Reding wrote: > >>> * Hiroshi Doyu wrote: > >>>> + smmu: smmu@7000f000 { > >>>> + compatible = "nvidia,tegra30-smmu"; > >>>> + reg = < 0x7000f000 0x400 /* controller registers */ > >>>> + 0x6000c000 0x150 /* AHB Arbitration registers */ > >>>> + 0x00001000 0x3ffff000 >;/* Virtual address space range > >>>> + * Exclude the 1st & last page > >>>> + */ > >>>> + interrupts = < 0 13 0x40 >; > >>>> + }; > >>>> }; > >>> > >>> Why is the virtual address space range limited to 1 GiB? What is the reason > >>> for the exclusion of the first and last pages? > >> > >> It's because physical RAM is located 2-4GB, and we may want to use > >> those area 1-1(V==P) mapping in some cases. This could be extended > >> with larger RAM without 1-1 mapping theoretically. So far 1GB seems to > >> be enough. > > > > I'm thinking that this would be better off in a separate property so that > > it's easier for boards to override it. > > Yes, and for another reason: The entries in the reg property are > supposed to be within the bus address space that contains the device, > whereas here this 3rd reg entry is being used to define something about > an entirely unrelated address space - the virtual address space seen by > SMMU clients. What about using "dma-window" property to specify IOVA range in dtsi as below? arch/powerpc/platforms/cell/iommu.c: 698 static int __init cell_iommu_get_window(struct device_node *np, 699 unsigned long *base, 700 unsigned long *size) 701 { 702 const void *dma_window; 703 unsigned long index; 704 705 /* Use ibm,dma-window if available, else, hard code ! */ 706 dma_window = of_get_property(np, "ibm,dma-window", NULL); 707 if (dma_window == NULL) { ^^^^^^^^^^^^^^ 708 *base = 0; 709 *size = 0x80000000u; 710 return -ENODEV; 711 } 712 713 of_parse_dma_window(np, dma_window, &index, base, size); 714 return 0; 715 } > >> The 1st page for AVP vector, and the last one is required by another > >> H/W entity. > > > > I would expect such peculiarities to be handled by the driver internally. > > That way users wouldn't have to know or care about these kind of details. > > If it can't be handled by the driver then at least it should be mentioned > > explicitly in the binding documentation. > > I agree, but: > > Why do those pages even need special handling? Doesn't the AVP get its > own address space ID, and then can set it up however it wants? This sounds better than dealing with prefixed mappings at booting. At least we need to pass # of ASIDs, and client should claim one of them. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 16 April 2012, Hiroshi Doyu wrote: > What about using "dma-window" property to specify IOVA range in dtsi as below? > > arch/powerpc/platforms/cell/iommu.c: > > 698 static int __init cell_iommu_get_window(struct device_node *np, > 699 unsigned long *base, > 700 unsigned long *size) > 701 { > 702 const void *dma_window; > 703 unsigned long index; > 704 > 705 /* Use ibm,dma-window if available, else, hard code ! */ > 706 dma_window = of_get_property(np, "ibm,dma-window", NULL); > 707 if (dma_window == NULL) { ^^^^^^^^^^^^^^ > 708 *base = 0; > 709 *size = 0x80000000u; > 710 return -ENODEV; > 711 } > 712 > 713 of_parse_dma_window(np, dma_window, &index, base, size); > 714 return 0; > 715 } > Yes, that's the right way to do it, but I would use the more generic "dma-window" name rather than "ibm,dma-window", which was originally introduced for pseries and for some reason copied into the cell qs2x firmware. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/16/2012 04:10 AM, Hiroshi Doyu wrote: > Stephen Warren wrote at Fri, 13 Apr 2012 21:33:47 +0200: >> On 04/13/2012 04:22 AM, Hiroshi Doyu wrote: >>> Add device tree support for Tegra30 IOMMU(SMMU). ... >> But why does the SMMU driver expect to control the AHB arbitration >> registers? They seem unrelated to the SMMU. > > It's necessary to inform AHB that SMMU is ready to use. There's a > dedicated bit for SMMU in this AHB arbitration register. Shouldn't there be a dedicated driver for the AHB arbitration registers that the SMMU driver calls into to achieve this? IIRC, the AHB arbitration registers support much more than the SMMU enable, and if we ever need to touch those other features, going to the SMMU driver to do so probably wouldn't make sense. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 16 Apr 2012 18:07:06 +0200 Stephen Warren <swarren@wwwdotorg.org> wrote: > On 04/16/2012 04:10 AM, Hiroshi Doyu wrote: > > Stephen Warren wrote at Fri, 13 Apr 2012 21:33:47 +0200: > >> On 04/13/2012 04:22 AM, Hiroshi Doyu wrote: > >>> Add device tree support for Tegra30 IOMMU(SMMU). > ... > >> But why does the SMMU driver expect to control the AHB arbitration > >> registers? They seem unrelated to the SMMU. > > > > It's necessary to inform AHB that SMMU is ready to use. There's a > > dedicated bit for SMMU in this AHB arbitration register. > > Shouldn't there be a dedicated driver for the AHB arbitration registers > that the SMMU driver calls into to achieve this? IIRC, the AHB > arbitration registers support much more than the SMMU enable, and if we > ever need to touch those other features, going to the SMMU driver to do > so probably wouldn't make sense. Agree. Sounds like the way to go. We haven't upstreamed AHB driver yet. So is it ok to remove AHB entry from SMMU dt and add AHB function call when upstreaming AHB driver? I'll work on that. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 16 Apr 2012 17:34:19 +0200 Arnd Bergmann <arnd@arndb.de> wrote: > On Monday 16 April 2012, Hiroshi Doyu wrote: > > What about using "dma-window" property to specify IOVA range in dtsi as below? > > > > arch/powerpc/platforms/cell/iommu.c: > > > > 698 static int __init cell_iommu_get_window(struct device_node *np, > > 699 unsigned long *base, > > 700 unsigned long *size) > > 701 { > > 702 const void *dma_window; > > 703 unsigned long index; > > 704 > > 705 /* Use ibm,dma-window if available, else, hard code ! */ > > 706 dma_window = of_get_property(np, "ibm,dma-window", NULL); > > 707 if (dma_window == NULL) { ^^^^^^^^^^^^^^ > > 708 *base = 0; > > 709 *size = 0x80000000u; > > 710 return -ENODEV; > > 711 } > > 712 > > 713 of_parse_dma_window(np, dma_window, &index, base, size); > > 714 return 0; > > 715 } > > > > Yes, that's the right way to do it, but I would use the more generic > "dma-window" name rather than "ibm,dma-window", which was originally > introduced for pseries and for some reason copied into the cell qs2x > firmware. Which name is better, "dma-window" or "iova-window"? Considering DMA IOMMU mapping API, "dma-window" may sound appropriate to me. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Hiroshi Doyu wrote: > On Mon, 16 Apr 2012 17:34:19 +0200 > Arnd Bergmann <arnd@arndb.de> wrote: > > > On Monday 16 April 2012, Hiroshi Doyu wrote: > > > What about using "dma-window" property to specify IOVA range in dtsi as below? > > > > > > arch/powerpc/platforms/cell/iommu.c: > > > > > > 698 static int __init cell_iommu_get_window(struct device_node *np, > > > 699 unsigned long *base, > > > 700 unsigned long *size) > > > 701 { > > > 702 const void *dma_window; > > > 703 unsigned long index; > > > 704 > > > 705 /* Use ibm,dma-window if available, else, hard code ! */ > > > 706 dma_window = of_get_property(np, "ibm,dma-window", NULL); > > > 707 if (dma_window == NULL) { ^^^^^^^^^^^^^^ > > > 708 *base = 0; > > > 709 *size = 0x80000000u; > > > 710 return -ENODEV; > > > 711 } > > > 712 > > > 713 of_parse_dma_window(np, dma_window, &index, base, size); > > > 714 return 0; > > > 715 } > > > > > > > Yes, that's the right way to do it, but I would use the more generic > > "dma-window" name rather than "ibm,dma-window", which was originally > > introduced for pseries and for some reason copied into the cell qs2x > > firmware. > > Which name is better, "dma-window" or "iova-window"? > Considering DMA IOMMU mapping API, "dma-window" may sound appropriate to me. But the window isn't necessarily used for DMA transfers. I was going to propose "aperture", but that doesn't seem quite right since it is a very GART-specific term. "iova-window" sounds like the best fit for what it really is. Thierry
From: Thierry Reding <thierry.reding@avionic-design.de> Subject: Re: [PATCH 1/1] arm/dts: Tegra30: Add device tree support for SMMU Date: Wed, 18 Apr 2012 07:41:40 +0200 Message-ID: <20120418054140.GA17506@avionic-0098.adnet.avionic-design.de> > * PGP Signed by an unknown key > > * Hiroshi Doyu wrote: > > On Mon, 16 Apr 2012 17:34:19 +0200 > > Arnd Bergmann <arnd@arndb.de> wrote: > > > > > On Monday 16 April 2012, Hiroshi Doyu wrote: > > > > What about using "dma-window" property to specify IOVA range in dtsi as below? > > > > > > > > arch/powerpc/platforms/cell/iommu.c: > > > > > > > > 698 static int __init cell_iommu_get_window(struct device_node *np, > > > > 699 unsigned long *base, > > > > 700 unsigned long *size) > > > > 701 { > > > > 702 const void *dma_window; > > > > 703 unsigned long index; > > > > 704 > > > > 705 /* Use ibm,dma-window if available, else, hard code ! */ > > > > 706 dma_window = of_get_property(np, "ibm,dma-window", NULL); > > > > 707 if (dma_window == NULL) { ^^^^^^^^^^^^^^ > > > > 708 *base = 0; > > > > 709 *size = 0x80000000u; > > > > 710 return -ENODEV; > > > > 711 } > > > > 712 > > > > 713 of_parse_dma_window(np, dma_window, &index, base, size); > > > > 714 return 0; > > > > 715 } > > > > > > > > > > Yes, that's the right way to do it, but I would use the more generic > > > "dma-window" name rather than "ibm,dma-window", which was originally > > > introduced for pseries and for some reason copied into the cell qs2x > > > firmware. > > > > Which name is better, "dma-window" or "iova-window"? > > Considering DMA IOMMU mapping API, "dma-window" may sound appropriate to me. > > But the window isn't necessarily used for DMA transfers. I was going to > propose "aperture", but that doesn't seem quite right since it is a very > GART-specific term. "iova-window" sounds like the best fit for what it > really is. If we can consider IOMMU as one of the implementation of DMA(Direct Memory Access), the prefix "dma-(window)" may make sense here. Then, we don't have to introduce a new concept "IO virtual address(iova)" in addition to the existing "bus address"(?) Anyway, either name would be ok for me;) -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 18 April 2012, Hiroshi Doyu wrote: > If we can consider IOMMU as one of the implementation of DMA(Direct > Memory Access), the prefix "dma-(window)" may make sense here. Then, > we don't have to introduce a new concept "IO virtual address(iova)" in > addition to the existing "bus address"(?) > > Anyway, either name would be ok for me;) I would just use dma-window, without the "ibm," prefix but following the same conventions. Note that the of_parse_dma_window function is currently only defined in powerpc specific code, and should get moved to drivers/of from arch/powerpc/kernel/prom_parse.c. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/17/2012 11:10 PM, Hiroshi Doyu wrote: > On Mon, 16 Apr 2012 18:07:06 +0200 > Stephen Warren <swarren@wwwdotorg.org> wrote: > >> On 04/16/2012 04:10 AM, Hiroshi Doyu wrote: >>> Stephen Warren wrote at Fri, 13 Apr 2012 21:33:47 +0200: >>>> On 04/13/2012 04:22 AM, Hiroshi Doyu wrote: >>>>> Add device tree support for Tegra30 IOMMU(SMMU). >> ... >>>> But why does the SMMU driver expect to control the AHB arbitration >>>> registers? They seem unrelated to the SMMU. >>> >>> It's necessary to inform AHB that SMMU is ready to use. There's a >>> dedicated bit for SMMU in this AHB arbitration register. >> >> Shouldn't there be a dedicated driver for the AHB arbitration registers >> that the SMMU driver calls into to achieve this? IIRC, the AHB >> arbitration registers support much more than the SMMU enable, and if we >> ever need to touch those other features, going to the SMMU driver to do >> so probably wouldn't make sense. > > Agree. Sounds like the way to go. > > We haven't upstreamed AHB driver yet. So is it ok to remove AHB entry > from SMMU dt and add AHB function call when upstreaming AHB driver? > I'll work on that. I think that seems reasonable for now, yes. I assume you mean implementing e.g. arch/arm/mach-tegra/tegra30-ahb.c, similar to how, say, the fuse APIs work. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/arm/tegra/tegra30-smmu.txt b/Documentation/devicetree/bindings/arm/tegra/tegra30-smmu.txt new file mode 100644 index 0000000..4bd8cd0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/tegra/tegra30-smmu.txt @@ -0,0 +1,19 @@ +NVIDIA Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit) + +Required properties: +- compatible : "nvidia,tegra30-smmu" +- reg : Should contain MC registers location and length +- reg : Should contain AHB Arbitration registers and length +- reg : Should contain virtual address space range +- interrupts : Should contain MC General interrupt + +Example: + smmu: smmu@7000f000 { + compatible = "nvidia,tegra30-smmu"; + reg = < 0x7000f000 0x400 /* controller registers */ + 0x6000c000 0x150 /* AHB Arbitration registers */ + 0x00001000 0x3ffff000 >;/* Virtual address space range + * Exclude the 1st & last page + */ + interrupts = < 0 13 0x40 >; + }; diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi index 62a7b39..c640a5b 100644 --- a/arch/arm/boot/dts/tegra30.dtsi +++ b/arch/arm/boot/dts/tegra30.dtsi @@ -183,4 +183,14 @@ reg = < 0x70000868 0xd0 /* Pad control registers */ 0x70003000 0x3e0 >; /* Mux registers */ }; + + smmu: smmu@7000f000 { + compatible = "nvidia,tegra30-smmu"; + reg = < 0x7000f000 0x400 /* controller registers */ + 0x6000c000 0x150 /* AHB Arbitration registers */ + 0x00001000 0x3ffff000 >;/* Virtual address space range + * Exclude the 1st & last page + */ + interrupts = < 0 13 0x40 >; + }; };