RE: your mail
On Feb 25, 2014 8:28 PM, Varun Sethi varun.se...@freescale.com wrote: -Original Message- From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- boun...@lists.linux-foundation.org] On Behalf Of Will Deacon Sent: Monday, February 24, 2014 10:59 PM To: srikanth TS Cc: iommu@lists.linux-foundation.org; sungjinn.ch...@samsung.com; linux- ker...@vger.kernel.org; ts.srika...@samsung.com Subject: Re: your mail 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. This could be done in add device notifier. I am working on similar(not PCI) hot plug device infrastructure for arm smmu driver. I will post an RFC patch by next week. Can you please explain with little more detail. We just want to make sure your idea fits in for pci iov also. -Srikanth ts -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 02/16] iommu/omap: omap_iommu_attach() should return ENODEV, not NULL
Hi Laurent,
On Tuesday 25 February 2014 16:32:03 Suman Anna wrote:
On 02/25/2014 03:13 PM, Laurent Pinchart wrote:
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.
The initialization at the beginning is also serving one another exit
path (a check for try_module_get), where err is not being set. If the
initialization is removed, then the err has to be set explicitly at the
other place. Let me know if you still want this changed.
The return value of iommu_enable() is unconditionally stored in err before the
try_module_get() call, so that code patch is buggy anyway and should be fixed.
I would still remove the initialization at declaration and assign -ENODEV to
err explicitly when try_module_get() fails before the goto err_module.
OK, I will fix this up.
regards
Suman
___
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 Laurent,
On 02/25/2014 08:13 PM, Laurent Pinchart wrote:
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 ?
I should have rephrased it better when I said addressable range. While
the MMUs are capable of programming the full 4GB space, there are some
address ranges that are private from the processor view. This window is
currently used to set the range for the omap-iovmm driver (which only
OMAP3 ISP is using atm), and there is no point in allowing the
omap-iovmm driver the full range when the processor could never
reach/access those addresses.
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.
Yeah, I wasn't sure if these qualify as features (as per
Documentation/devicetree/bindings/ABI.txt section II.2).
regards
Suman
+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;
+ };
___
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
* Laurent Pinchart laurent.pinch...@ideasonboard.com [140225 13:18]: 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 Acked-by: Tony Lindgren t...@atomide.com ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 10/16] ARM: OMAP2+: use pdata quirks for iommu reset lines
* Suman Anna s-a...@ti.com [140213 10:19]:
The OMAP iommu driver performs the reset management for the
iommu instances in processor sub-systems using the omap_device
API which are currently supplied as platform data ops. Use pdata
quirks to maintain the functionality as the OMAP iommu driver
gets converted to use DT nodes, until the reset portions are
decoupled from omap_hwmod/omap_device into a separate reset
driver.
This patch adds the pdata quirks for the reset management of
iommus within the DSP (OMAP3 OMAP4) and IPU subsystems (OMAP4).
Signed-off-by: Suman Anna s-a...@ti.com
Looks OK, but I suggest you separate out the remaining patches in
this series into another clean-up series. Then the clean-up series
can be merged later on as these have a good chance of conflicting
with other stuff.
Tony
---
arch/arm/mach-omap2/pdata-quirks.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 3d5b24d..74e094a 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -16,12 +16,14 @@
#include linux/wl12xx.h
#include linux/platform_data/pinctrl-single.h
+#include linux/platform_data/iommu-omap.h
#include am35xx.h
#include common.h
#include common-board-devices.h
#include dss-common.h
#include control.h
+#include omap_device.h
struct pdata_init {
const char *compatible;
@@ -92,6 +94,12 @@ static void __init hsmmc2_internal_input_clk(void)
omap_ctrl_writel(reg, OMAP343X_CONTROL_DEVCONF1);
}
+static struct iommu_platform_data omap3_iommu_pdata = {
+ .reset_name = mmu,
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
+
static int omap3_sbc_t3730_twl_callback(struct device *dev,
unsigned gpio,
unsigned ngpio)
@@ -185,6 +193,12 @@ static void __init omap4_panda_legacy_init(void)
legacy_init_ehci_clk(auxclk3_ck);
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
+
+static struct iommu_platform_data omap4_iommu_pdata = {
+ .reset_name = mmu_cache,
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
#endif
#ifdef CONFIG_SOC_OMAP5
@@ -240,6 +254,8 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002030, 48002030.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002a00, 48002a00.pinmux,
pcs_pdata),
+ OF_DEV_AUXDATA(ti,omap2-iommu, 0x5d00, 5d00.mmu,
+omap3_iommu_pdata),
/* Only on am3517 */
OF_DEV_AUXDATA(ti,davinci_mdio, 0x5c03, davinci_mdio.0, NULL),
OF_DEV_AUXDATA(ti,am3517-emac, 0x5c00, davinci_emac.0,
@@ -248,6 +264,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata =
{
#ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux,
pcs_pdata),
+ OF_DEV_AUXDATA(ti,omap4-iommu, 0x4a066000, 4a066000.mmu,
+omap4_iommu_pdata),
+ OF_DEV_AUXDATA(ti,omap4-iommu, 0x55082000, 55082000.mmu,
+omap4_iommu_pdata),
#endif
{ /* sentinel */ },
};
--
1.8.5.3
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 14/16] ARM: OMAP3: hwmod data: cleanup data for IOMMUs
* Suman Anna s-a...@ti.com [140213 10:19]:
From: Florian Vaussard florian.vauss...@epfl.ch
The irq numbers, ocp address space and device attribute data
have all been cleaned up for OMAP3 IOMMUs. All this data is
populated via the corresponding dt node.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Signed-off-by: Suman Anna s-a...@ti.com
This will need to wait until we've made omap3 to be DT only
as this will break idling of things for the legacy booting.
Regards,
Tony
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 46
--
1 file changed, 46 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 9c7e23a..d68c131 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -24,7 +24,6 @@
#include l4_3xxx.h
#include linux/platform_data/asoc-ti-mcbsp.h
#include linux/platform_data/spi-omap2-mcspi.h
-#include linux/platform_data/iommu-omap.h
#include linux/platform_data/mailbox-omap.h
#include plat/dmtimer.h
@@ -2991,83 +2990,39 @@ static struct omap_hwmod_class
omap3xxx_mmu_hwmod_class = {
/* mmu isp */
-static struct omap_mmu_dev_attr mmu_isp_dev_attr = {
- .da_start = 0x0,
- .da_end = 0xf000,
- .nr_tlb_entries = 8,
-};
-
static struct omap_hwmod omap3xxx_mmu_isp_hwmod;
-static struct omap_hwmod_irq_info omap3xxx_mmu_isp_irqs[] = {
- { .irq = 24 + OMAP_INTC_START, },
- { .irq = -1 }
-};
-
-static struct omap_hwmod_addr_space omap3xxx_mmu_isp_addrs[] = {
- {
- .pa_start = 0x480bd400,
- .pa_end = 0x480bd47f,
- .flags = ADDR_TYPE_RT,
- },
- { }
-};
/* l4_core - mmu isp */
static struct omap_hwmod_ocp_if omap3xxx_l4_core__mmu_isp = {
.master = omap3xxx_l4_core_hwmod,
.slave = omap3xxx_mmu_isp_hwmod,
- .addr = omap3xxx_mmu_isp_addrs,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
static struct omap_hwmod omap3xxx_mmu_isp_hwmod = {
.name = mmu_isp,
.class = omap3xxx_mmu_hwmod_class,
- .mpu_irqs = omap3xxx_mmu_isp_irqs,
.main_clk = cam_ick,
- .dev_attr = mmu_isp_dev_attr,
.flags = HWMOD_NO_IDLEST,
};
/* mmu iva */
-static struct omap_mmu_dev_attr mmu_iva_dev_attr = {
- .da_start = 0x1100,
- .da_end = 0xf000,
- .nr_tlb_entries = 32,
-};
-
static struct omap_hwmod omap3xxx_mmu_iva_hwmod;
-static struct omap_hwmod_irq_info omap3xxx_mmu_iva_irqs[] = {
- { .irq = 28 + OMAP_INTC_START, },
- { .irq = -1 }
-};
-
static struct omap_hwmod_rst_info omap3xxx_mmu_iva_resets[] = {
{ .name = mmu, .rst_shift = 1, .st_shift = 9 },
};
-static struct omap_hwmod_addr_space omap3xxx_mmu_iva_addrs[] = {
- {
- .pa_start = 0x5d00,
- .pa_end = 0x5d7f,
- .flags = ADDR_TYPE_RT,
- },
- { }
-};
-
/* l3_main - iva mmu */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__mmu_iva = {
.master = omap3xxx_l3_main_hwmod,
.slave = omap3xxx_mmu_iva_hwmod,
- .addr = omap3xxx_mmu_iva_addrs,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.name = mmu_iva,
.class = omap3xxx_mmu_hwmod_class,
- .mpu_irqs = omap3xxx_mmu_iva_irqs,
.clkdm_name = iva2_clkdm,
.rst_lines = omap3xxx_mmu_iva_resets,
.rst_lines_cnt = ARRAY_SIZE(omap3xxx_mmu_iva_resets),
@@ -3080,7 +3035,6 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.idlest_idle_bit = OMAP3430_ST_IVA2_SHIFT,
},
},
- .dev_attr = mmu_iva_dev_attr,
.flags = HWMOD_NO_IDLEST,
};
--
1.8.5.3
___
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
* Laurent Pinchart laurent.pinch...@ideasonboard.com [140225 13:18]: 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 Acked-by: Tony Lindgren t...@atomide.com ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 10/16] ARM: OMAP2+: use pdata quirks for iommu reset lines
Hi Tony,
On 02/26/2014 11:17 AM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [140213 10:19]:
The OMAP iommu driver performs the reset management for the
iommu instances in processor sub-systems using the omap_device
API which are currently supplied as platform data ops. Use pdata
quirks to maintain the functionality as the OMAP iommu driver
gets converted to use DT nodes, until the reset portions are
decoupled from omap_hwmod/omap_device into a separate reset
driver.
This patch adds the pdata quirks for the reset management of
iommus within the DSP (OMAP3 OMAP4) and IPU subsystems (OMAP4).
Signed-off-by: Suman Anna s-a...@ti.com
Looks OK, but I suggest you separate out the remaining patches in
this series into another clean-up series. Then the clean-up series
can be merged later on as these have a good chance of conflicting
with other stuff.
Only patches 14 through 16 are cleanup patches. Patches 12 and 13 are
adding OMAP5 functionality, and Patch11 is fixing up OMAP3 IVA. I would
have to drop Patch14 and Patch16 until OMAP3 is completely DT, so will
drop them for now. Let me know if you want me to split out the remaining
applicable patches that are in arch/arm/ into a separate series.
regards
Suman
Tony
---
arch/arm/mach-omap2/pdata-quirks.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 3d5b24d..74e094a 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -16,12 +16,14 @@
#include linux/wl12xx.h
#include linux/platform_data/pinctrl-single.h
+#include linux/platform_data/iommu-omap.h
#include am35xx.h
#include common.h
#include common-board-devices.h
#include dss-common.h
#include control.h
+#include omap_device.h
struct pdata_init {
const char *compatible;
@@ -92,6 +94,12 @@ static void __init hsmmc2_internal_input_clk(void)
omap_ctrl_writel(reg, OMAP343X_CONTROL_DEVCONF1);
}
+static struct iommu_platform_data omap3_iommu_pdata = {
+ .reset_name = mmu,
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
+
static int omap3_sbc_t3730_twl_callback(struct device *dev,
unsigned gpio,
unsigned ngpio)
@@ -185,6 +193,12 @@ static void __init omap4_panda_legacy_init(void)
legacy_init_ehci_clk(auxclk3_ck);
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
+
+static struct iommu_platform_data omap4_iommu_pdata = {
+ .reset_name = mmu_cache,
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
#endif
#ifdef CONFIG_SOC_OMAP5
@@ -240,6 +254,8 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002030, 48002030.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002a00, 48002a00.pinmux,
pcs_pdata),
+ OF_DEV_AUXDATA(ti,omap2-iommu, 0x5d00, 5d00.mmu,
+ omap3_iommu_pdata),
/* Only on am3517 */
OF_DEV_AUXDATA(ti,davinci_mdio, 0x5c03, davinci_mdio.0, NULL),
OF_DEV_AUXDATA(ti,am3517-emac, 0x5c00, davinci_emac.0,
@@ -248,6 +264,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux,
pcs_pdata),
+ OF_DEV_AUXDATA(ti,omap4-iommu, 0x4a066000, 4a066000.mmu,
+ omap4_iommu_pdata),
+ OF_DEV_AUXDATA(ti,omap4-iommu, 0x55082000, 55082000.mmu,
+ omap4_iommu_pdata),
#endif
{ /* sentinel */ },
};
--
1.8.5.3
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 04/16] iommu/omap: add devicetree support
* Suman Anna s-a...@ti.com [140213 10:19]:
From: Florian Vaussard florian.vauss...@epfl.ch
As OMAP2+ is moving to a full DT boot for all SoC families, commit
7ce93f3 ARM: OMAP2+: Fix more missing data for omap3.dtsi file
adds basic DT bits for OMAP3. But the driver is not yet converted,
so this will not work and driver will not be probed. Convert it!
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: dev_name adaptation and improved error checking]
Signed-off-by: Suman Anna s-a...@ti.com
Best that this gets merged along with the other iommu patches, so
for the arch/arm/*omap* parts:
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap-iommu.c | 5 +
drivers/iommu/omap-iommu.c | 41
2 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c
b/arch/arm/mach-omap2/omap-iommu.c
index f6daae8..f1fab56 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -10,6 +10,7 @@
* published by the Free Software Foundation.
*/
+#include linux/of.h
#include linux/module.h
#include linux/platform_device.h
#include linux/err.h
@@ -58,6 +59,10 @@ static int __init omap_iommu_dev_init(struct omap_hwmod
*oh, void *unused)
static int __init omap_iommu_init(void)
{
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
return omap_hwmod_for_each_by_class(mmu, omap_iommu_dev_init, NULL);
}
/* must be ready before omap3isp is probed */
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 6272c36..4329ab1 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -23,6 +23,9 @@
#include linux/spinlock.h
#include linux/io.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_iommu.h
+#include linux/of_irq.h
#include asm/cacheflush.h
@@ -937,20 +940,41 @@ static int omap_iommu_probe(struct platform_device
*pdev)
{
int err = -ENODEV;
int irq;
+ size_t len;
struct omap_iommu *obj;
struct resource *res;
struct iommu_platform_data *pdata = pdev-dev.platform_data;
+ struct device_node *of = pdev-dev.of_node;
obj = devm_kzalloc(pdev-dev, sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
if (!obj)
return -ENOMEM;
- obj-nr_tlb_entries = pdata-nr_tlb_entries;
- obj-name = pdata-name;
+ if (of) {
+ obj-name = dev_name(pdev-dev);
+ obj-nr_tlb_entries = 32;
+ err = of_property_read_u32(of, ti,#tlb-entries,
+obj-nr_tlb_entries);
+ if (err err != -EINVAL)
+ return err;
+ if (obj-nr_tlb_entries != 32 obj-nr_tlb_entries != 8)
+ return -EINVAL;
+ err = of_get_dma_window(of, NULL, 0, NULL, obj-da_start,
+ len);
+ if (err != 0)
+ return err;
+ obj-da_end = obj-da_start + len;
+ } else {
+ obj-nr_tlb_entries = pdata-nr_tlb_entries;
+ obj-name = pdata-name;
+ obj-da_start = pdata-da_start;
+ obj-da_end = pdata-da_end;
+ }
+ if (obj-da_end = obj-da_start)
+ return -EINVAL;
+
obj-dev = pdev-dev;
obj-ctx = (void *)obj + sizeof(*obj);
- obj-da_start = pdata-da_start;
- obj-da_end = pdata-da_end;
spin_lock_init(obj-iommu_lock);
mutex_init(obj-mmap_lock);
@@ -991,11 +1015,20 @@ static int omap_iommu_remove(struct platform_device
*pdev)
return 0;
}
+static struct of_device_id omap_iommu_of_match[] = {
+ { .compatible = ti,omap2-iommu },
+ { .compatible = ti,omap4-iommu },
+ { .compatible = ti,dra7-iommu },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_iommu_of_match);
+
static struct platform_driver omap_iommu_driver = {
.probe = omap_iommu_probe,
.remove = omap_iommu_remove,
.driver = {
.name = omap-iommu,
+ .of_match_table = of_match_ptr(omap_iommu_of_match),
},
};
--
1.8.5.3
___
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 Wednesday 26 February 2014 14:23:03 Suman Anna wrote: On Wednesday 26 February 2014 11:02:24 Suman Anna wrote: On 02/25/2014 08:13 PM, Laurent Pinchart wrote: 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 ? I should have rephrased it better when I said addressable range. While the MMUs are capable of programming the full 4GB space, there are some address ranges that are private from the processor view. This window is currently used to set the range for the omap-iovmm driver (which only OMAP3 ISP is using atm), and there is no point in allowing the omap-iovmm driver the full range when the processor could never reach/access those addresses. But the IOMMU VA space is from a device point of view, not from a CPU point of view. Could you point me to where those private ranges are documented, in order to understand the problem correctly ? Yes, they are indeed from the device perspective. I meant DSP and/or IPU by processor. For example on OMAP3, you can refer to Table 2-9 in section 2.4.5 DSP Subsystem Memory Space Mapping of the OMAP36xx TRM, and the external addressable range starts from 0x1100. OK, so it looks more like a property of the IOMMU master than a property of the IOMMU itself. It would be better to express it as such, but I wonder how that could be done, and if it would be worth it in this case. As not all masters (the OMAP3 ISP doesn't for instance) have restrictions regarding the VA range they can address, should this property be at least made optional ? 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
Re: [PATCH 3/4] ARM: dts: OMAP4: Add IOMMU nodes
Hi Suman,
Thank you for the patch.
On Thursday 13 February 2014 12:22:55 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
Add the IOMMU nodes for the DSP and IPU subsystems. The external
address space for DSP starts at 0x2000 in OMAP4 compared to
0x1100 in OMAP3, and the addresses beyond 0xE000 are
private address space for the Cortex-M3 cores in the IPU subsystem.
The MMU within the IPU sub-system also supports a bus error back
capability, not available on the DSP MMU.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: dma-window updates and bus error back addition]
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..1885f90 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -461,6 +461,23 @@
dma-names = tx, rx;
};
+ mmu_dsp: mmu@4a066000 {
+ compatible = ti,omap4-iommu;
+ reg = 0x4a066000 0xff;
+ interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mmu_dsp;
+ dma-window = 0x2000 0xd000;
+ };
+
+ mmu_ipu: mmu@55082000 {
+ compatible = ti,omap4-iommu;
+ reg = 0x55082000 0xff;
+ interrupts = GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mmu_ipu;
+ dma-window = 0 0xd000;
I'm not too familiar with the M3 MPU in the OMAP4, but doesn't its memory map
also include other reserved regions, such as 0x5504- 0x5505 to access
the ISS ?
+ ti,iommu-bus-err-back;
+ };
+
wdt2: wdt@4a314000 {
compatible = ti,omap4-wdt, ti,omap3-wdt;
reg = 0x4a314000 0x80;
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 1/1] iommu/amd: Fix PASID format in INVALIDATE_IOTLB_PAGES command
From: Jay Cornwall jay.cornw...@amd.com This patch corrects the PASID format in the INVALIDATE_IOTLB_PAGES command, which was caused by incorrect information in the AMD IOMMU Architectural Specification v2.01 document. Incorrect format: cmd-data[0][16:23] = PASID[7:0] cmd-data[1][16:27] = PASID[19:8] Correct format: cmd-data[0][16:23] = PASID[15:8] cmd-data[1][16:23] = PASID[7:0] However, this does not affect the IOMMUv2 hardware implementation, and has been corrected since version 2.02 of the specification (available through AMD NDA). Signed-off-by: Jay Cornwall jay.cornw...@amd.com Reviewed-by: Suravee Suthikulpanit suravee.suthikulpa...@amd.com --- drivers/iommu/amd_iommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index faf0da4..1dd9f81 100644 --- a/drivers/iommu/amd_iommu.c +++ b/drivers/iommu/amd_iommu.c @@ -982,10 +982,10 @@ static void build_inv_iotlb_pasid(struct iommu_cmd *cmd, u16 devid, int pasid, address = ~(0xfffULL); cmd-data[0] = devid; - cmd-data[0] |= (pasid 0xff) 16; + cmd-data[0] |= ((pasid 8) 0xff) 16; cmd-data[0] |= (qdep 0xff) 24; cmd-data[1] = devid; - cmd-data[1] |= ((pasid 8) 0xfff) 16; + cmd-data[1] |= (pasid 0xff) 16; cmd-data[2] = lower_32_bits(address); cmd-data[2] |= CMD_INV_IOMMU_PAGES_GN_MASK; cmd-data[3] = upper_32_bits(address); -- 1.8.1.2 ___ 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 Laurent, On 02/26/2014 02:36 PM, Laurent Pinchart wrote: Hi Suman, On Wednesday 26 February 2014 14:23:03 Suman Anna wrote: On Wednesday 26 February 2014 11:02:24 Suman Anna wrote: On 02/25/2014 08:13 PM, Laurent Pinchart wrote: 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 ? I should have rephrased it better when I said addressable range. While the MMUs are capable of programming the full 4GB space, there are some address ranges that are private from the processor view. This window is currently used to set the range for the omap-iovmm driver (which only OMAP3 ISP is using atm), and there is no point in allowing the omap-iovmm driver the full range when the processor could never reach/access those addresses. But the IOMMU VA space is from a device point of view, not from a CPU point of view. Could you point me to where those private ranges are documented, in order to understand the problem correctly ? Yes, they are indeed from the device perspective. I meant DSP and/or IPU by processor. For example on OMAP3, you can refer to Table 2-9 in section 2.4.5 DSP Subsystem Memory Space Mapping of the OMAP36xx TRM, and the external addressable range starts from 0x1100. OK, so it looks more like a property of the IOMMU master than a property of the IOMMU itself. It would be better to express it as such, but I wonder how that could be done, and if it would be worth it in this case. This property is currently solely used to configure the range for the omap-iovmm module, which were supplied through platform data in the non-DT case. I am wondering if the way to go here is to use iommu_domain_set_attr() and use the domain geometry values. regards Suman As not all masters (the OMAP3 ISP doesn't for instance) have restrictions regarding the VA range they can address, should this property be at least made optional ? 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
Re: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
On 02/26/2014 04:18 PM, Suman Anna wrote: Hi Laurent, On 02/26/2014 02:36 PM, Laurent Pinchart wrote: Hi Suman, On Wednesday 26 February 2014 14:23:03 Suman Anna wrote: On Wednesday 26 February 2014 11:02:24 Suman Anna wrote: On 02/25/2014 08:13 PM, Laurent Pinchart wrote: 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 ? I should have rephrased it better when I said addressable range. While the MMUs are capable of programming the full 4GB space, there are some address ranges that are private from the processor view. This window is currently used to set the range for the omap-iovmm driver (which only OMAP3 ISP is using atm), and there is no point in allowing the omap-iovmm driver the full range when the processor could never reach/access those addresses. But the IOMMU VA space is from a device point of view, not from a CPU point of view. Could you point me to where those private ranges are documented, in order to understand the problem correctly ? Yes, they are indeed from the device perspective. I meant DSP and/or IPU by processor. For example on OMAP3, you can refer to Table 2-9 in section 2.4.5 DSP Subsystem Memory Space Mapping of the OMAP36xx TRM, and the external addressable range starts from 0x1100. OK, so it looks more like a property of the IOMMU master than a property of the IOMMU itself. It would be better to express it as such, but I wonder how that could be done, and if it would be worth it in this case. This property is currently solely used to configure the range for the omap-iovmm module, which were supplied through platform data in the non-DT case. I am wondering if the way to go here is to use iommu_domain_set_attr() and use the domain geometry values. The other option is to supply these as driver match data, and switching the compatible strings to identify the MMU instance precisely. regards Suman As not all masters (the OMAP3 ISP doesn't for instance) have restrictions regarding the VA range they can address, should this property be at least made optional ? 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
Re: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
Hi Suman, On Wednesday 26 February 2014 16:28:08 Suman Anna wrote: On 02/26/2014 04:18 PM, Suman Anna wrote: On 02/26/2014 02:36 PM, Laurent Pinchart wrote: On Wednesday 26 February 2014 14:23:03 Suman Anna wrote: On Wednesday 26 February 2014 11:02:24 Suman Anna wrote: On 02/25/2014 08:13 PM, Laurent Pinchart wrote: 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 ? I should have rephrased it better when I said addressable range. While the MMUs are capable of programming the full 4GB space, there are some address ranges that are private from the processor view. This window is currently used to set the range for the omap-iovmm driver (which only OMAP3 ISP is using atm), and there is no point in allowing the omap-iovmm driver the full range when the processor could never reach/access those addresses. But the IOMMU VA space is from a device point of view, not from a CPU point of view. Could you point me to where those private ranges are documented, in order to understand the problem correctly ? Yes, they are indeed from the device perspective. I meant DSP and/or IPU by processor. For example on OMAP3, you can refer to Table 2-9 in section 2.4.5 DSP Subsystem Memory Space Mapping of the OMAP36xx TRM, and the external addressable range starts from 0x1100. OK, so it looks more like a property of the IOMMU master than a property of the IOMMU itself. It would be better to express it as such, but I wonder how that could be done, and if it would be worth it in this case. This property is currently solely used to configure the range for the omap-iovmm module, which were supplied through platform data in the non-DT case. If I'm not mistaken omap-iovmm is something we want to get rid of. I know that the OMAP3 ISP driver is the only user of that module, and I've started working on fixing that, but I'm currently lacking time to complete the work. Now, if we get rid of omap-iovmm, does that mean that the dma-window property won't need to be specified anymore ? If so, given that the only omap-iovmm user is the OMAP3 ISP driver, I would propose to drop the property and just hardcode the value. Please let me know if there's something I've missed. I am wondering if the way to go here is to use iommu_domain_set_attr() and use the domain geometry values. The other option is to supply these as driver match data, and switching the compatible strings to identify the MMU instance precisely. regards Suman As not all masters (the OMAP3 ISP doesn't for instance) have restrictions regarding the VA range they can address, should this property be at least made optional ? 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. [snip] -- 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 Laurent, On Wednesday 26 February 2014 16:28:08 Suman Anna wrote: On 02/26/2014 04:18 PM, Suman Anna wrote: On 02/26/2014 02:36 PM, Laurent Pinchart wrote: On Wednesday 26 February 2014 14:23:03 Suman Anna wrote: On Wednesday 26 February 2014 11:02:24 Suman Anna wrote: On 02/25/2014 08:13 PM, Laurent Pinchart wrote: 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 ? I should have rephrased it better when I said addressable range. While the MMUs are capable of programming the full 4GB space, there are some address ranges that are private from the processor view. This window is currently used to set the range for the omap-iovmm driver (which only OMAP3 ISP is using atm), and there is no point in allowing the omap-iovmm driver the full range when the processor could never reach/access those addresses. But the IOMMU VA space is from a device point of view, not from a CPU point of view. Could you point me to where those private ranges are documented, in order to understand the problem correctly ? Yes, they are indeed from the device perspective. I meant DSP and/or IPU by processor. For example on OMAP3, you can refer to Table 2-9 in section 2.4.5 DSP Subsystem Memory Space Mapping of the OMAP36xx TRM, and the external addressable range starts from 0x1100. OK, so it looks more like a property of the IOMMU master than a property of the IOMMU itself. It would be better to express it as such, but I wonder how that could be done, and if it would be worth it in this case. This property is currently solely used to configure the range for the omap-iovmm module, which were supplied through platform data in the non-DT case. If I'm not mistaken omap-iovmm is something we want to get rid of. I know that the OMAP3 ISP driver is the only user of that module, and I've started working on fixing that, but I'm currently lacking time to complete the work. Now, if we get rid of omap-iovmm, does that mean that the dma-window property won't need to be specified anymore ? If so, given that the only omap-iovmm user is the OMAP3 ISP driver, I would propose to drop the property and just hardcode the value. Yeah, none of our OMAP4+ stacks use omap-iovmm, or similar dynamic reservation scheme at the moment. I am perfectly fine with dropping the property and hard-coding it in the driver with a note. DSP/Bridge has a similar usage (in dmm.c), but that code is localized within the driver. Thanks for all the comments. regards Suman Please let me know if there's something I've missed. I am wondering if the way to go here is to use iommu_domain_set_attr() and use the domain geometry values. The other option is to supply these as driver match data, and switching the compatible strings to identify the MMU instance precisely. regards Suman As not all masters (the OMAP3 ISP doesn't for instance) have restrictions regarding the VA range they can address, should this property be at least made optional ? 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. [snip]
Re: IOMMU DMA-mapping API for arm64 ?
Hi Everyone, I was going through some iommu code in arch/arm and of some other archs code. I have some doubts on this for refactoring and may need some suggestions from you guys. 1. So, looking at other arch code, looks like they have their different way of implementation of iova management and buffer allocation. So to refactor the iommu common code out from arch/arm/ to lib/iommu-helper, do we need to take care across all arch ? 2. Should the approach be like take the common code(between arm/arm64) and move it into lib/iommu-helper.c ? Could someone give an example of what sort of code(will be better if this is little more specific) we are talking here to be taken out to lib/iommu-helper.c ? Earlier I was thinking of iova management can be taken out but then I saw it might not be suited across all archs. I am ready to do this work, but need some guidance from the experts . Thanks Ritesh On Thu, Feb 6, 2014 at 5:29 PM, Ritesh Harjani ritesh.harj...@gmail.com wrote: On Thu, Feb 6, 2014 at 3:43 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Thu, Feb 06, 2014 at 05:21:53AM +, Ritesh Harjani wrote: I also saw one mail discussion between you guys on what is the best place for adding iommu support in ARM64, but couldn't see any followed up patches for the same. The decision was to make take the iommu code from arch/arm and turn it into a library similar to swiotlb which can be used by the arch code. It is on our to-do list but no ETA yet. If you volunteer to help it would be great ;) Sure Catalin, will take out the common code from arch/arm and put into lib/iommu-helper which is the best place as discussed in many mail chains. Let me see how far I can go. Will keep you posted. -- Catalin Thanks Ritesh ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
