* [PATCH 1/6] ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
2012-06-16 1:55 ` Omar Ramirez Luna
@ 2012-06-16 1:55 ` Omar Ramirez Luna
-1 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-06-16 1:55 UTC (permalink / raw)
To: Tony Lindgren, Benoit Cousson
Cc: Ohad Ben-Cohen, Russell King,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Laurent Pinchart, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
If included without IOMMU_API being selected it will break
compilation:
arch/arm/plat-omap/include/plat/iommu.h:
In function 'dev_to_omap_iommu':
arch/arm/plat-omap/include/plat/iommu.h:148:
error: 'struct dev_archdata' has no member named 'iommu'
This will be seen, when hwmod includes iommu.h to get the
structure for attributes.
Signed-off-by: Omar Ramirez Luna <omar.luna-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm/plat-omap/include/plat/iommu.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index 88be3e6..e58d571 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -126,6 +126,7 @@ struct omap_iommu_arch_data {
struct omap_iommu *iommu_dev;
};
+#ifdef CONFIG_IOMMU_API
/**
* dev_to_omap_iommu() - retrieves an omap iommu object from a user device
* @dev: iommu client device
@@ -136,6 +137,7 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev)
return arch_data->iommu_dev;
}
+#endif
/* IOMMU errors */
#define OMAP_IOMMU_ERR_TLB_MISS (1 << 0)
--
1.7.4.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 1/6] ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
@ 2012-06-16 1:55 ` Omar Ramirez Luna
0 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-06-16 1:55 UTC (permalink / raw)
To: linux-arm-kernel
If included without IOMMU_API being selected it will break
compilation:
arch/arm/plat-omap/include/plat/iommu.h:
In function 'dev_to_omap_iommu':
arch/arm/plat-omap/include/plat/iommu.h:148:
error: 'struct dev_archdata' has no member named 'iommu'
This will be seen, when hwmod includes iommu.h to get the
structure for attributes.
Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
---
arch/arm/plat-omap/include/plat/iommu.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index 88be3e6..e58d571 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -126,6 +126,7 @@ struct omap_iommu_arch_data {
struct omap_iommu *iommu_dev;
};
+#ifdef CONFIG_IOMMU_API
/**
* dev_to_omap_iommu() - retrieves an omap iommu object from a user device
* @dev: iommu client device
@@ -136,6 +137,7 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev)
return arch_data->iommu_dev;
}
+#endif
/* IOMMU errors */
#define OMAP_IOMMU_ERR_TLB_MISS (1 << 0)
--
1.7.4.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH 2/6] ARM: OMAP3: hwmod data: add mmu data for iva and isp
2012-06-16 1:55 ` Omar Ramirez Luna
@ 2012-06-16 1:56 ` Omar Ramirez Luna
-1 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-06-16 1:56 UTC (permalink / raw)
To: Tony Lindgren, Benoit Cousson
Cc: Ohad Ben-Cohen, Russell King,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Laurent Pinchart, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Add mmu hwmod data for iva and isp.
Due to compatibility an ifdef CONFIG_OMAP_IOMMU_IVA2 needs to be
propagated (previously on iommu resource info) to hwmod data in OMAP3,
so users of iommu and tidspbridge can avoid issues of two modules
managing mmu data/irqs/resets; this until tidspbridge can be migrated
to iommu framework.
Signed-off-by: Omar Ramirez Luna <omar.luna-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 117 ++++++++++++++++++++++++++++
arch/arm/plat-omap/include/plat/iommu.h | 13 +++
2 files changed, 130 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0ea53bc..89df566 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -27,6 +27,7 @@
#include <plat/mcbsp.h>
#include <plat/mcspi.h>
#include <plat/dmtimer.h>
+#include <plat/iommu.h>
#include "omap_hwmod_common_data.h"
@@ -2777,6 +2778,118 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio3 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig mmu_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_mmu_hwmod_class = {
+ .name = "mmu",
+ .sysc = &mmu_sysc,
+};
+
+/* isp mmu */
+
+static struct omap_mmu_dev_attr isp_mmu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xfffff000,
+ .nr_tlb_entries = 8,
+};
+
+static struct omap_hwmod omap3xxx_isp_mmu_hwmod;
+static struct omap_hwmod_irq_info omap3xxx_isp_mmu_irqs[] = {
+ { .irq = 24 },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_addr_space omap3xxx_isp_mmu_addrs[] = {
+ {
+ .pa_start = 0x480bd400,
+ .pa_end = 0x480bd47f,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l4_core -> isp mmu */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__isp_mmu = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap3xxx_isp_mmu_hwmod,
+ .addr = omap3xxx_isp_mmu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap3xxx_isp_mmu_hwmod = {
+ .name = "isp_mmu",
+ .class = &omap3xxx_mmu_hwmod_class,
+ .mpu_irqs = omap3xxx_isp_mmu_irqs,
+ .main_clk = "cam_ick",
+ .dev_attr = &isp_mmu_dev_attr,
+ .flags = HWMOD_NO_IDLEST,
+};
+
+/* iva mmu */
+
+static struct omap_mmu_dev_attr iva_mmu_dev_attr = {
+ .da_start = 0x11000000,
+ .da_end = 0xfffff000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap3xxx_iva_mmu_hwmod;
+static struct omap_hwmod_irq_info omap3xxx_iva_mmu_irqs[] = {
+ { .irq = 28 },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap3xxx_iva_mmu_resets[] = {
+ { .name = "mmu", .rst_shift = 1, .st_shift = 9 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_iva_mmu_addrs[] = {
+ {
+ .pa_start = 0x5d000000,
+ .pa_end = 0x5d00007f,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l3_main -> iva mmu */
+static struct omap_hwmod_ocp_if omap3xxx_l3_main__iva_mmu = {
+ .master = &omap3xxx_l3_main_hwmod,
+ .slave = &omap3xxx_iva_mmu_hwmod,
+ .addr = omap3xxx_iva_mmu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap3xxx_iva_mmu_hwmod = {
+ .name = "iva_mmu",
+ .class = &omap3xxx_mmu_hwmod_class,
+ .mpu_irqs = omap3xxx_iva_mmu_irqs,
+ .rst_lines = omap3xxx_iva_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap3xxx_iva_mmu_resets),
+ .main_clk = "iva2_ck",
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430_IVA2_MOD,
+ },
+ },
+ .dev_attr = &iva_mmu_dev_attr,
+ .flags = HWMOD_NO_IDLEST,
+};
+
/* l4_per -> gpio4 */
static struct omap_hwmod_addr_space omap3xxx_gpio4_addrs[] = {
{
@@ -3174,6 +3287,10 @@ static struct omap_hwmod_ocp_if *omap3xxx_hwmod_ocp_ifs[] __initdata = {
&omap34xx_l4_core__mcspi2,
&omap34xx_l4_core__mcspi3,
&omap34xx_l4_core__mcspi4,
+ &omap3xxx_l4_core__isp_mmu,
+#ifdef CONFIG_OMAP_IOMMU_IVA2
+ &omap3xxx_l3_main__iva_mmu,
+#endif
&omap3xxx_l4_wkup__counter_32k,
NULL,
};
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index e58d571..44518cc 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -103,6 +103,19 @@ struct iommu_functions {
ssize_t (*dump_ctx)(struct omap_iommu *obj, char *buf, ssize_t len);
};
+/**
+ * omap_mmu_dev_attr - OMAP mmu device attributes for omap_hwmod
+ * @da_start: device address where the va space starts.
+ * @da_end: device address where the va space ends.
+ * @nr_tlb_entries: number of entries supported by the translation
+ * look-aside buffer (TLB).
+ */
+struct omap_mmu_dev_attr {
+ u32 da_start;
+ u32 da_end;
+ int nr_tlb_entries;
+};
+
struct iommu_platform_data {
const char *name;
const char *clk_name;
--
1.7.4.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 2/6] ARM: OMAP3: hwmod data: add mmu data for iva and isp
@ 2012-06-16 1:56 ` Omar Ramirez Luna
0 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-06-16 1:56 UTC (permalink / raw)
To: linux-arm-kernel
Add mmu hwmod data for iva and isp.
Due to compatibility an ifdef CONFIG_OMAP_IOMMU_IVA2 needs to be
propagated (previously on iommu resource info) to hwmod data in OMAP3,
so users of iommu and tidspbridge can avoid issues of two modules
managing mmu data/irqs/resets; this until tidspbridge can be migrated
to iommu framework.
Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 117 ++++++++++++++++++++++++++++
arch/arm/plat-omap/include/plat/iommu.h | 13 +++
2 files changed, 130 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0ea53bc..89df566 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -27,6 +27,7 @@
#include <plat/mcbsp.h>
#include <plat/mcspi.h>
#include <plat/dmtimer.h>
+#include <plat/iommu.h>
#include "omap_hwmod_common_data.h"
@@ -2777,6 +2778,118 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio3 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig mmu_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_mmu_hwmod_class = {
+ .name = "mmu",
+ .sysc = &mmu_sysc,
+};
+
+/* isp mmu */
+
+static struct omap_mmu_dev_attr isp_mmu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xfffff000,
+ .nr_tlb_entries = 8,
+};
+
+static struct omap_hwmod omap3xxx_isp_mmu_hwmod;
+static struct omap_hwmod_irq_info omap3xxx_isp_mmu_irqs[] = {
+ { .irq = 24 },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_addr_space omap3xxx_isp_mmu_addrs[] = {
+ {
+ .pa_start = 0x480bd400,
+ .pa_end = 0x480bd47f,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l4_core -> isp mmu */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__isp_mmu = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap3xxx_isp_mmu_hwmod,
+ .addr = omap3xxx_isp_mmu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap3xxx_isp_mmu_hwmod = {
+ .name = "isp_mmu",
+ .class = &omap3xxx_mmu_hwmod_class,
+ .mpu_irqs = omap3xxx_isp_mmu_irqs,
+ .main_clk = "cam_ick",
+ .dev_attr = &isp_mmu_dev_attr,
+ .flags = HWMOD_NO_IDLEST,
+};
+
+/* iva mmu */
+
+static struct omap_mmu_dev_attr iva_mmu_dev_attr = {
+ .da_start = 0x11000000,
+ .da_end = 0xfffff000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap3xxx_iva_mmu_hwmod;
+static struct omap_hwmod_irq_info omap3xxx_iva_mmu_irqs[] = {
+ { .irq = 28 },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap3xxx_iva_mmu_resets[] = {
+ { .name = "mmu", .rst_shift = 1, .st_shift = 9 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_iva_mmu_addrs[] = {
+ {
+ .pa_start = 0x5d000000,
+ .pa_end = 0x5d00007f,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l3_main -> iva mmu */
+static struct omap_hwmod_ocp_if omap3xxx_l3_main__iva_mmu = {
+ .master = &omap3xxx_l3_main_hwmod,
+ .slave = &omap3xxx_iva_mmu_hwmod,
+ .addr = omap3xxx_iva_mmu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap3xxx_iva_mmu_hwmod = {
+ .name = "iva_mmu",
+ .class = &omap3xxx_mmu_hwmod_class,
+ .mpu_irqs = omap3xxx_iva_mmu_irqs,
+ .rst_lines = omap3xxx_iva_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap3xxx_iva_mmu_resets),
+ .main_clk = "iva2_ck",
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430_IVA2_MOD,
+ },
+ },
+ .dev_attr = &iva_mmu_dev_attr,
+ .flags = HWMOD_NO_IDLEST,
+};
+
/* l4_per -> gpio4 */
static struct omap_hwmod_addr_space omap3xxx_gpio4_addrs[] = {
{
@@ -3174,6 +3287,10 @@ static struct omap_hwmod_ocp_if *omap3xxx_hwmod_ocp_ifs[] __initdata = {
&omap34xx_l4_core__mcspi2,
&omap34xx_l4_core__mcspi3,
&omap34xx_l4_core__mcspi4,
+ &omap3xxx_l4_core__isp_mmu,
+#ifdef CONFIG_OMAP_IOMMU_IVA2
+ &omap3xxx_l3_main__iva_mmu,
+#endif
&omap3xxx_l4_wkup__counter_32k,
NULL,
};
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index e58d571..44518cc 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -103,6 +103,19 @@ struct iommu_functions {
ssize_t (*dump_ctx)(struct omap_iommu *obj, char *buf, ssize_t len);
};
+/**
+ * omap_mmu_dev_attr - OMAP mmu device attributes for omap_hwmod
+ * @da_start: device address where the va space starts.
+ * @da_end: device address where the va space ends.
+ * @nr_tlb_entries: number of entries supported by the translation
+ * look-aside buffer (TLB).
+ */
+struct omap_mmu_dev_attr {
+ u32 da_start;
+ u32 da_end;
+ int nr_tlb_entries;
+};
+
struct iommu_platform_data {
const char *name;
const char *clk_name;
--
1.7.4.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
2012-06-16 1:55 ` Omar Ramirez Luna
@ 2012-06-16 1:56 ` Omar Ramirez Luna
-1 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-06-16 1:56 UTC (permalink / raw)
To: Tony Lindgren, Benoit Cousson
Cc: Ohad Ben-Cohen, Russell King,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Laurent Pinchart, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Add mmu hwmod data for ipu and dsp.
Signed-off-by: Omar Ramirez Luna <omar.luna-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 136 +++++++++++++++++++++++++++-
1 files changed, 134 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ebf9657..3879e9c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -30,6 +30,7 @@
#include <plat/mmc.h>
#include <plat/dmtimer.h>
#include <plat/common.h>
+#include <plat/iommu.h>
#include "omap_hwmod_common_data.h"
@@ -614,7 +615,6 @@ static struct omap_hwmod_irq_info omap44xx_dsp_irqs[] = {
static struct omap_hwmod_rst_info omap44xx_dsp_resets[] = {
{ .name = "dsp", .rst_shift = 0 },
- { .name = "mmu_cache", .rst_shift = 1 },
};
static struct omap_hwmod omap44xx_dsp_hwmod = {
@@ -1629,7 +1629,6 @@ static struct omap_hwmod_irq_info omap44xx_ipu_irqs[] = {
static struct omap_hwmod_rst_info omap44xx_ipu_resets[] = {
{ .name = "cpu0", .rst_shift = 0 },
{ .name = "cpu1", .rst_shift = 1 },
- { .name = "mmu_cache", .rst_shift = 2 },
};
static struct omap_hwmod omap44xx_ipu_hwmod = {
@@ -2436,6 +2435,137 @@ static struct omap_hwmod omap44xx_mmc5_hwmod = {
};
/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig mmu_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_mmu_hwmod_class = {
+ .name = "mmu",
+ .sysc = &mmu_sysc,
+};
+
+/* ipu mmu */
+
+static struct omap_mmu_dev_attr ipu_mmu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xfffff000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod;
+static struct omap_hwmod_irq_info omap44xx_ipu_mmu_irqs[] = {
+ { .irq = 100 + OMAP44XX_IRQ_GIC_START, },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_ipu_mmu_resets[] = {
+ { .name = "mmu_cache", .rst_shift = 2 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_ipu_mmu_addrs[] = {
+ {
+ .pa_start = 0x55082000,
+ .pa_end = 0x550820ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l3_main_2 -> ipu_mmu */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_2__ipu_mmu = {
+ .master = &omap44xx_l3_main_2_hwmod,
+ .slave = &omap44xx_ipu_mmu_hwmod,
+ .clk = "l3_div_ck",
+ .addr = omap44xx_ipu_mmu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
+ .name = "ipu_mmu",
+ .class = &omap44xx_mmu_hwmod_class,
+ .clkdm_name = "ducati_clkdm",
+ .mpu_irqs = omap44xx_ipu_mmu_irqs,
+ .rst_lines = omap44xx_ipu_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
+ .main_clk = "ipu_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .dev_attr = &ipu_mmu_dev_attr,
+};
+
+/* dsp mmu */
+
+static struct omap_mmu_dev_attr dsp_mmu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xfffff000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_dsp_mmu_hwmod;
+static struct omap_hwmod_irq_info omap44xx_dsp_mmu_irqs[] = {
+ { .irq = 28 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_dsp_mmu_resets[] = {
+ { .name = "mmu_cache", .rst_shift = 1 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_dsp_mmu_addrs[] = {
+ {
+ .pa_start = 0x4a066000,
+ .pa_end = 0x4a0660ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l4_cfg -> dsp */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__dsp_mmu = {
+ .master = &omap44xx_l4_cfg_hwmod,
+ .slave = &omap44xx_dsp_mmu_hwmod,
+ .clk = "l4_div_ck",
+ .addr = omap44xx_dsp_mmu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap44xx_dsp_mmu_hwmod = {
+ .name = "dsp_mmu",
+ .class = &omap44xx_mmu_hwmod_class,
+ .clkdm_name = "tesla_clkdm",
+ .mpu_irqs = omap44xx_dsp_mmu_irqs,
+ .rst_lines = omap44xx_dsp_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_dsp_mmu_resets),
+ .main_clk = "dsp_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_TESLA_TESLA_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_TESLA_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_TESLA_TESLA_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .dev_attr = &dsp_mmu_dev_attr,
+};
+
+/*
* 'mpu' class
* mpu sub-system
*/
@@ -6092,6 +6222,8 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
&omap44xx_l4_per__mmc3,
&omap44xx_l4_per__mmc4,
&omap44xx_l4_per__mmc5,
+ &omap44xx_l3_main_2__ipu_mmu,
+ &omap44xx_l4_cfg__dsp_mmu,
&omap44xx_l3_main_2__ocmc_ram,
&omap44xx_l4_cfg__ocp2scp_usb_phy,
&omap44xx_mpu_private__prcm_mpu,
--
1.7.4.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
@ 2012-06-16 1:56 ` Omar Ramirez Luna
0 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-06-16 1:56 UTC (permalink / raw)
To: linux-arm-kernel
Add mmu hwmod data for ipu and dsp.
Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 136 +++++++++++++++++++++++++++-
1 files changed, 134 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ebf9657..3879e9c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -30,6 +30,7 @@
#include <plat/mmc.h>
#include <plat/dmtimer.h>
#include <plat/common.h>
+#include <plat/iommu.h>
#include "omap_hwmod_common_data.h"
@@ -614,7 +615,6 @@ static struct omap_hwmod_irq_info omap44xx_dsp_irqs[] = {
static struct omap_hwmod_rst_info omap44xx_dsp_resets[] = {
{ .name = "dsp", .rst_shift = 0 },
- { .name = "mmu_cache", .rst_shift = 1 },
};
static struct omap_hwmod omap44xx_dsp_hwmod = {
@@ -1629,7 +1629,6 @@ static struct omap_hwmod_irq_info omap44xx_ipu_irqs[] = {
static struct omap_hwmod_rst_info omap44xx_ipu_resets[] = {
{ .name = "cpu0", .rst_shift = 0 },
{ .name = "cpu1", .rst_shift = 1 },
- { .name = "mmu_cache", .rst_shift = 2 },
};
static struct omap_hwmod omap44xx_ipu_hwmod = {
@@ -2436,6 +2435,137 @@ static struct omap_hwmod omap44xx_mmc5_hwmod = {
};
/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig mmu_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_mmu_hwmod_class = {
+ .name = "mmu",
+ .sysc = &mmu_sysc,
+};
+
+/* ipu mmu */
+
+static struct omap_mmu_dev_attr ipu_mmu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xfffff000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod;
+static struct omap_hwmod_irq_info omap44xx_ipu_mmu_irqs[] = {
+ { .irq = 100 + OMAP44XX_IRQ_GIC_START, },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_ipu_mmu_resets[] = {
+ { .name = "mmu_cache", .rst_shift = 2 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_ipu_mmu_addrs[] = {
+ {
+ .pa_start = 0x55082000,
+ .pa_end = 0x550820ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l3_main_2 -> ipu_mmu */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_2__ipu_mmu = {
+ .master = &omap44xx_l3_main_2_hwmod,
+ .slave = &omap44xx_ipu_mmu_hwmod,
+ .clk = "l3_div_ck",
+ .addr = omap44xx_ipu_mmu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
+ .name = "ipu_mmu",
+ .class = &omap44xx_mmu_hwmod_class,
+ .clkdm_name = "ducati_clkdm",
+ .mpu_irqs = omap44xx_ipu_mmu_irqs,
+ .rst_lines = omap44xx_ipu_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
+ .main_clk = "ipu_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .dev_attr = &ipu_mmu_dev_attr,
+};
+
+/* dsp mmu */
+
+static struct omap_mmu_dev_attr dsp_mmu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xfffff000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_dsp_mmu_hwmod;
+static struct omap_hwmod_irq_info omap44xx_dsp_mmu_irqs[] = {
+ { .irq = 28 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_dsp_mmu_resets[] = {
+ { .name = "mmu_cache", .rst_shift = 1 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_dsp_mmu_addrs[] = {
+ {
+ .pa_start = 0x4a066000,
+ .pa_end = 0x4a0660ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l4_cfg -> dsp */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__dsp_mmu = {
+ .master = &omap44xx_l4_cfg_hwmod,
+ .slave = &omap44xx_dsp_mmu_hwmod,
+ .clk = "l4_div_ck",
+ .addr = omap44xx_dsp_mmu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap44xx_dsp_mmu_hwmod = {
+ .name = "dsp_mmu",
+ .class = &omap44xx_mmu_hwmod_class,
+ .clkdm_name = "tesla_clkdm",
+ .mpu_irqs = omap44xx_dsp_mmu_irqs,
+ .rst_lines = omap44xx_dsp_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_dsp_mmu_resets),
+ .main_clk = "dsp_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_TESLA_TESLA_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_TESLA_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_TESLA_TESLA_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .dev_attr = &dsp_mmu_dev_attr,
+};
+
+/*
* 'mpu' class
* mpu sub-system
*/
@@ -6092,6 +6222,8 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
&omap44xx_l4_per__mmc3,
&omap44xx_l4_per__mmc4,
&omap44xx_l4_per__mmc5,
+ &omap44xx_l3_main_2__ipu_mmu,
+ &omap44xx_l4_cfg__dsp_mmu,
&omap44xx_l3_main_2__ocmc_ram,
&omap44xx_l4_cfg__ocp2scp_usb_phy,
&omap44xx_mpu_private__prcm_mpu,
--
1.7.4.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
2012-06-16 1:56 ` Omar Ramirez Luna
@ 2012-06-19 12:36 ` Cousson, Benoit
-1 siblings, 0 replies; 30+ messages in thread
From: Cousson, Benoit @ 2012-06-19 12:36 UTC (permalink / raw)
To: Omar Ramirez Luna
Cc: Tony Lindgren, Russell King, Ohad Ben-Cohen, Joerg Roedel,
Laurent Pinchart, Felipe Contreras, linux-omap, linux-arm-kernel,
iommu
Hi Omar,
On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
> Add mmu hwmod data for ipu and dsp.
>
> Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
> ---
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 136 +++++++++++++++++++++++++++-
> 1 files changed, 134 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index ebf9657..3879e9c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -30,6 +30,7 @@
> #include <plat/mmc.h>
> #include <plat/dmtimer.h>
> #include <plat/common.h>
> +#include <plat/iommu.h>
>
> #include "omap_hwmod_common_data.h"
>
> @@ -614,7 +615,6 @@ static struct omap_hwmod_irq_info omap44xx_dsp_irqs[] = {
>
> static struct omap_hwmod_rst_info omap44xx_dsp_resets[] = {
> { .name = "dsp", .rst_shift = 0 },
> - { .name = "mmu_cache", .rst_shift = 1 },
> };
>
> static struct omap_hwmod omap44xx_dsp_hwmod = {
> @@ -1629,7 +1629,6 @@ static struct omap_hwmod_irq_info omap44xx_ipu_irqs[] = {
> static struct omap_hwmod_rst_info omap44xx_ipu_resets[] = {
> { .name = "cpu0", .rst_shift = 0 },
> { .name = "cpu1", .rst_shift = 1 },
> - { .name = "mmu_cache", .rst_shift = 2 },
> };
>
> static struct omap_hwmod omap44xx_ipu_hwmod = {
> @@ -2436,6 +2435,137 @@ static struct omap_hwmod omap44xx_mmc5_hwmod = {
> };
>
> /*
> + * 'mmu' class
> + * The memory management unit performs virtual to physical address translation
> + * for its requestors.
> + */
> +
> +static struct omap_hwmod_class_sysconfig mmu_sysc = {
> + .rev_offs = 0x000,
> + .sysc_offs = 0x010,
> + .syss_offs = 0x014,
> + .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
> + SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> + .sysc_fields = &omap_hwmod_sysc_type1,
> +};
> +
> +static struct omap_hwmod_class omap44xx_mmu_hwmod_class = {
> + .name = "mmu",
> + .sysc = &mmu_sysc,
> +};
> +
> +/* ipu mmu */
> +
> +static struct omap_mmu_dev_attr ipu_mmu_dev_attr = {
> + .da_start = 0x0,
> + .da_end = 0xfffff000,
> + .nr_tlb_entries = 32,
> +};
> +
> +static struct omap_hwmod omap44xx_ipu_mmu_hwmod;
> +static struct omap_hwmod_irq_info omap44xx_ipu_mmu_irqs[] = {
> + { .irq = 100 + OMAP44XX_IRQ_GIC_START, },
> + { .irq = -1 }
> +};
> +
> +static struct omap_hwmod_rst_info omap44xx_ipu_mmu_resets[] = {
> + { .name = "mmu_cache", .rst_shift = 2 },
> +};
> +
> +static struct omap_hwmod_addr_space omap44xx_ipu_mmu_addrs[] = {
> + {
> + .pa_start = 0x55082000,
> + .pa_end = 0x550820ff,
> + .flags = ADDR_TYPE_RT,
> + },
> + { }
> +};
> +
> +/* l3_main_2 -> ipu_mmu */
> +static struct omap_hwmod_ocp_if omap44xx_l3_main_2__ipu_mmu = {
> + .master = &omap44xx_l3_main_2_hwmod,
> + .slave = &omap44xx_ipu_mmu_hwmod,
> + .clk = "l3_div_ck",
> + .addr = omap44xx_ipu_mmu_addrs,
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
> + .name = "ipu_mmu",
> + .class = &omap44xx_mmu_hwmod_class,
> + .clkdm_name = "ducati_clkdm",
> + .mpu_irqs = omap44xx_ipu_mmu_irqs,
> + .rst_lines = omap44xx_ipu_mmu_resets,
> + .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
> + .main_clk = "ipu_fck",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
> + .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
> + .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_HWCTRL,
> + },
> + },
> + .dev_attr = &ipu_mmu_dev_attr,
> +};
In fact, the MMU_IPU hwmod is now almost the same one than the previous IPU one...
If we do that we should maybe just rename the IPU -> MMU_IPU and DSP -> MMU_DSP.
But by doing that we will assume that the MMU does represent the subsystem, which is not necessarily super nice.
I guess that a much better representation will be to keep the subsystem (IPU) to handle the PRCM part:
+ .main_clk = "ipu_fck",
+ .prcm = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
And then the MMU_IPU will handle the configuration registers part and the reset + irq.
But then, you will have to create a parent child dependency between your devices to ensure that the IPU subsystem device will be enabled before trying to access the MMU_IPU.
This is what the DSS is about to do to handle the same kind of power dependency. The DSS device is the parent of all the DSS IPs (DISPC, HDMI...) and thus pm_runtime will ensure that the parent is enabled before trying to enable the children.
In term of DT, just to illustrate the situation, it will be something like that:
ipu {
compatible = "simple-bus";
ti,hwmods = "ipu";
ipu_mmu: mmu@4a066000 {
compatible = "omap-mmu";
ti,hwmods = "mmu_ipu";
reg...;
irqs...;
}
}
Is it something you can handle with your current framework?
Regards,
Benoit
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
@ 2012-06-19 12:36 ` Cousson, Benoit
0 siblings, 0 replies; 30+ messages in thread
From: Cousson, Benoit @ 2012-06-19 12:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi Omar,
On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
> Add mmu hwmod data for ipu and dsp.
>
> Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
> ---
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 136 +++++++++++++++++++++++++++-
> 1 files changed, 134 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index ebf9657..3879e9c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -30,6 +30,7 @@
> #include <plat/mmc.h>
> #include <plat/dmtimer.h>
> #include <plat/common.h>
> +#include <plat/iommu.h>
>
> #include "omap_hwmod_common_data.h"
>
> @@ -614,7 +615,6 @@ static struct omap_hwmod_irq_info omap44xx_dsp_irqs[] = {
>
> static struct omap_hwmod_rst_info omap44xx_dsp_resets[] = {
> { .name = "dsp", .rst_shift = 0 },
> - { .name = "mmu_cache", .rst_shift = 1 },
> };
>
> static struct omap_hwmod omap44xx_dsp_hwmod = {
> @@ -1629,7 +1629,6 @@ static struct omap_hwmod_irq_info omap44xx_ipu_irqs[] = {
> static struct omap_hwmod_rst_info omap44xx_ipu_resets[] = {
> { .name = "cpu0", .rst_shift = 0 },
> { .name = "cpu1", .rst_shift = 1 },
> - { .name = "mmu_cache", .rst_shift = 2 },
> };
>
> static struct omap_hwmod omap44xx_ipu_hwmod = {
> @@ -2436,6 +2435,137 @@ static struct omap_hwmod omap44xx_mmc5_hwmod = {
> };
>
> /*
> + * 'mmu' class
> + * The memory management unit performs virtual to physical address translation
> + * for its requestors.
> + */
> +
> +static struct omap_hwmod_class_sysconfig mmu_sysc = {
> + .rev_offs = 0x000,
> + .sysc_offs = 0x010,
> + .syss_offs = 0x014,
> + .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
> + SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> + .sysc_fields = &omap_hwmod_sysc_type1,
> +};
> +
> +static struct omap_hwmod_class omap44xx_mmu_hwmod_class = {
> + .name = "mmu",
> + .sysc = &mmu_sysc,
> +};
> +
> +/* ipu mmu */
> +
> +static struct omap_mmu_dev_attr ipu_mmu_dev_attr = {
> + .da_start = 0x0,
> + .da_end = 0xfffff000,
> + .nr_tlb_entries = 32,
> +};
> +
> +static struct omap_hwmod omap44xx_ipu_mmu_hwmod;
> +static struct omap_hwmod_irq_info omap44xx_ipu_mmu_irqs[] = {
> + { .irq = 100 + OMAP44XX_IRQ_GIC_START, },
> + { .irq = -1 }
> +};
> +
> +static struct omap_hwmod_rst_info omap44xx_ipu_mmu_resets[] = {
> + { .name = "mmu_cache", .rst_shift = 2 },
> +};
> +
> +static struct omap_hwmod_addr_space omap44xx_ipu_mmu_addrs[] = {
> + {
> + .pa_start = 0x55082000,
> + .pa_end = 0x550820ff,
> + .flags = ADDR_TYPE_RT,
> + },
> + { }
> +};
> +
> +/* l3_main_2 -> ipu_mmu */
> +static struct omap_hwmod_ocp_if omap44xx_l3_main_2__ipu_mmu = {
> + .master = &omap44xx_l3_main_2_hwmod,
> + .slave = &omap44xx_ipu_mmu_hwmod,
> + .clk = "l3_div_ck",
> + .addr = omap44xx_ipu_mmu_addrs,
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
> + .name = "ipu_mmu",
> + .class = &omap44xx_mmu_hwmod_class,
> + .clkdm_name = "ducati_clkdm",
> + .mpu_irqs = omap44xx_ipu_mmu_irqs,
> + .rst_lines = omap44xx_ipu_mmu_resets,
> + .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
> + .main_clk = "ipu_fck",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
> + .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
> + .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_HWCTRL,
> + },
> + },
> + .dev_attr = &ipu_mmu_dev_attr,
> +};
In fact, the MMU_IPU hwmod is now almost the same one than the previous IPU one...
If we do that we should maybe just rename the IPU -> MMU_IPU and DSP -> MMU_DSP.
But by doing that we will assume that the MMU does represent the subsystem, which is not necessarily super nice.
I guess that a much better representation will be to keep the subsystem (IPU) to handle the PRCM part:
+ .main_clk = "ipu_fck",
+ .prcm = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
And then the MMU_IPU will handle the configuration registers part and the reset + irq.
But then, you will have to create a parent child dependency between your devices to ensure that the IPU subsystem device will be enabled before trying to access the MMU_IPU.
This is what the DSS is about to do to handle the same kind of power dependency. The DSS device is the parent of all the DSS IPs (DISPC, HDMI...) and thus pm_runtime will ensure that the parent is enabled before trying to enable the children.
In term of DT, just to illustrate the situation, it will be something like that:
ipu {
compatible = "simple-bus";
ti,hwmods = "ipu";
ipu_mmu: mmu at 4a066000 {
compatible = "omap-mmu";
ti,hwmods = "mmu_ipu";
reg...;
irqs...;
}
}
Is it something you can handle with your current framework?
Regards,
Benoit
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
2012-06-19 12:36 ` Cousson, Benoit
@ 2012-06-19 16:39 ` Omar Ramirez Luna
-1 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-06-19 16:39 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Tony Lindgren, Russell King, Ohad Ben-Cohen, Joerg Roedel,
Laurent Pinchart, Felipe Contreras, linux-omap, linux-arm-kernel,
iommu
Hi Benoit,
On 19 June 2012 07:36, Cousson, Benoit <b-cousson@ti.com> wrote:
> On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
...
>> +static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
>> + .name = "ipu_mmu",
>> + .class = &omap44xx_mmu_hwmod_class,
>> + .clkdm_name = "ducati_clkdm",
>> + .mpu_irqs = omap44xx_ipu_mmu_irqs,
>> + .rst_lines = omap44xx_ipu_mmu_resets,
>> + .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
>> + .main_clk = "ipu_fck",
>> + .prcm = {
>> + .omap4 = {
>> + .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
>> + .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
>> + .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
>> + .modulemode = MODULEMODE_HWCTRL,
>> + },
>> + },
>> + .dev_attr = &ipu_mmu_dev_attr,
>> +};
>
> In fact, the MMU_IPU hwmod is now almost the same one than the previous IPU one...
> If we do that we should maybe just rename the IPU -> MMU_IPU and DSP -> MMU_DSP.
>
> But by doing that we will assume that the MMU does represent the subsystem, which is not necessarily super nice.
>
> I guess that a much better representation will be to keep the subsystem (IPU) to handle the PRCM part:
>
> + .main_clk = "ipu_fck",
> + .prcm = {
> + .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
> + .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
> + .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_HWCTRL,
>
> And then the MMU_IPU will handle the configuration registers part and the reset + irq.
>
> But then, you will have to create a parent child dependency between your devices to ensure that the IPU subsystem device will be enabled before trying to access the MMU_IPU.
>
> This is what the DSS is about to do to handle the same kind of power dependency. The DSS device is the parent of all the DSS IPs (DISPC, HDMI...) and thus pm_runtime will ensure that the parent is enabled before trying to enable the children.
>
> In term of DT, just to illustrate the situation, it will be something like that:
>
> ipu {
> compatible = "simple-bus";
> ti,hwmods = "ipu";
>
> ipu_mmu: mmu@4a066000 {
> compatible = "omap-mmu";
> ti,hwmods = "mmu_ipu";
> reg...;
> irqs...;
> }
> }
>
> Is it something you can handle with your current framework?
I agree it would be nice only IPU managed the prcm, however we can't
do that right now because hwmod expects the IP block to be out of
reset to continue the _enable sequence. On IPU both reset lines are
asserted at that point and hence _are_any_hardreset_lines_asserted
check will bail out, and ipu resets can't be lifted without a
configured iommu otherwise it might execute random garbage.
So, for IPU and DSP the mmu must be deasserted and configured before
the processor reset line (which is more like a parking brake) is
deasserted, and the latter should be made before _enable is called so
it can fully execute the enable sequence.
Regards,
Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
@ 2012-06-19 16:39 ` Omar Ramirez Luna
0 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-06-19 16:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Benoit,
On 19 June 2012 07:36, Cousson, Benoit <b-cousson@ti.com> wrote:
> On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
...
>> +static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
>> + ? ? .name ? ? ? ? ? = "ipu_mmu",
>> + ? ? .class ? ? ? ? ?= &omap44xx_mmu_hwmod_class,
>> + ? ? .clkdm_name ? ? = "ducati_clkdm",
>> + ? ? .mpu_irqs ? ? ? = omap44xx_ipu_mmu_irqs,
>> + ? ? .rst_lines ? ? ?= omap44xx_ipu_mmu_resets,
>> + ? ? .rst_lines_cnt ?= ARRAY_SIZE(omap44xx_ipu_mmu_resets),
>> + ? ? .main_clk ? ? ? = "ipu_fck",
>> + ? ? .prcm = {
>> + ? ? ? ? ? ? .omap4 = {
>> + ? ? ? ? ? ? ? ? ? ? .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
>> + ? ? ? ? ? ? ? ? ? ? .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
>> + ? ? ? ? ? ? ? ? ? ? .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
>> + ? ? ? ? ? ? ? ? ? ? .modulemode ? = MODULEMODE_HWCTRL,
>> + ? ? ? ? ? ? },
>> + ? ? },
>> + ? ? .dev_attr ? ? ? = &ipu_mmu_dev_attr,
>> +};
>
> In fact, the MMU_IPU hwmod is now almost the same one than the previous IPU one...
> If we do that we should maybe just rename the IPU -> MMU_IPU and DSP -> MMU_DSP.
>
> But by doing that we will assume that the MMU does represent the subsystem, which is not necessarily super nice.
>
> I guess that a much better representation will be to keep the subsystem (IPU) to handle the PRCM part:
>
> + ? ? ? .main_clk ? ? ? = "ipu_fck",
> + ? ? ? .prcm = {
> + ? ? ? ? ? ? ? .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
> + ? ? ? ? ? ? ? .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
> + ? ? ? ? ? ? ? .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
> + ? ? ? ? ? ? ? .modulemode ? = MODULEMODE_HWCTRL,
>
> And then the MMU_IPU will handle the configuration registers part and the reset + irq.
>
> But then, you will have to create a parent child dependency between your devices to ensure that the IPU subsystem device will be enabled before trying to access the MMU_IPU.
>
> This is what the DSS is about to do to handle the same kind of power dependency. The DSS device is the parent of all the DSS IPs (DISPC, HDMI...) and thus pm_runtime will ensure that the parent is enabled before trying to enable the children.
>
> In term of DT, just to illustrate the situation, it will be something like that:
>
> ipu {
> ? ? ? ?compatible = "simple-bus";
> ? ? ? ?ti,hwmods = "ipu";
>
> ? ? ? ?ipu_mmu: mmu at 4a066000 {
> ? ? ? ? ? ? ? ?compatible = "omap-mmu";
> ? ? ? ? ? ? ? ?ti,hwmods = "mmu_ipu";
> ? ? ? ? ? ? ? ?reg...;
> ? ? ? ? ? ? ? ?irqs...;
> ? ? ? ?}
> }
>
> Is it something you can handle with your current framework?
I agree it would be nice only IPU managed the prcm, however we can't
do that right now because hwmod expects the IP block to be out of
reset to continue the _enable sequence. On IPU both reset lines are
asserted at that point and hence _are_any_hardreset_lines_asserted
check will bail out, and ipu resets can't be lifted without a
configured iommu otherwise it might execute random garbage.
So, for IPU and DSP the mmu must be deasserted and configured before
the processor reset line (which is more like a parking brake) is
deasserted, and the latter should be made before _enable is called so
it can fully execute the enable sequence.
Regards,
Omar
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
2012-06-19 16:39 ` Omar Ramirez Luna
@ 2012-06-19 17:48 ` Cousson, Benoit
-1 siblings, 0 replies; 30+ messages in thread
From: Cousson, Benoit @ 2012-06-19 17:48 UTC (permalink / raw)
To: Omar Ramirez Luna
Cc: Tony Lindgren, Russell King, Ohad Ben-Cohen, Joerg Roedel,
Laurent Pinchart, Felipe Contreras, linux-omap, linux-arm-kernel,
iommu
On 6/19/2012 6:39 PM, Omar Ramirez Luna wrote:
> Hi Benoit,
>
> On 19 June 2012 07:36, Cousson, Benoit <b-cousson@ti.com> wrote:
>> On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
> ...
>>> +static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
>>> + .name = "ipu_mmu",
>>> + .class = &omap44xx_mmu_hwmod_class,
>>> + .clkdm_name = "ducati_clkdm",
>>> + .mpu_irqs = omap44xx_ipu_mmu_irqs,
>>> + .rst_lines = omap44xx_ipu_mmu_resets,
>>> + .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
>>> + .main_clk = "ipu_fck",
>>> + .prcm = {
>>> + .omap4 = {
>>> + .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
>>> + .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
>>> + .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
>>> + .modulemode = MODULEMODE_HWCTRL,
>>> + },
>>> + },
>>> + .dev_attr = &ipu_mmu_dev_attr,
>>> +};
>>
>> In fact, the MMU_IPU hwmod is now almost the same one than the previous IPU one...
>> If we do that we should maybe just rename the IPU -> MMU_IPU and DSP -> MMU_DSP.
>>
>> But by doing that we will assume that the MMU does represent the subsystem, which is not necessarily super nice.
>>
>> I guess that a much better representation will be to keep the subsystem (IPU) to handle the PRCM part:
>>
>> + .main_clk = "ipu_fck",
>> + .prcm = {
>> + .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
>> + .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
>> + .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
>> + .modulemode = MODULEMODE_HWCTRL,
>>
>> And then the MMU_IPU will handle the configuration registers part and the reset + irq.
>>
>> But then, you will have to create a parent child dependency between your devices to ensure that the IPU subsystem device will be enabled before trying to access the MMU_IPU.
>>
>> This is what the DSS is about to do to handle the same kind of power dependency. The DSS device is the parent of all the DSS IPs (DISPC, HDMI...) and thus pm_runtime will ensure that the parent is enabled before trying to enable the children.
>>
>> In term of DT, just to illustrate the situation, it will be something like that:
>>
>> ipu {
>> compatible = "simple-bus";
>> ti,hwmods = "ipu";
>>
>> ipu_mmu: mmu@4a066000 {
>> compatible = "omap-mmu";
>> ti,hwmods = "mmu_ipu";
>> reg...;
>> irqs...;
>> }
>> }
>>
>> Is it something you can handle with your current framework?
>
> I agree it would be nice only IPU managed the prcm, however we can't
> do that right now because hwmod expects the IP block to be out of
> reset to continue the _enable sequence. On IPU both reset lines are
> asserted at that point and hence _are_any_hardreset_lines_asserted
> check will bail out, and ipu resets can't be lifted without a
> configured iommu otherwise it might execute random garbage.
That's a good point, but like Paul said, the hard reset was removed
outside of the fmwk due to the lack of understanding about the real
usage / need for it.
If we do have a better understanding, we might add some more support in
the fmwk or at least improve it.
I'm now realizing that aborting the init if some reset lines are
asserted is not what we want to do for the IPU SS hwmod that will
contain the IPU (processor) reset control.
In fact the previous approach with a fake hwmod for the ipu_c0 processor
would have been avoided that issue.
If we do not want to go back with that, we should clearly revise the
_are_any_hardreset_lines_asserted approach and not prevent the init in
such case since it will prevent all the subsystem to start properly.
> So, for IPU and DSP the mmu must be deasserted and configured before
> the processor reset line (which is more like a parking brake) is
> deasserted, and the latter should be made before _enable is called so
> it can fully execute the enable sequence.
Yep, so we have to change the way it is handled today.
Paul,
If we consider that the reset lines are stored in the subsystem hwmod
(IPU, DSP or IVA), we cannot prevent the init phase because some line
are asserted. Otherwise we will never allow the MMU or processor to be
enabled later.
We might have to remove that check, maybe based on flag if we want to
keep that functionality or do an explicit reset control like we use to do.
What do you think?
Regards,
Benoit
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
@ 2012-06-19 17:48 ` Cousson, Benoit
0 siblings, 0 replies; 30+ messages in thread
From: Cousson, Benoit @ 2012-06-19 17:48 UTC (permalink / raw)
To: linux-arm-kernel
On 6/19/2012 6:39 PM, Omar Ramirez Luna wrote:
> Hi Benoit,
>
> On 19 June 2012 07:36, Cousson, Benoit <b-cousson@ti.com> wrote:
>> On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
> ...
>>> +static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
>>> + .name = "ipu_mmu",
>>> + .class = &omap44xx_mmu_hwmod_class,
>>> + .clkdm_name = "ducati_clkdm",
>>> + .mpu_irqs = omap44xx_ipu_mmu_irqs,
>>> + .rst_lines = omap44xx_ipu_mmu_resets,
>>> + .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
>>> + .main_clk = "ipu_fck",
>>> + .prcm = {
>>> + .omap4 = {
>>> + .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
>>> + .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
>>> + .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
>>> + .modulemode = MODULEMODE_HWCTRL,
>>> + },
>>> + },
>>> + .dev_attr = &ipu_mmu_dev_attr,
>>> +};
>>
>> In fact, the MMU_IPU hwmod is now almost the same one than the previous IPU one...
>> If we do that we should maybe just rename the IPU -> MMU_IPU and DSP -> MMU_DSP.
>>
>> But by doing that we will assume that the MMU does represent the subsystem, which is not necessarily super nice.
>>
>> I guess that a much better representation will be to keep the subsystem (IPU) to handle the PRCM part:
>>
>> + .main_clk = "ipu_fck",
>> + .prcm = {
>> + .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
>> + .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
>> + .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
>> + .modulemode = MODULEMODE_HWCTRL,
>>
>> And then the MMU_IPU will handle the configuration registers part and the reset + irq.
>>
>> But then, you will have to create a parent child dependency between your devices to ensure that the IPU subsystem device will be enabled before trying to access the MMU_IPU.
>>
>> This is what the DSS is about to do to handle the same kind of power dependency. The DSS device is the parent of all the DSS IPs (DISPC, HDMI...) and thus pm_runtime will ensure that the parent is enabled before trying to enable the children.
>>
>> In term of DT, just to illustrate the situation, it will be something like that:
>>
>> ipu {
>> compatible = "simple-bus";
>> ti,hwmods = "ipu";
>>
>> ipu_mmu: mmu at 4a066000 {
>> compatible = "omap-mmu";
>> ti,hwmods = "mmu_ipu";
>> reg...;
>> irqs...;
>> }
>> }
>>
>> Is it something you can handle with your current framework?
>
> I agree it would be nice only IPU managed the prcm, however we can't
> do that right now because hwmod expects the IP block to be out of
> reset to continue the _enable sequence. On IPU both reset lines are
> asserted at that point and hence _are_any_hardreset_lines_asserted
> check will bail out, and ipu resets can't be lifted without a
> configured iommu otherwise it might execute random garbage.
That's a good point, but like Paul said, the hard reset was removed
outside of the fmwk due to the lack of understanding about the real
usage / need for it.
If we do have a better understanding, we might add some more support in
the fmwk or at least improve it.
I'm now realizing that aborting the init if some reset lines are
asserted is not what we want to do for the IPU SS hwmod that will
contain the IPU (processor) reset control.
In fact the previous approach with a fake hwmod for the ipu_c0 processor
would have been avoided that issue.
If we do not want to go back with that, we should clearly revise the
_are_any_hardreset_lines_asserted approach and not prevent the init in
such case since it will prevent all the subsystem to start properly.
> So, for IPU and DSP the mmu must be deasserted and configured before
> the processor reset line (which is more like a parking brake) is
> deasserted, and the latter should be made before _enable is called so
> it can fully execute the enable sequence.
Yep, so we have to change the way it is handled today.
Paul,
If we consider that the reset lines are stored in the subsystem hwmod
(IPU, DSP or IVA), we cannot prevent the init phase because some line
are asserted. Otherwise we will never allow the MMU or processor to be
enabled later.
We might have to remove that check, maybe based on flag if we want to
keep that functionality or do an explicit reset control like we use to do.
What do you think?
Regards,
Benoit
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
2012-06-19 17:48 ` Cousson, Benoit
@ 2012-06-28 1:27 ` Omar Ramirez Luna
-1 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-06-28 1:27 UTC (permalink / raw)
To: Cousson, Benoit, Paul Walmsley
Cc: Tony Lindgren, Russell King, Ohad Ben-Cohen, Joerg Roedel,
Laurent Pinchart, Felipe Contreras, linux-omap, linux-arm-kernel,
iommu
+ Paul
On 19 June 2012 12:48, Cousson, Benoit <b-cousson@ti.com> wrote:
> On 6/19/2012 6:39 PM, Omar Ramirez Luna wrote:
>>
>> Hi Benoit,
>>
>> On 19 June 2012 07:36, Cousson, Benoit <b-cousson@ti.com> wrote:
>>>
>>> On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
>>
>> ...
>>>>
>>>> +static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
>>>> + .name = "ipu_mmu",
>>>> + .class = &omap44xx_mmu_hwmod_class,
>>>> + .clkdm_name = "ducati_clkdm",
>>>> + .mpu_irqs = omap44xx_ipu_mmu_irqs,
>>>> + .rst_lines = omap44xx_ipu_mmu_resets,
>>>> + .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
>>>> + .main_clk = "ipu_fck",
>>>> + .prcm = {
>>>> + .omap4 = {
>>>> + .clkctrl_offs =
>>>> OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
>>>> + .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
>>>> + .context_offs =
>>>> OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
>>>> + .modulemode = MODULEMODE_HWCTRL,
>>>> + },
>>>> + },
>>>> + .dev_attr = &ipu_mmu_dev_attr,
>>>> +};
>>>
>>>
>>> In fact, the MMU_IPU hwmod is now almost the same one than the previous
>>> IPU one...
>>> If we do that we should maybe just rename the IPU -> MMU_IPU and DSP ->
>>> MMU_DSP.
>>>
>>> But by doing that we will assume that the MMU does represent the
>>> subsystem, which is not necessarily super nice.
>>>
>>> I guess that a much better representation will be to keep the subsystem
>>> (IPU) to handle the PRCM part:
>>>
>>> + .main_clk = "ipu_fck",
>>> + .prcm = {
>>> + .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
>>> + .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
>>> + .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
>>> + .modulemode = MODULEMODE_HWCTRL,
>>>
>>> And then the MMU_IPU will handle the configuration registers part and the
>>> reset + irq.
>>>
>>> But then, you will have to create a parent child dependency between your
>>> devices to ensure that the IPU subsystem device will be enabled before
>>> trying to access the MMU_IPU.
>>>
>>> This is what the DSS is about to do to handle the same kind of power
>>> dependency. The DSS device is the parent of all the DSS IPs (DISPC, HDMI...)
>>> and thus pm_runtime will ensure that the parent is enabled before trying to
>>> enable the children.
>>>
>>> In term of DT, just to illustrate the situation, it will be something
>>> like that:
>>>
>>> ipu {
>>> compatible = "simple-bus";
>>> ti,hwmods = "ipu";
>>>
>>> ipu_mmu: mmu@4a066000 {
>>> compatible = "omap-mmu";
>>> ti,hwmods = "mmu_ipu";
>>> reg...;
>>> irqs...;
>>> }
>>> }
>>>
>>> Is it something you can handle with your current framework?
>>
>>
>> I agree it would be nice only IPU managed the prcm, however we can't
>> do that right now because hwmod expects the IP block to be out of
>> reset to continue the _enable sequence. On IPU both reset lines are
>> asserted at that point and hence _are_any_hardreset_lines_asserted
>> check will bail out, and ipu resets can't be lifted without a
>> configured iommu otherwise it might execute random garbage.
>
>
> That's a good point, but like Paul said, the hard reset was removed outside
> of the fmwk due to the lack of understanding about the real usage / need for
> it.
>
> If we do have a better understanding, we might add some more support in the
> fmwk or at least improve it.
>
> I'm now realizing that aborting the init if some reset lines are asserted is
> not what we want to do for the IPU SS hwmod that will contain the IPU
> (processor) reset control.
> In fact the previous approach with a fake hwmod for the ipu_c0 processor
> would have been avoided that issue.
>
> If we do not want to go back with that, we should clearly revise the
> _are_any_hardreset_lines_asserted approach and not prevent the init in such
> case since it will prevent all the subsystem to start properly.
>
>
>> So, for IPU and DSP the mmu must be deasserted and configured before
>> the processor reset line (which is more like a parking brake) is
>> deasserted, and the latter should be made before _enable is called so
>> it can fully execute the enable sequence.
>
>
> Yep, so we have to change the way it is handled today.
>
>
> Paul,
>
> If we consider that the reset lines are stored in the subsystem hwmod (IPU,
> DSP or IVA), we cannot prevent the init phase because some line are
> asserted. Otherwise we will never allow the MMU or processor to be enabled
> later.
> We might have to remove that check, maybe based on flag if we want to keep
> that functionality or do an explicit reset control like we use to do.
>
> What do you think?
I was waiting for some comments then I realized Paul wasn't actually
in the list of recipients for this email.
Regards,
Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
@ 2012-06-28 1:27 ` Omar Ramirez Luna
0 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-06-28 1:27 UTC (permalink / raw)
To: linux-arm-kernel
+ Paul
On 19 June 2012 12:48, Cousson, Benoit <b-cousson@ti.com> wrote:
> On 6/19/2012 6:39 PM, Omar Ramirez Luna wrote:
>>
>> Hi Benoit,
>>
>> On 19 June 2012 07:36, Cousson, Benoit <b-cousson@ti.com> wrote:
>>>
>>> On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
>>
>> ...
>>>>
>>>> +static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
>>>> + ? ? .name ? ? ? ? ? = "ipu_mmu",
>>>> + ? ? .class ? ? ? ? ?= &omap44xx_mmu_hwmod_class,
>>>> + ? ? .clkdm_name ? ? = "ducati_clkdm",
>>>> + ? ? .mpu_irqs ? ? ? = omap44xx_ipu_mmu_irqs,
>>>> + ? ? .rst_lines ? ? ?= omap44xx_ipu_mmu_resets,
>>>> + ? ? .rst_lines_cnt ?= ARRAY_SIZE(omap44xx_ipu_mmu_resets),
>>>> + ? ? .main_clk ? ? ? = "ipu_fck",
>>>> + ? ? .prcm = {
>>>> + ? ? ? ? ? ? .omap4 = {
>>>> + ? ? ? ? ? ? ? ? ? ? .clkctrl_offs =
>>>> OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
>>>> + ? ? ? ? ? ? ? ? ? ? .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
>>>> + ? ? ? ? ? ? ? ? ? ? .context_offs =
>>>> OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
>>>> + ? ? ? ? ? ? ? ? ? ? .modulemode ? = MODULEMODE_HWCTRL,
>>>> + ? ? ? ? ? ? },
>>>> + ? ? },
>>>> + ? ? .dev_attr ? ? ? = &ipu_mmu_dev_attr,
>>>> +};
>>>
>>>
>>> In fact, the MMU_IPU hwmod is now almost the same one than the previous
>>> IPU one...
>>> If we do that we should maybe just rename the IPU -> MMU_IPU and DSP ->
>>> MMU_DSP.
>>>
>>> But by doing that we will assume that the MMU does represent the
>>> subsystem, which is not necessarily super nice.
>>>
>>> I guess that a much better representation will be to keep the subsystem
>>> (IPU) to handle the PRCM part:
>>>
>>> + ? ? ? .main_clk ? ? ? = "ipu_fck",
>>> + ? ? ? .prcm = {
>>> + ? ? ? ? ? ? ? .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
>>> + ? ? ? ? ? ? ? .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
>>> + ? ? ? ? ? ? ? .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
>>> + ? ? ? ? ? ? ? .modulemode ? = MODULEMODE_HWCTRL,
>>>
>>> And then the MMU_IPU will handle the configuration registers part and the
>>> reset + irq.
>>>
>>> But then, you will have to create a parent child dependency between your
>>> devices to ensure that the IPU subsystem device will be enabled before
>>> trying to access the MMU_IPU.
>>>
>>> This is what the DSS is about to do to handle the same kind of power
>>> dependency. The DSS device is the parent of all the DSS IPs (DISPC, HDMI...)
>>> and thus pm_runtime will ensure that the parent is enabled before trying to
>>> enable the children.
>>>
>>> In term of DT, just to illustrate the situation, it will be something
>>> like that:
>>>
>>> ipu {
>>> ? ? ? ?compatible = "simple-bus";
>>> ? ? ? ?ti,hwmods = "ipu";
>>>
>>> ? ? ? ?ipu_mmu: mmu at 4a066000 {
>>> ? ? ? ? ? ? ? ?compatible = "omap-mmu";
>>> ? ? ? ? ? ? ? ?ti,hwmods = "mmu_ipu";
>>> ? ? ? ? ? ? ? ?reg...;
>>> ? ? ? ? ? ? ? ?irqs...;
>>> ? ? ? ?}
>>> }
>>>
>>> Is it something you can handle with your current framework?
>>
>>
>> I agree it would be nice only IPU managed the prcm, however we can't
>> do that right now because hwmod expects the IP block to be out of
>> reset to continue the _enable sequence. On IPU both reset lines are
>> asserted at that point and hence _are_any_hardreset_lines_asserted
>> check will bail out, and ipu resets can't be lifted without a
>> configured iommu otherwise it might execute random garbage.
>
>
> That's a good point, but like Paul said, the hard reset was removed outside
> of the fmwk due to the lack of understanding about the real usage / need for
> it.
>
> If we do have a better understanding, we might add some more support in the
> fmwk or at least improve it.
>
> I'm now realizing that aborting the init if some reset lines are asserted is
> not what we want to do for the IPU SS hwmod that will contain the IPU
> (processor) reset control.
> In fact the previous approach with a fake hwmod for the ipu_c0 processor
> would have been avoided that issue.
>
> If we do not want to go back with that, we should clearly revise the
> _are_any_hardreset_lines_asserted approach and not prevent the init in such
> case since it will prevent all the subsystem to start properly.
>
>
>> So, for IPU and DSP the mmu must be deasserted and configured before
>> the processor reset line (which is more like a parking brake) is
>> deasserted, and the latter should be made before _enable is called so
>> it can fully execute the enable sequence.
>
>
> Yep, so we have to change the way it is handled today.
>
>
> Paul,
>
> If we consider that the reset lines are stored in the subsystem hwmod (IPU,
> DSP or IVA), we cannot prevent the init phase because some line are
> asserted. Otherwise we will never allow the MMU or processor to be enabled
> later.
> We might have to remove that check, maybe based on flag if we want to keep
> that functionality or do an explicit reset control like we use to do.
>
> What do you think?
I was waiting for some comments then I realized Paul wasn't actually
in the list of recipients for this email.
Regards,
Omar
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
2012-06-28 1:27 ` Omar Ramirez Luna
@ 2012-07-09 13:50 ` Omar Ramirez Luna
-1 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-07-09 13:50 UTC (permalink / raw)
To: Paul Walmsley, Cousson, Benoit
Cc: Tony Lindgren, Russell King, Ohad Ben-Cohen, Joerg Roedel,
Laurent Pinchart, Felipe Contreras, linux-omap, linux-arm-kernel,
iommu
Hi Paul,
On 27 June 2012 20:27, Omar Ramirez Luna <omar.luna@linaro.org> wrote:
> On 19 June 2012 12:48, Cousson, Benoit <b-cousson@ti.com> wrote:
>> On 6/19/2012 6:39 PM, Omar Ramirez Luna wrote:
>>>
>>> Hi Benoit,
>>>
>>> On 19 June 2012 07:36, Cousson, Benoit <b-cousson@ti.com> wrote:
>>>>
>>>> On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
>>>
>>> ...
>>>>>
>>>>> +static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
>>>>> + .name = "ipu_mmu",
>>>>> + .class = &omap44xx_mmu_hwmod_class,
>>>>> + .clkdm_name = "ducati_clkdm",
>>>>> + .mpu_irqs = omap44xx_ipu_mmu_irqs,
>>>>> + .rst_lines = omap44xx_ipu_mmu_resets,
>>>>> + .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
>>>>> + .main_clk = "ipu_fck",
>>>>> + .prcm = {
>>>>> + .omap4 = {
>>>>> + .clkctrl_offs =
>>>>> OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
>>>>> + .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
>>>>> + .context_offs =
>>>>> OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
>>>>> + .modulemode = MODULEMODE_HWCTRL,
>>>>> + },
>>>>> + },
>>>>> + .dev_attr = &ipu_mmu_dev_attr,
>>>>> +};
>>>>
>>>>
>>>> In fact, the MMU_IPU hwmod is now almost the same one than the previous
>>>> IPU one...
>>>> If we do that we should maybe just rename the IPU -> MMU_IPU and DSP ->
>>>> MMU_DSP.
>>>>
>>>> But by doing that we will assume that the MMU does represent the
>>>> subsystem, which is not necessarily super nice.
>>>>
>>>> I guess that a much better representation will be to keep the subsystem
>>>> (IPU) to handle the PRCM part:
>>>>
>>>> + .main_clk = "ipu_fck",
>>>> + .prcm = {
>>>> + .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
>>>> + .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
>>>> + .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
>>>> + .modulemode = MODULEMODE_HWCTRL,
>>>>
>>>> And then the MMU_IPU will handle the configuration registers part and the
>>>> reset + irq.
>>>>
>>>> But then, you will have to create a parent child dependency between your
>>>> devices to ensure that the IPU subsystem device will be enabled before
>>>> trying to access the MMU_IPU.
>>>>
>>>> This is what the DSS is about to do to handle the same kind of power
>>>> dependency. The DSS device is the parent of all the DSS IPs (DISPC, HDMI...)
>>>> and thus pm_runtime will ensure that the parent is enabled before trying to
>>>> enable the children.
>>>>
>>>> In term of DT, just to illustrate the situation, it will be something
>>>> like that:
>>>>
>>>> ipu {
>>>> compatible = "simple-bus";
>>>> ti,hwmods = "ipu";
>>>>
>>>> ipu_mmu: mmu@4a066000 {
>>>> compatible = "omap-mmu";
>>>> ti,hwmods = "mmu_ipu";
>>>> reg...;
>>>> irqs...;
>>>> }
>>>> }
>>>>
>>>> Is it something you can handle with your current framework?
>>>
>>>
>>> I agree it would be nice only IPU managed the prcm, however we can't
>>> do that right now because hwmod expects the IP block to be out of
>>> reset to continue the _enable sequence. On IPU both reset lines are
>>> asserted at that point and hence _are_any_hardreset_lines_asserted
>>> check will bail out, and ipu resets can't be lifted without a
>>> configured iommu otherwise it might execute random garbage.
>>
>>
>> That's a good point, but like Paul said, the hard reset was removed outside
>> of the fmwk due to the lack of understanding about the real usage / need for
>> it.
>>
>> If we do have a better understanding, we might add some more support in the
>> fmwk or at least improve it.
>>
>> I'm now realizing that aborting the init if some reset lines are asserted is
>> not what we want to do for the IPU SS hwmod that will contain the IPU
>> (processor) reset control.
>> In fact the previous approach with a fake hwmod for the ipu_c0 processor
>> would have been avoided that issue.
>>
>> If we do not want to go back with that, we should clearly revise the
>> _are_any_hardreset_lines_asserted approach and not prevent the init in such
>> case since it will prevent all the subsystem to start properly.
>>
>>
>>> So, for IPU and DSP the mmu must be deasserted and configured before
>>> the processor reset line (which is more like a parking brake) is
>>> deasserted, and the latter should be made before _enable is called so
>>> it can fully execute the enable sequence.
>>
>>
>> Yep, so we have to change the way it is handled today.
>>
>>
>> Paul,
>>
>> If we consider that the reset lines are stored in the subsystem hwmod (IPU,
>> DSP or IVA), we cannot prevent the init phase because some line are
>> asserted. Otherwise we will never allow the MMU or processor to be enabled
>> later.
>> We might have to remove that check, maybe based on flag if we want to keep
>> that functionality or do an explicit reset control like we use to do.
>>
>> What do you think?
>
> I was waiting for some comments then I realized Paul wasn't actually
> in the list of recipients for this email.
Any chance you had time to check on this? While at it, could you please check:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70443.html
Thanks,
Omar
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
@ 2012-07-09 13:50 ` Omar Ramirez Luna
0 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-07-09 13:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi Paul,
On 27 June 2012 20:27, Omar Ramirez Luna <omar.luna@linaro.org> wrote:
> On 19 June 2012 12:48, Cousson, Benoit <b-cousson@ti.com> wrote:
>> On 6/19/2012 6:39 PM, Omar Ramirez Luna wrote:
>>>
>>> Hi Benoit,
>>>
>>> On 19 June 2012 07:36, Cousson, Benoit <b-cousson@ti.com> wrote:
>>>>
>>>> On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
>>>
>>> ...
>>>>>
>>>>> +static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
>>>>> + .name = "ipu_mmu",
>>>>> + .class = &omap44xx_mmu_hwmod_class,
>>>>> + .clkdm_name = "ducati_clkdm",
>>>>> + .mpu_irqs = omap44xx_ipu_mmu_irqs,
>>>>> + .rst_lines = omap44xx_ipu_mmu_resets,
>>>>> + .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
>>>>> + .main_clk = "ipu_fck",
>>>>> + .prcm = {
>>>>> + .omap4 = {
>>>>> + .clkctrl_offs =
>>>>> OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
>>>>> + .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
>>>>> + .context_offs =
>>>>> OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
>>>>> + .modulemode = MODULEMODE_HWCTRL,
>>>>> + },
>>>>> + },
>>>>> + .dev_attr = &ipu_mmu_dev_attr,
>>>>> +};
>>>>
>>>>
>>>> In fact, the MMU_IPU hwmod is now almost the same one than the previous
>>>> IPU one...
>>>> If we do that we should maybe just rename the IPU -> MMU_IPU and DSP ->
>>>> MMU_DSP.
>>>>
>>>> But by doing that we will assume that the MMU does represent the
>>>> subsystem, which is not necessarily super nice.
>>>>
>>>> I guess that a much better representation will be to keep the subsystem
>>>> (IPU) to handle the PRCM part:
>>>>
>>>> + .main_clk = "ipu_fck",
>>>> + .prcm = {
>>>> + .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
>>>> + .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
>>>> + .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
>>>> + .modulemode = MODULEMODE_HWCTRL,
>>>>
>>>> And then the MMU_IPU will handle the configuration registers part and the
>>>> reset + irq.
>>>>
>>>> But then, you will have to create a parent child dependency between your
>>>> devices to ensure that the IPU subsystem device will be enabled before
>>>> trying to access the MMU_IPU.
>>>>
>>>> This is what the DSS is about to do to handle the same kind of power
>>>> dependency. The DSS device is the parent of all the DSS IPs (DISPC, HDMI...)
>>>> and thus pm_runtime will ensure that the parent is enabled before trying to
>>>> enable the children.
>>>>
>>>> In term of DT, just to illustrate the situation, it will be something
>>>> like that:
>>>>
>>>> ipu {
>>>> compatible = "simple-bus";
>>>> ti,hwmods = "ipu";
>>>>
>>>> ipu_mmu: mmu at 4a066000 {
>>>> compatible = "omap-mmu";
>>>> ti,hwmods = "mmu_ipu";
>>>> reg...;
>>>> irqs...;
>>>> }
>>>> }
>>>>
>>>> Is it something you can handle with your current framework?
>>>
>>>
>>> I agree it would be nice only IPU managed the prcm, however we can't
>>> do that right now because hwmod expects the IP block to be out of
>>> reset to continue the _enable sequence. On IPU both reset lines are
>>> asserted at that point and hence _are_any_hardreset_lines_asserted
>>> check will bail out, and ipu resets can't be lifted without a
>>> configured iommu otherwise it might execute random garbage.
>>
>>
>> That's a good point, but like Paul said, the hard reset was removed outside
>> of the fmwk due to the lack of understanding about the real usage / need for
>> it.
>>
>> If we do have a better understanding, we might add some more support in the
>> fmwk or at least improve it.
>>
>> I'm now realizing that aborting the init if some reset lines are asserted is
>> not what we want to do for the IPU SS hwmod that will contain the IPU
>> (processor) reset control.
>> In fact the previous approach with a fake hwmod for the ipu_c0 processor
>> would have been avoided that issue.
>>
>> If we do not want to go back with that, we should clearly revise the
>> _are_any_hardreset_lines_asserted approach and not prevent the init in such
>> case since it will prevent all the subsystem to start properly.
>>
>>
>>> So, for IPU and DSP the mmu must be deasserted and configured before
>>> the processor reset line (which is more like a parking brake) is
>>> deasserted, and the latter should be made before _enable is called so
>>> it can fully execute the enable sequence.
>>
>>
>> Yep, so we have to change the way it is handled today.
>>
>>
>> Paul,
>>
>> If we consider that the reset lines are stored in the subsystem hwmod (IPU,
>> DSP or IVA), we cannot prevent the init phase because some line are
>> asserted. Otherwise we will never allow the MMU or processor to be enabled
>> later.
>> We might have to remove that check, maybe based on flag if we want to keep
>> that functionality or do an explicit reset control like we use to do.
>>
>> What do you think?
>
> I was waiting for some comments then I realized Paul wasn't actually
> in the list of recipients for this email.
Any chance you had time to check on this? While at it, could you please check:
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg70443.html
Thanks,
Omar
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 4/6] ARM: OMAP3/4: iommu: migrate to hwmod framework
2012-06-16 1:55 ` Omar Ramirez Luna
@ 2012-06-16 1:56 ` Omar Ramirez Luna
-1 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-06-16 1:56 UTC (permalink / raw)
To: Tony Lindgren, Benoit Cousson
Cc: Ohad Ben-Cohen, Russell King,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Laurent Pinchart, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Use hwmod data and device attributes to build and register an
omap device for iommu driver.
- Update the naming convention in isp module.
- Remove unneeded check for number of resources, as this is now
handled by omap_device and prevents driver from loading.
- Now unused, remove platform device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
Signed-off-by: Omar Ramirez Luna <omar.luna-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/iommu2.c | 19 ----
arch/arm/mach-omap2/omap-iommu.c | 159 ++++++-------------------------
arch/arm/plat-omap/include/plat/iommu.h | 2 +-
drivers/iommu/omap-iommu.c | 3 -
5 files changed, 33 insertions(+), 152 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2a4fc0d..5b66efa 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -216,7 +216,7 @@ static struct platform_device omap3isp_device = {
};
static struct omap_iommu_arch_data omap3_isp_iommu = {
- .name = "isp",
+ .name = "isp_mmu",
};
struct isp_platform_data {
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..35cab47 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -32,12 +32,8 @@
#define MMU_SYS_IDLE_SMART (2 << MMU_SYS_IDLE_SHIFT)
#define MMU_SYS_IDLE_MASK (3 << MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_SOFTRESET (1 << 1)
#define MMU_SYS_AUTOIDLE 1
-/* SYSSTATUS */
-#define MMU_SYS_RESETDONE 1
-
/* IRQSTATUS & IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 << 4)
#define MMU_IRQ_TABLEWALKFAULT (1 << 3)
@@ -88,7 +84,6 @@ static void __iommu_set_twl(struct omap_iommu *obj, bool on)
static int omap2_iommu_enable(struct omap_iommu *obj)
{
u32 l, pa;
- unsigned long timeout;
if (!obj->iopgd || !IS_ALIGNED((u32)obj->iopgd, SZ_16K))
return -EINVAL;
@@ -97,20 +92,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
if (!IS_ALIGNED(pa, SZ_16K))
return -EINVAL;
- iommu_write_reg(obj, MMU_SYS_SOFTRESET, MMU_SYSCONFIG);
-
- timeout = jiffies + msecs_to_jiffies(20);
- do {
- l = iommu_read_reg(obj, MMU_SYSSTATUS);
- if (l & MMU_SYS_RESETDONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (!(l & MMU_SYS_RESETDONE)) {
- dev_err(obj->dev, "can't take mmu out of reset\n");
- return -ENODEV;
- }
-
l = iommu_read_reg(obj, MMU_REVISION);
dev_info(obj->dev, "%s: version %d.%d\n", obj->name,
(l >> 4) & 0xf, l & 0xf);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index ac49384..02d98ce 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,56 @@
#include <linux/module.h>
#include <linux/platform_device.h>
+#include <linux/err.h>
+#include <linux/slab.h>
#include <plat/iommu.h>
#include <plat/irqs.h>
+#include <plat/omap_hwmod.h>
+#include <plat/omap_device.h>
-struct iommu_device {
- resource_size_t base;
- int irq;
- struct iommu_platform_data pdata;
- struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
- {
- .base = 0x480bd400,
- .irq = 24,
- .pdata = {
- .name = "isp",
- .nr_tlb_entries = 8,
- .clk_name = "cam_ick",
- .da_start = 0x0,
- .da_end = 0xFFFFF000,
- },
- },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
- {
- .base = 0x5d000000,
- .irq = 28,
- .pdata = {
- .name = "iva2",
- .nr_tlb_entries = 32,
- .clk_name = "iva2_ck",
- .da_start = 0x11000000,
- .da_end = 0xFFFFF000,
- },
- },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
- {
- .base = OMAP4_MMU1_BASE,
- .irq = OMAP44XX_IRQ_DUCATI_MMU,
- .pdata = {
- .name = "ducati",
- .nr_tlb_entries = 32,
- .clk_name = "ipu_fck",
- .da_start = 0x0,
- .da_end = 0xFFFFF000,
- },
- },
-#if defined(CONFIG_MPU_TESLA_IOMMU)
- {
- .base = OMAP4_MMU2_BASE,
- .irq = INT_44XX_DSP_MMU,
- .pdata = {
- .name = "tesla",
- .nr_tlb_entries = 32,
- .clk_name = "tesla_ick",
- .da_start = 0x0,
- .da_end = 0xFFFFF000,
- },
- },
-#endif
-};
-#define NR_OMAP4_IOMMU_DEVICES ARRAY_SIZE(omap4_devices)
-static struct platform_device *omap4_iommu_pdev[NR_OMAP4_IOMMU_DEVICES];
-#else
-#define omap4_devices NULL
-#define NR_OMAP4_IOMMU_DEVICES 0
-#define omap4_iommu_pdev NULL
-#endif
-
-static struct platform_device **omap_iommu_pdev;
-
-static int __init omap_iommu_init(void)
+static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
{
- int i, err;
- struct resource res[] = {
- { .flags = IORESOURCE_MEM },
- { .flags = IORESOURCE_IRQ },
- };
+ struct platform_device *pdev;
+ struct iommu_platform_data *pdata;
+ struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh->dev_attr;
+ static int i;
- if (cpu_is_omap34xx()) {
- devices = omap3_devices;
- omap_iommu_pdev = omap3_iommu_pdev;
- num_iommu_devices = NR_OMAP3_IOMMU_DEVICES;
- } else if (cpu_is_omap44xx()) {
- devices = omap4_devices;
- omap_iommu_pdev = omap4_iommu_pdev;
- num_iommu_devices = NR_OMAP4_IOMMU_DEVICES;
- } else
- return -ENODEV;
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
- for (i = 0; i < num_iommu_devices; i++) {
- struct platform_device *pdev;
- const struct iommu_device *d = &devices[i];
+ pdata->name = oh->name;
+ pdata->clk_name = oh->main_clk;
+ pdata->nr_tlb_entries = a->nr_tlb_entries;
+ pdata->da_start = a->da_start;
+ pdata->da_end = a->da_end;
- pdev = platform_device_alloc("omap-iommu", i);
- if (!pdev) {
- err = -ENOMEM;
- goto err_out;
- }
+ pdev = omap_device_build("omap-iommu", i, oh, pdata, sizeof(*pdata),
+ NULL, 0, 0);
- res[0].start = d->base;
- res[0].end = d->base + MMU_REG_SIZE - 1;
- res[1].start = res[1].end = d->irq;
+ kfree(pdata);
- err = platform_device_add_resources(pdev, res,
- ARRAY_SIZE(res));
- if (err)
- goto err_out;
- err = platform_device_add_data(pdev, &d->pdata,
- sizeof(d->pdata));
- if (err)
- goto err_out;
- err = platform_device_add(pdev);
- if (err)
- goto err_out;
- omap_iommu_pdev[i] = pdev;
+ if (IS_ERR(pdev)) {
+ pr_err("%s: device build err: %ld\n", __func__, PTR_ERR(pdev));
+ return PTR_ERR(pdev);
}
+
+ i++;
+
return 0;
+}
-err_out:
- while (i--)
- platform_device_put(omap_iommu_pdev[i]);
- return err;
+static int __init omap_iommu_init(void)
+{
+ return omap_hwmod_for_each_by_class("mmu", omap_iommu_dev_init, NULL);
}
/* must be ready before omap3isp is probed */
subsys_initcall(omap_iommu_init);
static void __exit omap_iommu_exit(void)
{
- int i;
-
- for (i = 0; i < num_iommu_devices; i++)
- platform_device_unregister(omap_iommu_pdev[i]);
+ /* Do nothing */
}
module_exit(omap_iommu_exit);
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index 44518cc..ed56424 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -119,7 +119,7 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
const char *clk_name;
- const int nr_tlb_entries;
+ int nr_tlb_entries;
u32 da_start;
u32 da_end;
};
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 9bdbf2f..93d7d84 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -906,9 +906,6 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev)
struct resource *res;
struct iommu_platform_data *pdata = pdev->dev.platform_data;
- if (pdev->num_resources != 2)
- return -EINVAL;
-
obj = kzalloc(sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
if (!obj)
return -ENOMEM;
--
1.7.4.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 4/6] ARM: OMAP3/4: iommu: migrate to hwmod framework
@ 2012-06-16 1:56 ` Omar Ramirez Luna
0 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-06-16 1:56 UTC (permalink / raw)
To: linux-arm-kernel
Use hwmod data and device attributes to build and register an
omap device for iommu driver.
- Update the naming convention in isp module.
- Remove unneeded check for number of resources, as this is now
handled by omap_device and prevents driver from loading.
- Now unused, remove platform device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
---
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/iommu2.c | 19 ----
arch/arm/mach-omap2/omap-iommu.c | 159 ++++++-------------------------
arch/arm/plat-omap/include/plat/iommu.h | 2 +-
drivers/iommu/omap-iommu.c | 3 -
5 files changed, 33 insertions(+), 152 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2a4fc0d..5b66efa 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -216,7 +216,7 @@ static struct platform_device omap3isp_device = {
};
static struct omap_iommu_arch_data omap3_isp_iommu = {
- .name = "isp",
+ .name = "isp_mmu",
};
struct isp_platform_data {
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..35cab47 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -32,12 +32,8 @@
#define MMU_SYS_IDLE_SMART (2 << MMU_SYS_IDLE_SHIFT)
#define MMU_SYS_IDLE_MASK (3 << MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_SOFTRESET (1 << 1)
#define MMU_SYS_AUTOIDLE 1
-/* SYSSTATUS */
-#define MMU_SYS_RESETDONE 1
-
/* IRQSTATUS & IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 << 4)
#define MMU_IRQ_TABLEWALKFAULT (1 << 3)
@@ -88,7 +84,6 @@ static void __iommu_set_twl(struct omap_iommu *obj, bool on)
static int omap2_iommu_enable(struct omap_iommu *obj)
{
u32 l, pa;
- unsigned long timeout;
if (!obj->iopgd || !IS_ALIGNED((u32)obj->iopgd, SZ_16K))
return -EINVAL;
@@ -97,20 +92,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
if (!IS_ALIGNED(pa, SZ_16K))
return -EINVAL;
- iommu_write_reg(obj, MMU_SYS_SOFTRESET, MMU_SYSCONFIG);
-
- timeout = jiffies + msecs_to_jiffies(20);
- do {
- l = iommu_read_reg(obj, MMU_SYSSTATUS);
- if (l & MMU_SYS_RESETDONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (!(l & MMU_SYS_RESETDONE)) {
- dev_err(obj->dev, "can't take mmu out of reset\n");
- return -ENODEV;
- }
-
l = iommu_read_reg(obj, MMU_REVISION);
dev_info(obj->dev, "%s: version %d.%d\n", obj->name,
(l >> 4) & 0xf, l & 0xf);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index ac49384..02d98ce 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,56 @@
#include <linux/module.h>
#include <linux/platform_device.h>
+#include <linux/err.h>
+#include <linux/slab.h>
#include <plat/iommu.h>
#include <plat/irqs.h>
+#include <plat/omap_hwmod.h>
+#include <plat/omap_device.h>
-struct iommu_device {
- resource_size_t base;
- int irq;
- struct iommu_platform_data pdata;
- struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
- {
- .base = 0x480bd400,
- .irq = 24,
- .pdata = {
- .name = "isp",
- .nr_tlb_entries = 8,
- .clk_name = "cam_ick",
- .da_start = 0x0,
- .da_end = 0xFFFFF000,
- },
- },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
- {
- .base = 0x5d000000,
- .irq = 28,
- .pdata = {
- .name = "iva2",
- .nr_tlb_entries = 32,
- .clk_name = "iva2_ck",
- .da_start = 0x11000000,
- .da_end = 0xFFFFF000,
- },
- },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
- {
- .base = OMAP4_MMU1_BASE,
- .irq = OMAP44XX_IRQ_DUCATI_MMU,
- .pdata = {
- .name = "ducati",
- .nr_tlb_entries = 32,
- .clk_name = "ipu_fck",
- .da_start = 0x0,
- .da_end = 0xFFFFF000,
- },
- },
-#if defined(CONFIG_MPU_TESLA_IOMMU)
- {
- .base = OMAP4_MMU2_BASE,
- .irq = INT_44XX_DSP_MMU,
- .pdata = {
- .name = "tesla",
- .nr_tlb_entries = 32,
- .clk_name = "tesla_ick",
- .da_start = 0x0,
- .da_end = 0xFFFFF000,
- },
- },
-#endif
-};
-#define NR_OMAP4_IOMMU_DEVICES ARRAY_SIZE(omap4_devices)
-static struct platform_device *omap4_iommu_pdev[NR_OMAP4_IOMMU_DEVICES];
-#else
-#define omap4_devices NULL
-#define NR_OMAP4_IOMMU_DEVICES 0
-#define omap4_iommu_pdev NULL
-#endif
-
-static struct platform_device **omap_iommu_pdev;
-
-static int __init omap_iommu_init(void)
+static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
{
- int i, err;
- struct resource res[] = {
- { .flags = IORESOURCE_MEM },
- { .flags = IORESOURCE_IRQ },
- };
+ struct platform_device *pdev;
+ struct iommu_platform_data *pdata;
+ struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh->dev_attr;
+ static int i;
- if (cpu_is_omap34xx()) {
- devices = omap3_devices;
- omap_iommu_pdev = omap3_iommu_pdev;
- num_iommu_devices = NR_OMAP3_IOMMU_DEVICES;
- } else if (cpu_is_omap44xx()) {
- devices = omap4_devices;
- omap_iommu_pdev = omap4_iommu_pdev;
- num_iommu_devices = NR_OMAP4_IOMMU_DEVICES;
- } else
- return -ENODEV;
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
- for (i = 0; i < num_iommu_devices; i++) {
- struct platform_device *pdev;
- const struct iommu_device *d = &devices[i];
+ pdata->name = oh->name;
+ pdata->clk_name = oh->main_clk;
+ pdata->nr_tlb_entries = a->nr_tlb_entries;
+ pdata->da_start = a->da_start;
+ pdata->da_end = a->da_end;
- pdev = platform_device_alloc("omap-iommu", i);
- if (!pdev) {
- err = -ENOMEM;
- goto err_out;
- }
+ pdev = omap_device_build("omap-iommu", i, oh, pdata, sizeof(*pdata),
+ NULL, 0, 0);
- res[0].start = d->base;
- res[0].end = d->base + MMU_REG_SIZE - 1;
- res[1].start = res[1].end = d->irq;
+ kfree(pdata);
- err = platform_device_add_resources(pdev, res,
- ARRAY_SIZE(res));
- if (err)
- goto err_out;
- err = platform_device_add_data(pdev, &d->pdata,
- sizeof(d->pdata));
- if (err)
- goto err_out;
- err = platform_device_add(pdev);
- if (err)
- goto err_out;
- omap_iommu_pdev[i] = pdev;
+ if (IS_ERR(pdev)) {
+ pr_err("%s: device build err: %ld\n", __func__, PTR_ERR(pdev));
+ return PTR_ERR(pdev);
}
+
+ i++;
+
return 0;
+}
-err_out:
- while (i--)
- platform_device_put(omap_iommu_pdev[i]);
- return err;
+static int __init omap_iommu_init(void)
+{
+ return omap_hwmod_for_each_by_class("mmu", omap_iommu_dev_init, NULL);
}
/* must be ready before omap3isp is probed */
subsys_initcall(omap_iommu_init);
static void __exit omap_iommu_exit(void)
{
- int i;
-
- for (i = 0; i < num_iommu_devices; i++)
- platform_device_unregister(omap_iommu_pdev[i]);
+ /* Do nothing */
}
module_exit(omap_iommu_exit);
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index 44518cc..ed56424 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -119,7 +119,7 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
const char *clk_name;
- const int nr_tlb_entries;
+ int nr_tlb_entries;
u32 da_start;
u32 da_end;
};
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 9bdbf2f..93d7d84 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -906,9 +906,6 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev)
struct resource *res;
struct iommu_platform_data *pdata = pdev->dev.platform_data;
- if (pdev->num_resources != 2)
- return -EINVAL;
-
obj = kzalloc(sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
if (!obj)
return -ENOMEM;
--
1.7.4.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH 5/6] ARM: OMAP2+: iommu: add reset handling
2012-06-16 1:55 ` Omar Ramirez Luna
@ 2012-06-16 1:56 ` Omar Ramirez Luna
-1 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-06-16 1:56 UTC (permalink / raw)
To: Tony Lindgren, Benoit Cousson
Cc: Ohad Ben-Cohen, Russell King,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Laurent Pinchart, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Recent changes in hwmod now require for drivers to handle reset
lines. Otherwise iommu initialization will fail.
Signed-off-by: Omar Ramirez Luna <omar.luna-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm/mach-omap2/omap-iommu.c | 6 ++++++
arch/arm/plat-omap/include/plat/iommu.h | 6 ++++++
drivers/iommu/omap-iommu.c | 20 ++++++++++++++++++--
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 02d98ce..96eecd8 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -37,6 +37,12 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
pdata->da_start = a->da_start;
pdata->da_end = a->da_end;
+ if (oh->rst_lines_cnt == 1) {
+ pdata->reset_name = oh->rst_lines->name;
+ pdata->assert_reset = omap_device_assert_hardreset;
+ pdata->deassert_reset = omap_device_deassert_hardreset;
+ }
+
pdev = omap_device_build("omap-iommu", i, oh, pdata, sizeof(*pdata),
NULL, 0, 0);
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index ed56424..bb15b85 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -13,6 +13,8 @@
#ifndef __MACH_IOMMU_H
#define __MACH_IOMMU_H
+#include <linux/platform_device.h>
+
struct iotlb_entry {
u32 da;
u32 pa;
@@ -119,9 +121,13 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
const char *clk_name;
+ const char *reset_name;
int nr_tlb_entries;
u32 da_start;
u32 da_end;
+
+ int (*assert_reset)(struct platform_device *pdev, const char *name);
+ int (*deassert_reset)(struct platform_device *pdev, const char *name);
};
/**
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 93d7d84..f0d6865 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -125,13 +125,23 @@ EXPORT_SYMBOL_GPL(omap_iommu_arch_version);
static int iommu_enable(struct omap_iommu *obj)
{
int err;
+ struct platform_device *pdev = to_platform_device(obj->dev);
+ struct iommu_platform_data *pdata = pdev->dev.platform_data;
- if (!obj)
+ if (!obj || !pdata)
return -EINVAL;
if (!arch_iommu)
return -ENODEV;
+ if (pdata->deassert_reset) {
+ err = pdata->deassert_reset(pdev, pdata->reset_name);
+ if (err) {
+ dev_err(obj->dev, "deassert_reset failed: %d\n", err);
+ return err;
+ }
+ }
+
clk_enable(obj->clk);
err = arch_iommu->enable(obj);
@@ -142,7 +152,10 @@ static int iommu_enable(struct omap_iommu *obj)
static void iommu_disable(struct omap_iommu *obj)
{
- if (!obj)
+ struct platform_device *pdev = to_platform_device(obj->dev);
+ struct iommu_platform_data *pdata = pdev->dev.platform_data;
+
+ if (!obj || !pdata)
return;
clk_enable(obj->clk);
@@ -150,6 +163,9 @@ static void iommu_disable(struct omap_iommu *obj)
arch_iommu->disable(obj);
clk_disable(obj->clk);
+
+ if (pdata->assert_reset)
+ pdata->assert_reset(pdev, pdata->reset_name);
}
/*
--
1.7.4.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 5/6] ARM: OMAP2+: iommu: add reset handling
@ 2012-06-16 1:56 ` Omar Ramirez Luna
0 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-06-16 1:56 UTC (permalink / raw)
To: linux-arm-kernel
Recent changes in hwmod now require for drivers to handle reset
lines. Otherwise iommu initialization will fail.
Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
---
arch/arm/mach-omap2/omap-iommu.c | 6 ++++++
arch/arm/plat-omap/include/plat/iommu.h | 6 ++++++
drivers/iommu/omap-iommu.c | 20 ++++++++++++++++++--
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 02d98ce..96eecd8 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -37,6 +37,12 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
pdata->da_start = a->da_start;
pdata->da_end = a->da_end;
+ if (oh->rst_lines_cnt == 1) {
+ pdata->reset_name = oh->rst_lines->name;
+ pdata->assert_reset = omap_device_assert_hardreset;
+ pdata->deassert_reset = omap_device_deassert_hardreset;
+ }
+
pdev = omap_device_build("omap-iommu", i, oh, pdata, sizeof(*pdata),
NULL, 0, 0);
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index ed56424..bb15b85 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -13,6 +13,8 @@
#ifndef __MACH_IOMMU_H
#define __MACH_IOMMU_H
+#include <linux/platform_device.h>
+
struct iotlb_entry {
u32 da;
u32 pa;
@@ -119,9 +121,13 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
const char *clk_name;
+ const char *reset_name;
int nr_tlb_entries;
u32 da_start;
u32 da_end;
+
+ int (*assert_reset)(struct platform_device *pdev, const char *name);
+ int (*deassert_reset)(struct platform_device *pdev, const char *name);
};
/**
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 93d7d84..f0d6865 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -125,13 +125,23 @@ EXPORT_SYMBOL_GPL(omap_iommu_arch_version);
static int iommu_enable(struct omap_iommu *obj)
{
int err;
+ struct platform_device *pdev = to_platform_device(obj->dev);
+ struct iommu_platform_data *pdata = pdev->dev.platform_data;
- if (!obj)
+ if (!obj || !pdata)
return -EINVAL;
if (!arch_iommu)
return -ENODEV;
+ if (pdata->deassert_reset) {
+ err = pdata->deassert_reset(pdev, pdata->reset_name);
+ if (err) {
+ dev_err(obj->dev, "deassert_reset failed: %d\n", err);
+ return err;
+ }
+ }
+
clk_enable(obj->clk);
err = arch_iommu->enable(obj);
@@ -142,7 +152,10 @@ static int iommu_enable(struct omap_iommu *obj)
static void iommu_disable(struct omap_iommu *obj)
{
- if (!obj)
+ struct platform_device *pdev = to_platform_device(obj->dev);
+ struct iommu_platform_data *pdata = pdev->dev.platform_data;
+
+ if (!obj || !pdata)
return;
clk_enable(obj->clk);
@@ -150,6 +163,9 @@ static void iommu_disable(struct omap_iommu *obj)
arch_iommu->disable(obj);
clk_disable(obj->clk);
+
+ if (pdata->assert_reset)
+ pdata->assert_reset(pdev, pdata->reset_name);
}
/*
--
1.7.4.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
2012-06-16 1:55 ` Omar Ramirez Luna
@ 2012-07-17 10:11 ` Joerg Roedel
-1 siblings, 0 replies; 30+ messages in thread
From: Joerg Roedel @ 2012-07-17 10:11 UTC (permalink / raw)
To: Omar Ramirez Luna
Cc: Ohad Ben-Cohen, Russell King, Benoit Cousson, Tony Lindgren,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Laurent Pinchart, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Fri, Jun 15, 2012 at 08:55:58PM -0500, Omar Ramirez Luna wrote:
> Omar Ramirez Luna (6):
> ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
> ARM: OMAP3: hwmod data: add mmu data for iva and isp
> ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
> ARM: OMAP3/4: iommu: migrate to hwmod framework
> ARM: OMAP2+: iommu: add reset handling
> ARM: OMAP3/4: iommu: adapt to runtime pm
What happens with this patch-set. Comments anyone? Ohad?
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
@ 2012-07-17 10:11 ` Joerg Roedel
0 siblings, 0 replies; 30+ messages in thread
From: Joerg Roedel @ 2012-07-17 10:11 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jun 15, 2012 at 08:55:58PM -0500, Omar Ramirez Luna wrote:
> Omar Ramirez Luna (6):
> ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
> ARM: OMAP3: hwmod data: add mmu data for iva and isp
> ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
> ARM: OMAP3/4: iommu: migrate to hwmod framework
> ARM: OMAP2+: iommu: add reset handling
> ARM: OMAP3/4: iommu: adapt to runtime pm
What happens with this patch-set. Comments anyone? Ohad?
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
2012-07-17 10:11 ` Joerg Roedel
@ 2012-07-17 10:51 ` Ohad Ben-Cohen
-1 siblings, 0 replies; 30+ messages in thread
From: Ohad Ben-Cohen @ 2012-07-17 10:51 UTC (permalink / raw)
To: Joerg Roedel, Paul Walmsley
Cc: Omar Ramirez Luna, Tony Lindgren, Benoit Cousson, Russell King,
Laurent Pinchart, Felipe Contreras, linux-omap, linux-arm-kernel,
iommu
+ Paul
On Tue, Jul 17, 2012 at 1:11 PM, Joerg Roedel <joerg.roedel@amd.com> wrote:
> On Fri, Jun 15, 2012 at 08:55:58PM -0500, Omar Ramirez Luna wrote:
>> Omar Ramirez Luna (6):
>> ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
>> ARM: OMAP3: hwmod data: add mmu data for iva and isp
>> ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
>> ARM: OMAP3/4: iommu: migrate to hwmod framework
>> ARM: OMAP2+: iommu: add reset handling
>> ARM: OMAP3/4: iommu: adapt to runtime pm
>
> What happens with this patch-set. Comments anyone? Ohad?
Looks like it depends on a few OMAP hwmod changes (reset handling)
which require Paul's ACK.
Ohad.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
@ 2012-07-17 10:51 ` Ohad Ben-Cohen
0 siblings, 0 replies; 30+ messages in thread
From: Ohad Ben-Cohen @ 2012-07-17 10:51 UTC (permalink / raw)
To: linux-arm-kernel
+ Paul
On Tue, Jul 17, 2012 at 1:11 PM, Joerg Roedel <joerg.roedel@amd.com> wrote:
> On Fri, Jun 15, 2012 at 08:55:58PM -0500, Omar Ramirez Luna wrote:
>> Omar Ramirez Luna (6):
>> ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
>> ARM: OMAP3: hwmod data: add mmu data for iva and isp
>> ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
>> ARM: OMAP3/4: iommu: migrate to hwmod framework
>> ARM: OMAP2+: iommu: add reset handling
>> ARM: OMAP3/4: iommu: adapt to runtime pm
>
> What happens with this patch-set. Comments anyone? Ohad?
Looks like it depends on a few OMAP hwmod changes (reset handling)
which require Paul's ACK.
Ohad.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
2012-07-17 10:51 ` Ohad Ben-Cohen
@ 2012-07-18 17:15 ` Omar Ramirez Luna
-1 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-07-18 17:15 UTC (permalink / raw)
To: Joerg Roedel
Cc: Ohad Ben-Cohen, Paul Walmsley, Tony Lindgren, Benoit Cousson,
Russell King, Laurent Pinchart, Felipe Contreras, linux-omap,
linux-arm-kernel, iommu
On 17 July 2012 05:51, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> + Paul
>
> On Tue, Jul 17, 2012 at 1:11 PM, Joerg Roedel <joerg.roedel@amd.com> wrote:
>> On Fri, Jun 15, 2012 at 08:55:58PM -0500, Omar Ramirez Luna wrote:
>>> Omar Ramirez Luna (6):
>>> ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
>>> ARM: OMAP3: hwmod data: add mmu data for iva and isp
>>> ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
>>> ARM: OMAP3/4: iommu: migrate to hwmod framework
>>> ARM: OMAP2+: iommu: add reset handling
>>> ARM: OMAP3/4: iommu: adapt to runtime pm
>>
>> What happens with this patch-set. Comments anyone? Ohad?
>
> Looks like it depends on a few OMAP hwmod changes (reset handling)
> which require Paul's ACK.
That's correct, sorry if I failed to mention that in the cover-letter,
but it does depend on:
http://lkml.indiana.edu/hypermail/linux/kernel/1207.2/00361.html
For the hwmod reset handling. Mainly, I wanted to gather comments for
this patch set.
- omar
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
@ 2012-07-18 17:15 ` Omar Ramirez Luna
0 siblings, 0 replies; 30+ messages in thread
From: Omar Ramirez Luna @ 2012-07-18 17:15 UTC (permalink / raw)
To: linux-arm-kernel
On 17 July 2012 05:51, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> + Paul
>
> On Tue, Jul 17, 2012 at 1:11 PM, Joerg Roedel <joerg.roedel@amd.com> wrote:
>> On Fri, Jun 15, 2012 at 08:55:58PM -0500, Omar Ramirez Luna wrote:
>>> Omar Ramirez Luna (6):
>>> ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
>>> ARM: OMAP3: hwmod data: add mmu data for iva and isp
>>> ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
>>> ARM: OMAP3/4: iommu: migrate to hwmod framework
>>> ARM: OMAP2+: iommu: add reset handling
>>> ARM: OMAP3/4: iommu: adapt to runtime pm
>>
>> What happens with this patch-set. Comments anyone? Ohad?
>
> Looks like it depends on a few OMAP hwmod changes (reset handling)
> which require Paul's ACK.
That's correct, sorry if I failed to mention that in the cover-letter,
but it does depend on:
http://lkml.indiana.edu/hypermail/linux/kernel/1207.2/00361.html
For the hwmod reset handling. Mainly, I wanted to gather comments for
this patch set.
- omar
^ permalink raw reply [flat|nested] 30+ messages in thread