Re: Stream ID managment for VF
On Feb 25, 2014 2:28 AM, Will Deacon will.dea...@arm.com wrote: On Mon, Feb 24, 2014 at 03:12:21PM +, srikanth TS wrote: Hi Will Deacon, Hello, Currently SMMU driver expecting all stream ID used by respective master should be defined in the DT. We want to know how to handle in the case of virtual functions dynamically created and destroyed. Is PCI driver responsible for creating stream ID respective BDand requesting SMMU to add to the mapping table[stream Id to context mapping table]? Or is there any right way of doing it? Correct, the driver currently doesn't support dynamic mappings (mainly because I didn't want to try and invent something that I couldn't test). There are a couple of ways to solve this: (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SMMU within a fixed range. That would probably need some code in the bus layer, so that a bus notifier can kick and call back to the relevant SMMU. I think first way of solving seems to be better, because we don't know how many VF are used and i feel its not good idea to keep whole list of streamID [which is equal to max num vf] in DT. Again in this method we need to generate the stream ID dynamically whenever VF is added in pci iov driver side. And then pass that stream ID to SMMU. Is it ok this way? Or you prefer 2nd way which is simpler. (2) Describe the RID - SID mapping in the device-tree. We probably want to avoid an enormous table, so this would only work for simple `SID = RID + offset' or 'SID = RID mask' cases. How do your IDs map to each other? Will ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 0/2] arm: dma-mapping: add dynamic resize of IOVA bitmap
Hello, This patchset is a continuation of the work started by Andreas Herrmann to add support for dynamically resized bitmaps for IOMMU based DMA-mapping implementation for ARM architecture. Some more discussion and rationale has been discussed in the following thread: http://www.spinics.net/lists/arm-kernel/msg303732.html The first patch adds support for on-demand extending IO address space bitmap. It is based on the original work by Andreas Herrmann, but I decided to drop arm_iommu_create_mapping() api change part. The second patch removes the 'order' hack, which was used to reduce the size of a bitmap. The first patch solved the problem of too large io address space bitmaps, so the 'order' hack is no longer needed. The parameters of the arm_iommu_create_mapping() function can be then simplified by dropping 'order' parameter without any functional change of the whole subsystem. This parameter was already a bit misunderstood, so the overall result is also a little improvement of the API. Best regards Marek Szyprowski, PhD Samsung RD Institute Poland Andreas Herrmann (1): arm: dma-mapping: Add support to extend DMA IOMMU mappings Marek Szyprowski (1): arm: dma-mapping: remove order parameter from arm_iommu_create_mapping() arch/arm/include/asm/dma-iommu.h | 12 ++- arch/arm/mm/dma-mapping.c | 144 +++-- drivers/gpu/drm/exynos/exynos_drm_drv.h |2 - drivers/gpu/drm/exynos/exynos_drm_iommu.c |6 +- drivers/gpu/drm/exynos/exynos_drm_iommu.h |1 - drivers/iommu/shmobile-iommu.c|2 +- 6 files changed, 124 insertions(+), 43 deletions(-) -- 1.7.9.5 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 1/2] arm: dma-mapping: Add support to extend DMA IOMMU mappings
From: Andreas Herrmann andreas.herrm...@calxeda.com
Instead of using just one bitmap to keep track of IO virtual addresses
(handed out for IOMMU use) introduce an array of bitmaps. This allows
us to extend existing mappings when running out of iova space in the
initial mapping etc.
If there is not enough space in the mapping to service an IO virtual
address allocation request, __alloc_iova() tries to extend the mapping
-- by allocating another bitmap -- and makes another allocation
attempt using the freshly allocated bitmap.
This allows arm iommu drivers to start with a decent initial size when
an dma_iommu_mapping is created and still to avoid running out of IO
virtual addresses for the mapping.
Signed-off-by: Andreas Herrmann andreas.herrm...@calxeda.com
[mszyprow: removed extensions parameter to arm_iommu_create_mapping()
function, which will be modified in the next patch anyway, also some
debug messages about extending bitmap]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/include/asm/dma-iommu.h |8 ++-
arch/arm/mm/dma-mapping.c| 123 --
2 files changed, 110 insertions(+), 21 deletions(-)
diff --git a/arch/arm/include/asm/dma-iommu.h b/arch/arm/include/asm/dma-iommu.h
index a8c56ac..686797c 100644
--- a/arch/arm/include/asm/dma-iommu.h
+++ b/arch/arm/include/asm/dma-iommu.h
@@ -13,8 +13,12 @@ struct dma_iommu_mapping {
/* iommu specific data */
struct iommu_domain *domain;
- void*bitmap;
- size_t bits;
+ unsigned long **bitmaps; /* array of bitmaps */
+ unsigned intnr_bitmaps; /* nr of elements in array */
+ unsigned intextensions;
+ size_t bitmap_size;/* size of a single bitmap */
+ size_t bits; /* per bitmap */
+ unsigned intsize; /* per bitmap */
unsigned intorder;
dma_addr_t base;
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index c9c6acdf..cc42bc2 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1066,6 +1066,8 @@ fs_initcall(dma_debug_do_init);
/* IOMMU */
+static int extend_iommu_mapping(struct dma_iommu_mapping *mapping);
+
static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
size_t size)
{
@@ -1073,6 +1075,8 @@ static inline dma_addr_t __alloc_iova(struct
dma_iommu_mapping *mapping,
unsigned int align = 0;
unsigned int count, start;
unsigned long flags;
+ dma_addr_t iova;
+ int i;
if (order CONFIG_ARM_DMA_IOMMU_ALIGNMENT)
order = CONFIG_ARM_DMA_IOMMU_ALIGNMENT;
@@ -1084,30 +1088,78 @@ static inline dma_addr_t __alloc_iova(struct
dma_iommu_mapping *mapping,
align = (1 (order - mapping-order)) - 1;
spin_lock_irqsave(mapping-lock, flags);
- start = bitmap_find_next_zero_area(mapping-bitmap, mapping-bits, 0,
- count, align);
- if (start mapping-bits) {
- spin_unlock_irqrestore(mapping-lock, flags);
- return DMA_ERROR_CODE;
+ for (i = 0; i mapping-nr_bitmaps; i++) {
+ start = bitmap_find_next_zero_area(mapping-bitmaps[i],
+ mapping-bits, 0, count, align);
+
+ if (start mapping-bits)
+ continue;
+
+ bitmap_set(mapping-bitmaps[i], start, count);
+ break;
}
- bitmap_set(mapping-bitmap, start, count);
+ /*
+* No unused range found. Try to extend the existing mapping
+* and perform a second attempt to reserve an IO virtual
+* address range of size bytes.
+*/
+ if (i == mapping-nr_bitmaps) {
+ if (extend_iommu_mapping(mapping)) {
+ spin_unlock_irqrestore(mapping-lock, flags);
+ return DMA_ERROR_CODE;
+ }
+
+ start = bitmap_find_next_zero_area(mapping-bitmaps[i],
+ mapping-bits, 0, count, align);
+
+ if (start mapping-bits) {
+ spin_unlock_irqrestore(mapping-lock, flags);
+ return DMA_ERROR_CODE;
+ }
+
+ bitmap_set(mapping-bitmaps[i], start, count);
+ }
spin_unlock_irqrestore(mapping-lock, flags);
- return mapping-base + (start (mapping-order + PAGE_SHIFT));
+ iova = mapping-base + (mapping-size * i);
+ iova += start (mapping-order + PAGE_SHIFT);
+
+ return iova;
}
static inline void __free_iova(struct dma_iommu_mapping *mapping,
dma_addr_t addr, size_t size)
{
- unsigned int start = (addr - mapping-base)
-
Re: [PATCHv2 02/16] iommu/omap: omap_iommu_attach() should return ENODEV, not NULL
Hi Suman,
Thank you for the patch.
On Thursday 13 February 2014 12:15:33 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
omap_iommu_attach() returns NULL or ERR_PTR in case of error, but
omap_iommu_attach_dev() only checks for IS_ERR. Thus a NULL return value (in
case driver_find_device fails) will cause the kernel to panic when
omap_iommu_attach_dev() dereferences the pointer.
In such case, omap_iommu_attach() should return ENODEV, not NULL.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Acked-by: Suman Anna s-a...@ti.com
---
drivers/iommu/omap-iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index fff2ffd..6272c36 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -863,7 +863,7 @@ static int device_match_by_alias(struct device *dev,
void *data) **/
static struct omap_iommu *omap_iommu_attach(const char *name, u32 *iopgd)
{
- int err = -ENOMEM;
+ int err = -ENODEV;
struct device *dev;
struct omap_iommu *obj;
@@ -871,7 +871,7 @@ static struct omap_iommu *omap_iommu_attach(const char
*name, u32 *iopgd) (void *)name,
device_match_by_alias);
if (!dev)
- return NULL;
+ return ERR_PTR(err);
I would return ERR_PTR(-ENODEV) here, and remove the initialization at
declaration of err above.
obj = to_iommu(dev);
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 07/16] iommu/omap: allow enable/disable even without pdata
Hi Suman,
Thank you for the patch.
On Thursday 13 February 2014 12:15:38 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
When booting with a devicetree, no platform data is provided.
Do not prematurely exit iommu_enable() and iommu_disable() in
such a case.
Note: As OMAP do not yet has a proper reset controller driver,
IOMMUs requiring a reset signal should use pdata-quirks as a
transitional solution.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
This looks good to me, but you should move this patch before 04/16, otherwise
you'll break bisection.
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index f6afe8f..7672eb4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -149,13 +149,10 @@ static int iommu_enable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj-dev);
struct iommu_platform_data *pdata = pdev-dev.platform_data;
- if (!pdata)
- return -EINVAL;
-
if (!arch_iommu)
return -ENODEV;
- if (pdata-deassert_reset) {
+ if (pdata pdata-deassert_reset) {
err = pdata-deassert_reset(pdev, pdata-reset_name);
if (err) {
dev_err(obj-dev, deassert_reset failed: %d\n, err);
@@ -175,14 +172,11 @@ static void iommu_disable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj-dev);
struct iommu_platform_data *pdata = pdev-dev.platform_data;
- if (!pdata)
- return;
-
arch_iommu-disable(obj);
pm_runtime_put_sync(obj-dev);
- if (pdata-assert_reset)
+ if (pdata pdata-assert_reset)
pdata-assert_reset(pdev, pdata-reset_name);
}
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 08/16] ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2
On Thursday 13 February 2014 12:15:39 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting
usage by tidspbridge and other iommu users. The same can be achieved
by marking the DT node disabled, so remove this obsolete flag and
the corresponding hwmod data can be enabled.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: revise commit log]
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8
arch/arm/plat-omap/Kconfig | 3 ---
2 files changed, 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c index 4c3b1e6..81dd071 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3029,8 +3029,6 @@ static struct omap_hwmod omap3xxx_mmu_isp_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
-#ifdef CONFIG_OMAP_IOMMU_IVA2
-
/* mmu iva */
static struct omap_mmu_dev_attr mmu_iva_dev_attr = {
@@ -3082,8 +3080,6 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
-#endif
-
/* l4_per - gpio4 */
static struct omap_hwmod_addr_space omap3xxx_gpio4_addrs[] = {
{
@@ -3855,9 +3851,7 @@ static struct omap_hwmod_ocp_if
*omap34xx_hwmod_ocp_ifs[] __initdata = { omap3xxx_l4_core__hdq1w,
omap3xxx_sad2d__l3,
omap3xxx_l4_core__mmu_isp,
-#ifdef CONFIG_OMAP_IOMMU_IVA2
omap3xxx_l3_main__mmu_iva,
-#endif
omap34xx_l4_core__ssi,
NULL
};
@@ -3881,9 +3875,7 @@ static struct omap_hwmod_ocp_if
*omap36xx_hwmod_ocp_ifs[] __initdata = { omap3xxx_l4_core__hdq1w,
omap3xxx_sad2d__l3,
omap3xxx_l4_core__mmu_isp,
-#ifdef CONFIG_OMAP_IOMMU_IVA2
omap3xxx_l3_main__mmu_iva,
-#endif
NULL
};
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 436ea97..02fc10d 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -86,9 +86,6 @@ config OMAP_MUX_WARNINGS
to change the pin multiplexing setup. When there are no warnings
printed, it's safe to deselect OMAP_MUX for your product.
-config OMAP_IOMMU_IVA2
- bool
-
config OMAP_MPU_TIMER
bool Use mpu timer
depends on ARCH_OMAP1
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
Hi Suman,
Thank you for the patch.
On Thursday 13 February 2014 12:15:34 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from
the standard bindings used by OMAP peripherals, this patch uses a
'dma-window' (already used by Tegra SMMU) and adds two OMAP custom
bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: split bindings document, add dra7 and bus error back]
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/iommu/ti,omap-iommu.txt| 28 +++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file mode
100644
index 000..116492d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -0,0 +1,28 @@
+OMAP2+ IOMMU
+
+Required properties:
+- compatible : Should be one of,
+ ti,omap2-iommu for OMAP2/OMAP3 IOMMU instances
+ ti,omap4-iommu for OMAP4/OMAP5 IOMMU instances
+ ti,dra7-iommu for DRA7xx IOMMU instances
+- ti,hwmods : Name of the hwmod associated with the IOMMU instance
+- reg: Address space for the configuration registers
+- interrupts : Interrupt specifier for the IOMMU instance
+- dma-window : IOVA start address and length
Isn't the dma window more of a system configuration property than a hardware
property ? How do you expect it to be set ?
+Optional properties:
+- ti,#tlb-entries : Number of entries in the translation look-aside buffer.
+Should be either 8 or 32 (default: 32)
+- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing
+ back a bus error response on MMU faults.
Do these features vary per IOMMU instance or per IOMMU model ? In the latter
case they could be inferred from the compatible string by the driver without
requiring them to be explicit in DT (whether you want to do so is left to you
though).
+Example:
+ /* OMAP3 ISP MMU */
+ mmu_isp: mmu@480bd400 {
+ compatible = ti,omap2-iommu;
+ reg = 0x480bd400 0x80;
+ interrupts = 24;
+ ti,hwmods = mmu_isp;
+ ti,#tlb-entries = 8;
+ dma-window = 0 0xf000;
+ };
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 07/16] iommu/omap: allow enable/disable even without pdata
Hi Laurent,
On 02/25/2014 03:15 PM, Laurent Pinchart wrote:
Hi Suman,
Thank you for the patch.
On Thursday 13 February 2014 12:15:38 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
When booting with a devicetree, no platform data is provided.
Do not prematurely exit iommu_enable() and iommu_disable() in
such a case.
Note: As OMAP do not yet has a proper reset controller driver,
IOMMUs requiring a reset signal should use pdata-quirks as a
transitional solution.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
This looks good to me, but you should move this patch before 04/16, otherwise
you'll break bisection.
OK, I see the point w.r.t the OMAP3 ISP node. I will move it to before
03/16 (the DT bindings patch), it shouldn't make any difference.
regards
Suman
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index f6afe8f..7672eb4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -149,13 +149,10 @@ static int iommu_enable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj-dev);
struct iommu_platform_data *pdata = pdev-dev.platform_data;
- if (!pdata)
- return -EINVAL;
-
if (!arch_iommu)
return -ENODEV;
- if (pdata-deassert_reset) {
+ if (pdata pdata-deassert_reset) {
err = pdata-deassert_reset(pdev, pdata-reset_name);
if (err) {
dev_err(obj-dev, deassert_reset failed: %d\n, err);
@@ -175,14 +172,11 @@ static void iommu_disable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj-dev);
struct iommu_platform_data *pdata = pdev-dev.platform_data;
- if (!pdata)
- return;
-
arch_iommu-disable(obj);
pm_runtime_put_sync(obj-dev);
- if (pdata-assert_reset)
+ if (pdata pdata-assert_reset)
pdata-assert_reset(pdev, pdata-reset_name);
}
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
Hi Suman,
On Tuesday 25 February 2014 17:02:35 Suman Anna wrote:
On 02/25/2014 03:26 PM, Laurent Pinchart wrote:
On Thursday 13 February 2014 12:15:34 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from
the standard bindings used by OMAP peripherals, this patch uses a
'dma-window' (already used by Tegra SMMU) and adds two OMAP custom
bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: split bindings document, add dra7 and bus error back]
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/iommu/ti,omap-iommu.txt| 28
+++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file mode
100644
index 000..116492d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -0,0 +1,28 @@
+OMAP2+ IOMMU
+
+Required properties:
+- compatible : Should be one of,
+ ti,omap2-iommu for OMAP2/OMAP3 IOMMU instances
+ ti,omap4-iommu for OMAP4/OMAP5 IOMMU instances
+ ti,dra7-iommu for DRA7xx IOMMU instances
+- ti,hwmods : Name of the hwmod associated with the IOMMU instance
+- reg: Address space for the configuration registers
+- interrupts : Interrupt specifier for the IOMMU instance
+- dma-window : IOVA start address and length
Isn't the dma window more of a system configuration property than a
hardware property ? How do you expect it to be set?
We are setting it based on the addressable range for the MMU.
A quick look at the ISP and IVA IOMMUs in the OMAP3 shows that both support
the full 4GB VA space. Why do you need to restrict it ?
We are reusing the existing defined property and it allows us to get rid of
the IOVA start and end addresses defined in the pre-DT OMAP iommu platform
data.
+Optional properties:
+- ti,#tlb-entries : Number of entries in the translation look-aside
buffer. +Should be either 8 or 32 (default: 32)
+- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing
+back a bus error response on MMU faults.
Do these features vary per IOMMU instance or per IOMMU model ? In the
latter case they could be inferred from the compatible string by the
driver without requiring them to be explicit in DT (whether you want to
do so is left to you though).
Well, these are fixed features given an IOMMU instance, like the OMAP3
ISP is the only one that has 8 TLB entries, all the remaining ones have
32, and the IPU iommu instances are the only ones that support the bus
error response back. I have no preference to any particular way, and
sure the driver can infer these easily based on unique compatible
strings per subsystem per SoC. I just happened to go with defining
compatible strings per SoC, with the optional properties differentiating
the fixed behavior between different IOMMU instances on that SoC. This
is where I was looking for some inputs/guidance from the DT bindings
maintainers on what is the preferred method.
I think you've made the right choice. I wasn't sure whether those parameters
varied across IOMMU instances of compatible devices (from a compatible string
point of view) or were constant. As they vary they should be expressed in DT.
+Example:
+ /* OMAP3 ISP MMU */
+ mmu_isp: mmu@480bd400 {
+ compatible = ti,omap2-iommu;
+ reg = 0x480bd400 0x80;
+ interrupts = 24;
+ ti,hwmods = mmu_isp;
+ ti,#tlb-entries = 8;
+ dma-window = 0 0xf000;
+ };
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
