[PATCH 0/8] Add hwmod data for IPU & DSP processors/MMUs

[PATCH 0/8] Add hwmod data for IPU & DSP processors/MMUs

[Suman Anna]

Hi Tony,

The following series adds the hwmod data and the corresponding
pdata quirks for the various MMUs associated with the IPU and DSP
processors on DRA7xx/AM57xx SoCs. This is part 1 of the patches
for enabling the MMUs on DRA7 SoCs (OMAP4 and OMAP5 are already
supported on mainline) and providing a baseline for adding the
OMAP remoteproc driver. The hwmod data for the consumers of these
MMUs - IPU and DSP processors is also added on OMAP5 and DRA7 SoCs,
with an update to the OMAP4 ones.

Patches are baselined on your current for-next branch with commit
a70cb93b6c2f ("Merge branch 'omap-for-v4.14/dt-v3' into for-next").

I have tested the patches on current TI DRA7xx/AM57xx boards (DRA7,
DRA72, DRA71, DRA76 EVMs, AM571x & AM572x IDKs and AM57xx BeagleBoard-X15)
as well as the OMAP4 Panda and OMAP5 uEVM.

regards
Suman

Suman Anna (8):
  ARM: DRA7: hwmod data: Add MMU data for IPUs
  ARM: DRA7: hwmod data: Add MMU data for DSPs
  ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 IPUs
  ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 DSPs
  ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods
  ARM: OMAP5: hwmod_data: Add data for IPU & DSP processors
  ARM: DRA7: hwmod_data: Add data for IPUs
  ARM: DRA7: hwmod_data: Add data for DSPs

 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   2 -
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  79 +++++++
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 322 +++++++++++++++++++++++++++++
 arch/arm/mach-omap2/pdata-quirks.c         |  11 +-
 4 files changed, 411 insertions(+), 3 deletions(-)

-- 
2.13.1

[PATCH 1/8] ARM: DRA7: hwmod data: Add MMU data for IPUs

[Suman Anna]

A new MMU hwmod class and data structures are added for
representing the MMUs within the IPU1 and IPU2 processor
subsystems present on DRA7xx/AM57xx SoCs.

Note that the clock integration is slightly different between
IPU1 and IPU2. IPU2 functional clock is sourced directly from
dpll_core_h22x2_ck, while IPU1 has a mux clock for which one
of the inputs is dpll_core_h22x2_ck. This mux clock is configured
to be sourced from the dpll_core_h22x2_ck in turn, so that both
IPU1 and IPU2 run at the same clock frequency. This is already
addressed in commit 39879c7d963e ("ARM: dts: dra7xx-clocks:
Source IPU1 functional clock from CORE DPLL").

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 81 +++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index f040244c57e7..bf55802448ac 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1800,6 +1800,69 @@ static struct omap_hwmod dra7xx_mmc4_hwmod = {
 };
 
 /*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_mmu_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+			   SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dra7xx_mmu_hwmod_class = {
+	.name = "mmu",
+	.sysc = &dra7xx_mmu_sysc,
+};
+
+/* IPU MMUs */
+static struct omap_hwmod_rst_info dra7xx_mmu_ipu_resets[] = {
+	{ .name = "mmu_cache", .rst_shift = 2 },
+};
+
+/* mmu ipu1 */
+static struct omap_hwmod dra7xx_mmu_ipu1_hwmod = {
+	.name		= "mmu_ipu1",
+	.class		= &dra7xx_mmu_hwmod_class,
+	.clkdm_name	= "ipu1_clkdm",
+	.rst_lines	= dra7xx_mmu_ipu_resets,
+	.rst_lines_cnt	= ARRAY_SIZE(dra7xx_mmu_ipu_resets),
+	.main_clk	= "ipu1_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_IPU1_IPU1_CLKCTRL_OFFSET,
+			.rstctrl_offs = DRA7XX_RM_IPU1_RSTCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_IPU1_IPU1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/* mmu ipu2 */
+static struct omap_hwmod dra7xx_mmu_ipu2_hwmod = {
+	.name		= "mmu_ipu2",
+	.class		= &dra7xx_mmu_hwmod_class,
+	.clkdm_name	= "ipu2_clkdm",
+	.rst_lines	= dra7xx_mmu_ipu_resets,
+	.rst_lines_cnt	= ARRAY_SIZE(dra7xx_mmu_ipu_resets),
+	.main_clk	= "dpll_core_h22x2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_IPU2_IPU2_CLKCTRL_OFFSET,
+			.rstctrl_offs = DRA7XX_RM_IPU2_RSTCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_IPU2_IPU2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/*
  * 'mpu' class
  *
  */
@@ -2901,6 +2964,22 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__l4_cfg = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l3_main_1 -> mmu_ipu1 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mmu_ipu1 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_mmu_ipu1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> mmu_ipu2 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mmu_ipu2 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_mmu_ipu2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l3_main_1 -> l4_per1 */
 static struct omap_hwmod_ocp_if dra7xx_l3_main_1__l4_per1 = {
 	.master		= &dra7xx_l3_main_1_hwmod,
@@ -4010,6 +4089,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
 	&dra7xx_l4_per1__mmc2,
 	&dra7xx_l4_per1__mmc3,
 	&dra7xx_l4_per1__mmc4,
+	&dra7xx_l3_main_1__mmu_ipu1,
+	&dra7xx_l3_main_1__mmu_ipu2,
 	&dra7xx_l4_cfg__mpu,
 	&dra7xx_l4_cfg__ocp2scp1,
 	&dra7xx_l4_cfg__ocp2scp3,
-- 
2.13.1

[PATCH 2/8] ARM: DRA7: hwmod data: Add MMU data for DSPs

[Suman Anna]

Add the data structures for representing the MMUs within the DSP
processor subsystems present in DRA7xx/AM57xx SoCs. The DRA7xx
family of SoCs usually have one or two DSPs. The DRA74x/DRA76x
family has two DSPs, while DRA72x/DRA71x has only a single DSP.
Each DSP subsystem has two MMUs, one for the processor core and
the other for the internal EDMA block. The hwmod data for the
second DSP is only added for DRA74x/DRA76x family of SoCs.

Both these MMUs share a common reset line, the MMU on the EDMA
port is expected to be mirror-programmed alongside the primary
MMU. The reset data is added to both the MMUs to allow the
omap_hwmod layer to skip the enabling and idling of these devices,
as that would require the reset be released, which is outside
the scope of the hwmod core code. The other PRCM data fields are
also skipped for both the second MMUs, this will be handled as
part of the primary MMU enabling sequence. The pdata quirks will
also not be added for the second MMU as the OMAP IOMMU driver
releases the reset once and is expected to program both the MMUs
together.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 109 ++++++++++++++++++++++++++++++
 1 file changed, 109 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index bf55802448ac..63ad0d3217dc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1821,6 +1821,77 @@ static struct omap_hwmod_class dra7xx_mmu_hwmod_class = {
 	.sysc = &dra7xx_mmu_sysc,
 };
 
+/* DSP MMUs */
+static struct omap_hwmod_rst_info dra7xx_mmu_dsp_resets[] = {
+	{ .name = "mmu_cache", .rst_shift = 1 },
+};
+
+/* mmu0 - dsp1 */
+static struct omap_hwmod dra7xx_mmu0_dsp1_hwmod = {
+	.name		= "mmu0_dsp1",
+	.class		= &dra7xx_mmu_hwmod_class,
+	.clkdm_name	= "dsp1_clkdm",
+	.rst_lines	= dra7xx_mmu_dsp_resets,
+	.rst_lines_cnt	= ARRAY_SIZE(dra7xx_mmu_dsp_resets),
+	.main_clk	= "dpll_dsp_m2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_DSP1_DSP1_CLKCTRL_OFFSET,
+			.rstctrl_offs = DRA7XX_RM_DSP1_RSTCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_DSP1_DSP1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/* mmu1 - dsp1 */
+static struct omap_hwmod dra7xx_mmu1_dsp1_hwmod = {
+	.name		= "mmu1_dsp1",
+	.class		= &dra7xx_mmu_hwmod_class,
+	.clkdm_name	= "dsp1_clkdm",
+	.rst_lines	= dra7xx_mmu_dsp_resets,
+	.rst_lines_cnt	= ARRAY_SIZE(dra7xx_mmu_dsp_resets),
+	.main_clk	= "dpll_dsp_m2_ck",
+	.prcm = {
+		.omap4 = {
+			.rstctrl_offs = DRA7XX_RM_DSP1_RSTCTRL_OFFSET,
+		},
+	},
+};
+
+/* mmu0 - dsp2 */
+static struct omap_hwmod dra7xx_mmu0_dsp2_hwmod = {
+	.name		= "mmu0_dsp2",
+	.class		= &dra7xx_mmu_hwmod_class,
+	.clkdm_name	= "dsp2_clkdm",
+	.rst_lines	= dra7xx_mmu_dsp_resets,
+	.rst_lines_cnt	= ARRAY_SIZE(dra7xx_mmu_dsp_resets),
+	.main_clk	= "dpll_dsp_m2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_DSP2_DSP2_CLKCTRL_OFFSET,
+			.rstctrl_offs = DRA7XX_RM_DSP2_RSTCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_DSP2_DSP2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/* mmu1 - dsp2 */
+static struct omap_hwmod dra7xx_mmu1_dsp2_hwmod = {
+	.name		= "mmu1_dsp2",
+	.class		= &dra7xx_mmu_hwmod_class,
+	.clkdm_name	= "dsp2_clkdm",
+	.rst_lines	= dra7xx_mmu_dsp_resets,
+	.rst_lines_cnt	= ARRAY_SIZE(dra7xx_mmu_dsp_resets),
+	.main_clk	= "dpll_dsp_m2_ck",
+	.prcm = {
+		.omap4 = {
+			.rstctrl_offs = DRA7XX_RM_DSP2_RSTCTRL_OFFSET,
+		},
+	},
+};
+
 /* IPU MMUs */
 static struct omap_hwmod_rst_info dra7xx_mmu_ipu_resets[] = {
 	{ .name = "mmu_cache", .rst_shift = 2 },
@@ -2964,6 +3035,38 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__l4_cfg = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l3_main_1 -> mmu0_dsp1 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mmu0_dsp1 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_mmu0_dsp1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> mmu1_dsp1 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mmu1_dsp1 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_mmu1_dsp1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> mmu0_dsp2 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mmu0_dsp2 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_mmu0_dsp2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> mmu1_dsp2 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mmu1_dsp2 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_mmu1_dsp2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l3_main_1 -> mmu_ipu1 */
 static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mmu_ipu1 = {
 	.master		= &dra7xx_l3_main_1_hwmod,
@@ -4089,6 +4192,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
 	&dra7xx_l4_per1__mmc2,
 	&dra7xx_l4_per1__mmc3,
 	&dra7xx_l4_per1__mmc4,
+	&dra7xx_l3_main_1__mmu0_dsp1,
+	&dra7xx_l3_main_1__mmu1_dsp1,
 	&dra7xx_l3_main_1__mmu_ipu1,
 	&dra7xx_l3_main_1__mmu_ipu2,
 	&dra7xx_l4_cfg__mpu,
@@ -4153,11 +4258,15 @@ static struct omap_hwmod_ocp_if *dra7xx_gp_hwmod_ocp_ifs[] __initdata = {
 /* SoC variant specific hwmod links */
 static struct omap_hwmod_ocp_if *dra76x_hwmod_ocp_ifs[] __initdata = {
 	&dra7xx_l4_per3__usb_otg_ss4,
+	&dra7xx_l3_main_1__mmu0_dsp2,
+	&dra7xx_l3_main_1__mmu1_dsp2,
 	NULL,
 };
 
 static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = {
 	&dra7xx_l4_per3__usb_otg_ss4,
+	&dra7xx_l3_main_1__mmu0_dsp2,
+	&dra7xx_l3_main_1__mmu1_dsp2,
 	NULL,
 };
 
-- 
2.13.1

[PATCH 3/8] ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 IPUs

[Suman Anna]

The IOMMUs within the IPU processor subsystems in DRA7xx SoCs
are very similar to those in OMAP4/OMAP5, so extend the OMAP4
iommu pdata quirks for these MMUs as well.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 arch/arm/mach-omap2/pdata-quirks.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 6b433fce65a5..253315393a29 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -412,7 +412,8 @@ static void __init omap3_pandora_legacy_init(void)
 }
 #endif /* CONFIG_ARCH_OMAP3 */
 
-#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
+	defined(CONFIG_SOC_DRA7XX)
 static struct iommu_platform_data omap4_iommu_pdata = {
 	.reset_name = "mmu_cache",
 	.assert_reset = omap_device_assert_hardreset,
@@ -588,6 +589,10 @@ static struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
 		       &dra7_hsmmc_data_mmc2),
 	OF_DEV_AUXDATA("ti,dra7-hsmmc", 0x480ad000, "480ad000.mmc",
 		       &dra7_hsmmc_data_mmc3),
+	OF_DEV_AUXDATA("ti,dra7-iommu", 0x55082000, "55082000.mmu",
+		       &omap4_iommu_pdata),
+	OF_DEV_AUXDATA("ti,dra7-iommu", 0x58882000, "58882000.mmu",
+		       &omap4_iommu_pdata),
 #endif
 	/* Common auxdata */
 	OF_DEV_AUXDATA("pinctrl-single", 0, NULL, &pcs_pdata),
-- 
2.13.1

[PATCH 4/8] ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 DSPs

[Suman Anna]

The DSP processor subsystem in DRA7xx SoCs has two MMUs, one
for the processor port and another for an EDMA port. Both
these MMUs share a common reset line, the MMU on the EDMA
port will always be mirror-programmed alongside the primary
MMU, with the reset handled once. The reset handling is the
same as on equivalent DSP subsystems on OMAP4/OMAP5 SoCs, so
extend the OMAP4 iommu pdata quirks for reset for the MMU
associated with the processor port only.

Add these pdata quirks for both the DSP1 and DSP2 processor
subsystems. Note that DSP2 subsystem is present only on the
DRA74x/DRA76x SoC variants and not on DRA72x/DRA71x SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 arch/arm/mach-omap2/pdata-quirks.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 253315393a29..65e566f0c5ea 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -589,6 +589,10 @@ static struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
 		       &dra7_hsmmc_data_mmc2),
 	OF_DEV_AUXDATA("ti,dra7-hsmmc", 0x480ad000, "480ad000.mmc",
 		       &dra7_hsmmc_data_mmc3),
+	OF_DEV_AUXDATA("ti,dra7-dsp-iommu", 0x40d01000, "40d01000.mmu",
+		       &omap4_iommu_pdata),
+	OF_DEV_AUXDATA("ti,dra7-dsp-iommu", 0x41501000, "41501000.mmu",
+		       &omap4_iommu_pdata),
 	OF_DEV_AUXDATA("ti,dra7-iommu", 0x55082000, "55082000.mmu",
 		       &omap4_iommu_pdata),
 	OF_DEV_AUXDATA("ti,dra7-iommu", 0x58882000, "58882000.mmu",
-- 
2.13.1

[PATCH 5/8] ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods

[Suman Anna]

The .modulemode field is removed from both the IPU and DSP processor
hwmods. This fixes a potential kernel crash during the shutdown sequence
of any of these remoteproc devices, either during a normal teardown or
during a recovery.

The DSP and IPU processor subsystems are represented by multiple hwmods,
one for each of the MMUs present within the subsystem and one for the
processor cores. The processor subsystem is clocked from a single clock
source with separate reset lines for each of the processors and the
MMUs. This clock and reset information is represented in separate hwmods
to allow the management of these entities in different drivers operating
on the corresponding platform devices. This doesn't fit quite well into
the current omap_hwmod layer due to these inter-dependencies.

A remoteproc startup sequence involves enabling and programming of the
MMUs, loading of the firmware into RAM mapped by the MMUs, and releasing
the processors from reset. A shutdown sequence follows a reverse pattern
with the processors put into reset first followed by the unmapping and
disabling of the MMUs. Both the processors and the MMUs are present
within a single clock domain and requires the domain be clocked and
enabled until the last entity. The kernel crash can happen during the
unmapping phase of the MMUs, as the hwmod layer disables the module
during the omap_device_idle processing of the processor hwmod. This
issue is fixed by not defining a modulemode for the IPU/DSP processors,
which results in keeping the module in an activated state. The module
is disabled properly during the omap_device_idle processing of the MMU
hwmod while disabling the MMU.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 --
 1 file changed, 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 3e2d792fd9df..d183ffdf37e6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -550,7 +550,6 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
 			.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,
 		},
 	},
 };
@@ -1561,7 +1560,6 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
 			.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,
 		},
 	},
 };
-- 
2.13.1

[PATCH 5/8] ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods

[Tony Lindgren]

* Suman Anna <s-anna@ti.com> [170821 16:48]:
>
> A shutdown sequence follows a reverse pattern
> with the processors put into reset first followed by the unmapping and
> disabling of the MMUs. Both the processors and the MMUs are present
> within a single clock domain and requires the domain be clocked and
> enabled until the last entity. The kernel crash can happen during the
> unmapping phase of the MMUs, as the hwmod layer disables the module
> during the omap_device_idle processing of the processor hwmod. This
> issue is fixed by not defining a modulemode for the IPU/DSP processors,
> which results in keeping the module in an activated state. The module
> is disabled properly during the omap_device_idle processing of the MMU
> hwmod while disabling the MMU.

I think a better way to fix this would be to make sure the module
is enabled during the unmapping phase of the MMUs. If there is no
driver left at that point to call pm_runtime_get() on the module,
do it via pdata-quirks.c using struct iommu_platform_data?

If you can't add the enable/disable around existing assert_reset/
deassert_reset, you can add a new one.

Regards,

Tony

[PATCH 5/8] ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods

[Suman Anna]

Hi Tony,

On 08/22/2017 12:37 PM, Tony Lindgren wrote:
> * Suman Anna <s-anna@ti.com> [170821 16:48]:
>>
>> A shutdown sequence follows a reverse pattern
>> with the processors put into reset first followed by the unmapping and
>> disabling of the MMUs. Both the processors and the MMUs are present
>> within a single clock domain and requires the domain be clocked and
>> enabled until the last entity. The kernel crash can happen during the
>> unmapping phase of the MMUs, as the hwmod layer disables the module
>> during the omap_device_idle processing of the processor hwmod. This
>> issue is fixed by not defining a modulemode for the IPU/DSP processors,
>> which results in keeping the module in an activated state. The module
>> is disabled properly during the omap_device_idle processing of the MMU
>> hwmod while disabling the MMU.
> 
> I think a better way to fix this would be to make sure the module
> is enabled during the unmapping phase of the MMUs. If there is no
> driver left at that point to call pm_runtime_get() on the module,
> do it via pdata-quirks.c using struct iommu_platform_data?

The problem is because there is no reference counting on modulemode
programming unlike clocks or omap_device pm_domain callbacks. The IOMMU
driver already has an active pm_runtime_get() invoked earlier and
invoking another wouldn't result in any change.

> If you can't add the enable/disable around existing assert_reset/
> deassert_reset, you can add a new one.

The remoteproc driver is only dealing with its resets and hwmod while
the IOMMU driver is dealing with its dedicated reset. The PRCM registers
though are a single set between the two.

regards
Suman

[PATCH 5/8] ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods

[Tony Lindgren]

* Suman Anna <s-anna@ti.com> [170822 11:45]:
> On 08/22/2017 12:37 PM, Tony Lindgren wrote:
> > I think a better way to fix this would be to make sure the module
> > is enabled during the unmapping phase of the MMUs. If there is no
> > driver left at that point to call pm_runtime_get() on the module,
> > do it via pdata-quirks.c using struct iommu_platform_data?
> 
> The problem is because there is no reference counting on modulemode
> programming unlike clocks or omap_device pm_domain callbacks. The IOMMU
> driver already has an active pm_runtime_get() invoked earlier and
> invoking another wouldn't result in any change.

Hmm iommu driver has pm_runtime_get() on which modules? Can you
please point me to that code too so I can follow..

Or is there maybe a single module shared across multiple devices?

If so, we need a minimal module wrapper driver. You can do what we
already do for musb on am335x in drivers/usb/musb/musb_am335x.c.
A single module has two musb instances and a shared cppi41 dma
instance. See also it's related entries in am33xx.dtsi.

Note that the clkctrl clocks are available now as clocks, so they
could be directly enabled for testing. See omap4_tesla_clkctrl_regs
and omap4_ducati_clkctrl_regs if that helps.

> The remoteproc driver is only dealing with its resets and hwmod while
> the IOMMU driver is dealing with its dedicated reset. The PRCM registers
> though are a single set between the two.

Sorry but I'm having hard time following which driver claims
which modules :)

Regards,

Tony

[PATCH 5/8] ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods

[Suman Anna]

Hi Tony,

On 08/22/2017 02:24 PM, Tony Lindgren wrote:
> * Suman Anna <s-anna@ti.com> [170822 11:45]:
>> On 08/22/2017 12:37 PM, Tony Lindgren wrote:
>>> I think a better way to fix this would be to make sure the module
>>> is enabled during the unmapping phase of the MMUs. If there is no
>>> driver left at that point to call pm_runtime_get() on the module,
>>> do it via pdata-quirks.c using struct iommu_platform_data?
>>
>> The problem is because there is no reference counting on modulemode
>> programming unlike clocks or omap_device pm_domain callbacks. The IOMMU
>> driver already has an active pm_runtime_get() invoked earlier and
>> invoking another wouldn't result in any change.
> 
> Hmm iommu driver has pm_runtime_get() on which modules? Can you
> please point me to that code too so I can follow..

The OMAP IOMMU driver deals with the MMU device only and uses both the
omap_device_{assert/deassert}_hardreset and omap_device_{enable/idle} on
the omap_device associated with the MMU device. The MMU register space
has a SYSCONFIG register (also has softreset that only resets the MMU
block) so we do have a hwmod associated with it to deal with its
setting. Today, the reset API is invoked through pdata-quirks and the
omap_device_{enable/idle} API through the pm_runtime in the IOMMU
driver. Lookup iommu_enable() and iommu_disable() in
drivers/iommu/omap-iommu.c

> Or is there maybe a single module shared across multiple devices?

Yeah kinda. The PRCM registers are just one set, with different bits in
RSTCTRL and RSTST registers dealing with different reset lines. The API
to deal with resets is still using the omap_device API and they are
invoked using pdata-quirks. For OMAP remoteproc driver, we only have one
pdata quirks defined, but the function we plug in invokes both the reset
as well as the omap_device_enable/idle functions (not in mainline yet).
See [1] for reference.

So, we have a unique hwmod/omap_device associated with each of the
individual devices (IOMMU and the processor are represented as a device
each).

> If so, we need a minimal module wrapper driver. You can do what we
> already do for musb on am335x in drivers/usb/musb/musb_am335x.c.
> A single module has two musb instances and a shared cppi41 dma
> instance. See also it's related entries in am33xx.dtsi.
> 
> Note that the clkctrl clocks are available now as clocks, so they
> could be directly enabled for testing. See omap4_tesla_clkctrl_regs
> and omap4_ducati_clkctrl_regs if that helps.

OK, looks like these are recent additions by Tero. It will still be a
shared set between the MMU and remoteproc drivers, but let me look into
how these get integrated. At this point, I don't want to be dealing with
separate clk API in my driver.

>> The remoteproc driver is only dealing with its resets and hwmod while
>> the IOMMU driver is dealing with its dedicated reset. The PRCM registers
>> though are a single set between the two.
> 
> Sorry but I'm having hard time following which driver claims
> which modules :)

OMAP IOMMU driver claims and deals with the MMU device in each of the
DSP and IPU subsystems. The OMAP remoteproc driver deals with the DSP or
the Cortex-M3/M4 cores.

regards
Suman

[1]
http://git.ti.com/gitweb/?p=rpmsg/remoteproc.git;a=blob;f=arch/arm/mach-omap2/remoteproc.c;h=78a4c4746bb568420b251bc42db02849ef439e27;hb=6f7d874549ce847eeb0308704b6a477c308f59e5

[PATCH 6/8] ARM: OMAP5: hwmod_data: Add data for IPU & DSP processors

[Suman Anna]

OMAP5, like OMAP4, also has an IPU and a DSP processor subsystems.
The relevant hwmod classes and data structures are added for these
devices.

Do note that these hwmod data strucutures do not have a .modulemode
field as the devices are managed together with their corresponding
MMUs. Each of the processor subsystem and its MMU are present within
the same clock domain and requires the domain be clocked and enabled
until the last entity is disabled. The module is disabled properly
during the omap_device_idle processing of the MMU hwmod while
disabling the MMU.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 79 ++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 9a67f013ebad..15f217b5e462 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -335,6 +335,36 @@ static struct omap_hwmod omap54xx_dmic_hwmod = {
 };
 
 /*
+ * 'dsp' class
+ * dsp sub-system
+ */
+
+static struct omap_hwmod_class omap54xx_dsp_hwmod_class = {
+	.name	= "dsp",
+};
+
+static struct omap_hwmod_rst_info omap54xx_dsp_resets[] = {
+	{ .name = "dsp", .rst_shift = 0 },
+};
+
+/* dsp */
+static struct omap_hwmod omap54xx_dsp_hwmod = {
+	.name		= "dsp",
+	.class		= &omap54xx_dsp_hwmod_class,
+	.clkdm_name	= "dsp_clkdm",
+	.rst_lines	= omap54xx_dsp_resets,
+	.rst_lines_cnt	= ARRAY_SIZE(omap54xx_dsp_resets),
+	.main_clk	= "dpll_iva_h11x2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_DSP_DSP_CLKCTRL_OFFSET,
+			.rstctrl_offs = OMAP54XX_RM_DSP_RSTCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_DSP_DSP_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
  * 'dss' class
  * display sub-system
  */
@@ -940,6 +970,37 @@ static struct omap_hwmod omap54xx_i2c5_hwmod = {
 };
 
 /*
+ * 'ipu' class
+ * image processor unit
+ */
+
+static struct omap_hwmod_class omap54xx_ipu_hwmod_class = {
+	.name	= "ipu",
+};
+
+static struct omap_hwmod_rst_info omap54xx_ipu_resets[] = {
+	{ .name = "cpu0", .rst_shift = 0 },
+	{ .name = "cpu1", .rst_shift = 1 },
+};
+
+/* ipu */
+static struct omap_hwmod omap54xx_ipu_hwmod = {
+	.name		= "ipu",
+	.class		= &omap54xx_ipu_hwmod_class,
+	.clkdm_name	= "ipu_clkdm",
+	.rst_lines	= omap54xx_ipu_resets,
+	.rst_lines_cnt	= ARRAY_SIZE(omap54xx_ipu_resets),
+	.main_clk	= "dpll_core_h22x2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_IPU_IPU_CLKCTRL_OFFSET,
+			.rstctrl_offs = OMAP54XX_RM_IPU_RSTCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_IPU_IPU_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
  * 'kbd' class
  * keyboard controller
  */
@@ -2135,6 +2196,14 @@ static struct omap_hwmod_ocp_if omap54xx_l4_cfg__l3_main_1 = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* dsp -> l3_main_1 */
+static struct omap_hwmod_ocp_if omap54xx_dsp__l3_main_1 = {
+	.master		= &omap54xx_dsp_hwmod,
+	.slave		= &omap54xx_l3_main_1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_cfg -> mmu_dsp */
 static struct omap_hwmod_ocp_if omap54xx_l4_cfg__mmu_dsp = {
 	.master		= &omap54xx_l4_cfg_hwmod,
@@ -2167,6 +2236,14 @@ static struct omap_hwmod_ocp_if omap54xx_l4_cfg__l3_main_2 = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l3_main_2 -> ipu */
+static struct omap_hwmod_ocp_if omap54xx_l3_main_2__ipu = {
+	.master		= &omap54xx_l3_main_2_hwmod,
+	.slave		= &omap54xx_ipu_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l3_main_2 -> mmu_ipu */
 static struct omap_hwmod_ocp_if omap54xx_l3_main_2__mmu_ipu = {
 	.master		= &omap54xx_l3_main_2_hwmod,
@@ -2766,7 +2843,9 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] __initdata = {
 	&omap54xx_l3_main_3__l3_instr,
 	&omap54xx_l3_main_2__l3_main_1,
 	&omap54xx_l4_cfg__l3_main_1,
+	&omap54xx_dsp__l3_main_1,
 	&omap54xx_mpu__l3_main_1,
+	&omap54xx_l3_main_2__ipu,
 	&omap54xx_l3_main_1__l3_main_2,
 	&omap54xx_l4_cfg__l3_main_2,
 	&omap54xx_l3_main_1__l3_main_3,
-- 
2.13.1

[PATCH 6/8] ARM: OMAP5: hwmod_data: Add data for IPU & DSP processors

[Tony Lindgren]

* Suman Anna <s-anna@ti.com> [170821 16:48]:
> OMAP5, like OMAP4, also has an IPU and a DSP processor subsystems.
> The relevant hwmod classes and data structures are added for these
> devices.
> 
> Do note that these hwmod data strucutures do not have a .modulemode
> field as the devices are managed together with their corresponding
> MMUs. Each of the processor subsystem and its MMU are present within
> the same clock domain and requires the domain be clocked and enabled
> until the last entity is disabled. The module is disabled properly
> during the omap_device_idle processing of the MMU hwmod while
> disabling the MMU.

I think we can make that issue go away, see below.

> --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> @@ -335,6 +335,36 @@ static struct omap_hwmod omap54xx_dmic_hwmod = {
> +/* dsp */
> +static struct omap_hwmod omap54xx_dsp_hwmod = {
> +	.name		= "dsp",
> +	.class		= &omap54xx_dsp_hwmod_class,
> +	.clkdm_name	= "dsp_clkdm",
> +	.rst_lines	= omap54xx_dsp_resets,
> +	.rst_lines_cnt	= ARRAY_SIZE(omap54xx_dsp_resets),
> +	.main_clk	= "dpll_iva_h11x2_ck",
> +	.prcm = {
> +		.omap4 = {
> +			.clkctrl_offs = OMAP54XX_CM_DSP_DSP_CLKCTRL_OFFSET,
> +			.rstctrl_offs = OMAP54XX_RM_DSP_RSTCTRL_OFFSET,
> +			.context_offs = OMAP54XX_RM_DSP_DSP_CONTEXT_OFFSET,
> +		},
> +	},
> +};
> +
> +/*

I don't think we should add a second instance for the DSP_CLKCTRL.

We already have mmu_dsp instance and I'm pretty sure this should be
just one parent "ti,sysc-omap4" interconnect target module instance.
Then the MMU and DSP can be children of that node. I think it's set
the same way for all omap4 and later SoCs. So let's wait on
this series until we have this verified.

Tehn for resets, in the long run we can add reset controller support
to the ti-sysc driver and then the MMU driver can do the reset with
device_reset(dev->parent). Also a separate resetctrl driver is needed
that the ti-sysc driver can request.

But yeah sorry no immediate solution available for the reset part.

Regards,

Tony

[PATCH 7/8] ARM: DRA7: hwmod_data: Add data for IPUs

[Suman Anna]

The DRA7xx family of SoCs usually have two IPU remote processor
subsystems. These subsystems are very similar to the respective
processor subsystems on OMAP4/OMAP5 in terms of clock and reset
integration. The relevant hwmod classes and data structures are
added for IPU1 and IPU2 remoteproc devices that's present on
almost all DRA7xx/AM57xx SoCs.

Do note that these hwmod data structures do not have a .modulemode
field as the devices are managed together with their corresponding
MMUs. Each of the processor subsystem and its MMU are present within
the same clock domain and requires the domain be clocked and enabled
until the last entity is disabled. The module is disabled properly
during the omap_device_idle processing of the MMU hwmod while
disabling the MMU.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 66 +++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 63ad0d3217dc..e65a02855633 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1201,6 +1201,54 @@ static struct omap_hwmod dra7xx_i2c5_hwmod = {
 };
 
 /*
+ * 'ipu' class
+ * image processor unit
+ */
+
+static struct omap_hwmod_class dra7xx_ipu_hwmod_class = {
+	.name	= "ipu",
+};
+
+static struct omap_hwmod_rst_info dra7xx_ipu_resets[] = {
+	{ .name = "cpu0", .rst_shift = 0 },
+	{ .name = "cpu1", .rst_shift = 1 },
+};
+
+/* ipu1 processor */
+static struct omap_hwmod dra7xx_ipu1_hwmod = {
+	.name		= "ipu1",
+	.class		= &dra7xx_ipu_hwmod_class,
+	.clkdm_name	= "ipu1_clkdm",
+	.rst_lines	= dra7xx_ipu_resets,
+	.rst_lines_cnt	= ARRAY_SIZE(dra7xx_ipu_resets),
+	.main_clk	= "ipu1_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_IPU1_IPU1_CLKCTRL_OFFSET,
+			.rstctrl_offs = DRA7XX_RM_IPU1_RSTCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_IPU1_IPU1_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/* ipu2 processor */
+static struct omap_hwmod dra7xx_ipu2_hwmod = {
+	.name		= "ipu2",
+	.class		= &dra7xx_ipu_hwmod_class,
+	.clkdm_name	= "ipu2_clkdm",
+	.rst_lines	= dra7xx_ipu_resets,
+	.rst_lines_cnt	= ARRAY_SIZE(dra7xx_ipu_resets),
+	.main_clk	= "dpll_core_h22x2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_IPU2_IPU2_CLKCTRL_OFFSET,
+			.rstctrl_offs = DRA7XX_RM_IPU2_RSTCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_IPU2_IPU2_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
  * 'mailbox' class
  *
  */
@@ -3492,6 +3540,22 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__i2c5 = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* ipu1 -> l3_main_1 */
+static struct omap_hwmod_ocp_if dra7xx_ipu1__l3_main_1 = {
+	.master		= &dra7xx_ipu1_hwmod,
+	.slave		= &dra7xx_l3_main_1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* ipu2 -> l3_main_1 */
+static struct omap_hwmod_ocp_if dra7xx_ipu2__l3_main_1 = {
+	.master		= &dra7xx_ipu2_hwmod,
+	.slave		= &dra7xx_l3_main_1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_cfg -> mailbox1 */
 static struct omap_hwmod_ocp_if dra7xx_l4_cfg__mailbox1 = {
 	.master		= &dra7xx_l4_cfg_hwmod,
@@ -4171,6 +4235,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
 	&dra7xx_l4_per1__i2c3,
 	&dra7xx_l4_per1__i2c4,
 	&dra7xx_l4_per1__i2c5,
+	&dra7xx_ipu1__l3_main_1,
+	&dra7xx_ipu2__l3_main_1,
 	&dra7xx_l4_cfg__mailbox1,
 	&dra7xx_l4_per3__mailbox2,
 	&dra7xx_l4_per3__mailbox3,
-- 
2.13.1

[PATCH 8/8] ARM: DRA7: hwmod_data: Add data for DSPs

[Suman Anna]

The DRA7xx family of SoCs can have up to two identical DSP
processor subsystems, with most of them having a single DSP
processor subsystem. The second DSP is present only on DRA74x
and DRA76x variants currently.

These subsystems are very similar to the respective processor
subsystems on OMAP4/OMAP5 in terms of clock and reset integration.
The relevant hwmod class and data structures are added for both
the DSP remoteproc devices, with the data for DSP2 added only
on DRA74x/DRA76x variants.

Do note that these hwmod data structures do not have a .modulemode
field as the devices are managed together with their corresponding
MMUs. Each of the processor subsystem and its MMU are present within
the same clock domain and requires the domain be clocked and enabled
until the last entity is disabled. The module is disabled properly
during the omap_device_idle processing of the MMU hwmod while
disabling the MMU.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 66 +++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index e65a02855633..2a6341753c70 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -555,6 +555,53 @@ static struct omap_hwmod dra7xx_tptc1_hwmod = {
 };
 
 /*
+ * 'dsp' class
+ * dsp sub-system
+ */
+
+static struct omap_hwmod_class dra7xx_dsp_hwmod_class = {
+	.name   = "dsp",
+};
+
+static struct omap_hwmod_rst_info dra7xx_dsp_resets[] = {
+	{ .name = "dsp", .rst_shift = 0 },
+};
+
+/* dsp1 processor */
+static struct omap_hwmod dra7xx_dsp1_hwmod = {
+	.name		= "dsp1",
+	.class		= &dra7xx_dsp_hwmod_class,
+	.clkdm_name	= "dsp1_clkdm",
+	.rst_lines	= dra7xx_dsp_resets,
+	.rst_lines_cnt	= ARRAY_SIZE(dra7xx_dsp_resets),
+	.main_clk	= "dpll_dsp_m2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_DSP1_DSP1_CLKCTRL_OFFSET,
+			.rstctrl_offs = DRA7XX_RM_DSP1_RSTCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_DSP1_DSP1_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/* dsp2 processor */
+static struct omap_hwmod dra7xx_dsp2_hwmod = {
+	.name		= "dsp2",
+	.class		= &dra7xx_dsp_hwmod_class,
+	.clkdm_name	= "dsp2_clkdm",
+	.rst_lines	= dra7xx_dsp_resets,
+	.rst_lines_cnt	= ARRAY_SIZE(dra7xx_dsp_resets),
+	.main_clk	= "dpll_dsp_m2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_DSP2_DSP2_CLKCTRL_OFFSET,
+			.rstctrl_offs = DRA7XX_RM_DSP2_RSTCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_DSP2_DSP2_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
  * 'dss' class
  *
  */
@@ -3266,6 +3313,22 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__tptc1 = {
 	.user		= OCP_USER_MPU,
 };
 
+/* dsp1 -> l3_main_1 */
+static struct omap_hwmod_ocp_if dra7xx_dsp1__l3_main_1 = {
+	.master		= &dra7xx_dsp1_hwmod,
+	.slave		= &dra7xx_l3_main_1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dsp2 -> l3_main_1 */
+static struct omap_hwmod_ocp_if dra7xx_dsp2__l3_main_1 = {
+	.master		= &dra7xx_dsp2_hwmod,
+	.slave		= &dra7xx_l3_main_1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l3_main_1 -> dss */
 static struct omap_hwmod_ocp_if dra7xx_l3_main_1__dss = {
 	.master		= &dra7xx_l3_main_1_hwmod,
@@ -4215,6 +4278,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
 	&dra7xx_l3_main_1__tptc1,
 	&dra7xx_l3_main_1__dss,
 	&dra7xx_l3_main_1__dispc,
+	&dra7xx_dsp1__l3_main_1,
 	&dra7xx_l3_main_1__hdmi,
 	&dra7xx_l3_main_1__aes1,
 	&dra7xx_l3_main_1__aes2,
@@ -4326,6 +4390,7 @@ static struct omap_hwmod_ocp_if *dra76x_hwmod_ocp_ifs[] __initdata = {
 	&dra7xx_l4_per3__usb_otg_ss4,
 	&dra7xx_l3_main_1__mmu0_dsp2,
 	&dra7xx_l3_main_1__mmu1_dsp2,
+	&dra7xx_dsp2__l3_main_1,
 	NULL,
 };
 
@@ -4333,6 +4398,7 @@ static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = {
 	&dra7xx_l4_per3__usb_otg_ss4,
 	&dra7xx_l3_main_1__mmu0_dsp2,
 	&dra7xx_l3_main_1__mmu1_dsp2,
+	&dra7xx_dsp2__l3_main_1,
 	NULL,
 };
 
-- 
2.13.1

[PATCH 0/8] Add hwmod data for IPU & DSP processors/MMUs

[Suman Anna]

Tony,

On 08/21/2017 06:48 PM, Suman Anna wrote:
> Hi Tony,
> 
> The following series adds the hwmod data and the corresponding
> pdata quirks for the various MMUs associated with the IPU and DSP
> processors on DRA7xx/AM57xx SoCs. This is part 1 of the patches
> for enabling the MMUs on DRA7 SoCs (OMAP4 and OMAP5 are already
> supported on mainline) and providing a baseline for adding the
> OMAP remoteproc driver. The hwmod data for the consumers of these
> MMUs - IPU and DSP processors is also added on OMAP5 and DRA7 SoCs,
> with an update to the OMAP4 ones.
> 
> Patches are baselined on your current for-next branch with commit
> a70cb93b6c2f ("Merge branch 'omap-for-v4.14/dt-v3' into for-next").
> 
> I have tested the patches on current TI DRA7xx/AM57xx boards (DRA7,
> DRA72, DRA71, DRA76 EVMs, AM571x & AM572x IDKs and AM57xx BeagleBoard-X15)
> as well as the OMAP4 Panda and OMAP5 uEVM.

Ping on this series. Tero's clkctrl series changes are orthogonal to
these changes.

regards
Suman

> 
> regards
> Suman
> 
> Suman Anna (8):
>   ARM: DRA7: hwmod data: Add MMU data for IPUs
>   ARM: DRA7: hwmod data: Add MMU data for DSPs
>   ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 IPUs
>   ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 DSPs
>   ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods
>   ARM: OMAP5: hwmod_data: Add data for IPU & DSP processors
>   ARM: DRA7: hwmod_data: Add data for IPUs
>   ARM: DRA7: hwmod_data: Add data for DSPs
> 
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   2 -
>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  79 +++++++
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 322 +++++++++++++++++++++++++++++
>  arch/arm/mach-omap2/pdata-quirks.c         |  11 +-
>  4 files changed, 411 insertions(+), 3 deletions(-)
> 

[PATCH 0/8] Add hwmod data for IPU & DSP processors/MMUs

[Tony Lindgren]

* Suman Anna <s-anna@ti.com> [170922 10:19]:
> Ping on this series. Tero's clkctrl series changes are orthogonal to
> these changes.

With patch 5/8 you said earlier "It will still be a shared set
between the MMU and remoteproc drivers, but let me look into
how these get integrated." So was there any conclusion there?

Also, what's the deal with these omap4 changes that I commented
on in 5/8?

Regards,

Tony

[PATCH 0/8] Add hwmod data for IPU & DSP processors/MMUs

[Suman Anna]

On 09/22/2017 12:51 PM, Tony Lindgren wrote:
> * Suman Anna <s-anna@ti.com> [170922 10:19]:
>> Ping on this series. Tero's clkctrl series changes are orthogonal to
>> these changes.
> 
> With patch 5/8 you said earlier "It will still be a shared set
> between the MMU and remoteproc drivers, but let me look into
> how these get integrated." So was there any conclusion there?
> 
> Also, what's the deal with these omap4 changes that I commented
> on in 5/8?

Tony,
So, looking at code, removing modulemode on hwmod does change the
semantics as that will not plug in the clkctrl clk (_omap4_xlate_clkctrl
will return 0) into the hwmod and will fall back. So, this should make
it compatible to the existing code before adding the clkctrl dt nodes,
and Patch 5 will be good to avoid the crash when disabling the processor
nodes. That said, now that the modulemode is controlled by the
ti-clkctrl code, I would expect to get the refcounting for free due to
clk_enable() semantics if the same clkctrl clk is plugged under two
nodes (MMU and processor) and I may not need to remove the modulemode.
One of the main reasons for removing the modulemode is the lack of
refcounting on modulemode in the original code.

In anycase, I need to retest this with all of required patches from Tero
(current mainline does not yet have the clkctrl dt nodes).

Tero,
Do you have these patches rebased onto 4.14-rc1 (preferable if it is
rebased onto Tony's omap-for-v4.15/soc branch. I tried cherry-picking
from your github test branch (based on 4.13-rc3), but am running into
some L3Noc errors once I add the clkctrl dts node patch on Panda4 using NFS.

regards
Suman

[PATCH 0/8] Add hwmod data for IPU & DSP processors/MMUs

[Tony Lindgren]

* Suman Anna <s-anna@ti.com> [170922 14:08]:
> On 09/22/2017 12:51 PM, Tony Lindgren wrote:
> > * Suman Anna <s-anna@ti.com> [170922 10:19]:
> >> Ping on this series. Tero's clkctrl series changes are orthogonal to
> >> these changes.
> > 
> > With patch 5/8 you said earlier "It will still be a shared set
> > between the MMU and remoteproc drivers, but let me look into
> > how these get integrated." So was there any conclusion there?
> > 
> > Also, what's the deal with these omap4 changes that I commented
> > on in 5/8?
> 
> Tony,
> So, looking at code, removing modulemode on hwmod does change the
> semantics as that will not plug in the clkctrl clk (_omap4_xlate_clkctrl
> will return 0) into the hwmod and will fall back. So, this should make
> it compatible to the existing code before adding the clkctrl dt nodes,
> and Patch 5 will be good to avoid the crash when disabling the processor
> nodes. That said, now that the modulemode is controlled by the
> ti-clkctrl code, I would expect to get the refcounting for free due to
> clk_enable() semantics if the same clkctrl clk is plugged under two
> nodes (MMU and processor) and I may not need to remove the modulemode.
> One of the main reasons for removing the modulemode is the lack of
> refcounting on modulemode in the original code.

OK. Sounds like you can get the refcounting for free just by modifying
the dts as done for example for musb on omap4 in "[PATCH 10/10] ARM:
dts: Use ti-sysc module driver for omap4 musb" in that series. You
will need also the rest of the patches from that series naturally :)

That is as long as MMU and processor are both child devices in the
same interconnect target module.

> In anycase, I need to retest this with all of required patches from Tero
> (current mainline does not yet have the clkctrl dt nodes).

OK

> Tero,
> Do you have these patches rebased onto 4.14-rc1 (preferable if it is
> rebased onto Tony's omap-for-v4.15/soc branch. I tried cherry-picking
> from your github test branch (based on 4.13-rc3), but am running into
> some L3Noc errors once I add the clkctrl dts node patch on Panda4 using NFS.

Yeah I noticed that and emailed Tero about it. It seems to trigger
with built-in musb and DEBUG_KERNEL disabled, not sure what triggers
it. Only happens after the clkctrl nodes are added.

Regards,

Tony

[PATCH 0/8] Add hwmod data for IPU & DSP processors/MMUs

[Tero Kristo]

?
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 23/09/17 00:19, Tony Lindgren wrote:
> * Suman Anna <s-anna@ti.com> [170922 14:08]:
>> On 09/22/2017 12:51 PM, Tony Lindgren wrote:
>>> * Suman Anna <s-anna@ti.com> [170922 10:19]:
>>>> Ping on this series. Tero's clkctrl series changes are orthogonal to
>>>> these changes.
>>>
>>> With patch 5/8 you said earlier "It will still be a shared set
>>> between the MMU and remoteproc drivers, but let me look into
>>> how these get integrated." So was there any conclusion there?
>>>
>>> Also, what's the deal with these omap4 changes that I commented
>>> on in 5/8?
>>
>> Tony,
>> So, looking at code, removing modulemode on hwmod does change the
>> semantics as that will not plug in the clkctrl clk (_omap4_xlate_clkctrl
>> will return 0) into the hwmod and will fall back. So, this should make
>> it compatible to the existing code before adding the clkctrl dt nodes,
>> and Patch 5 will be good to avoid the crash when disabling the processor
>> nodes. That said, now that the modulemode is controlled by the
>> ti-clkctrl code, I would expect to get the refcounting for free due to
>> clk_enable() semantics if the same clkctrl clk is plugged under two
>> nodes (MMU and processor) and I may not need to remove the modulemode.
>> One of the main reasons for removing the modulemode is the lack of
>> refcounting on modulemode in the original code.
> 
> OK. Sounds like you can get the refcounting for free just by modifying
> the dts as done for example for musb on omap4 in "[PATCH 10/10] ARM:
> dts: Use ti-sysc module driver for omap4 musb" in that series. You
> will need also the rest of the patches from that series naturally :)
> 
> That is as long as MMU and processor are both child devices in the
> same interconnect target module.
> 
>> In anycase, I need to retest this with all of required patches from Tero
>> (current mainline does not yet have the clkctrl dt nodes).
> 
> OK
> 
>> Tero,
>> Do you have these patches rebased onto 4.14-rc1 (preferable if it is
>> rebased onto Tony's omap-for-v4.15/soc branch. I tried cherry-picking
>> from your github test branch (based on 4.13-rc3), but am running into
>> some L3Noc errors once I add the clkctrl dts node patch on Panda4 using NFS.
> 
> Yeah I noticed that and emailed Tero about it. It seems to trigger
> with built-in musb and DEBUG_KERNEL disabled, not sure what triggers
> it. Only happens after the clkctrl nodes are added.

In my tree, you can find 4.14-rc1-clkctrl-cleanup branch. It can still 
be considered WIP, as I haven't posted it publicly and am working with 
some late quirks on it.

-Tero