[RFC PATCH 0/6] ARM: OMAP4+: hwmod: fixing omap4+ DSS hwmods

[RFC PATCH 0/6] ARM: OMAP4+: hwmod: fixing omap4+ DSS hwmods

[Tomi Valkeinen]

This is an RFC to fix the issues with boot time DSS hwmod setup.

There was an earlier series sent by Archit here:

http://www.spinics.net/lists/linux-omap/msg107700.html

This series takes different approach, and just tries to fix the issue at setup
time by making sure the DSS core hwmod is enabled when a DSS submodule hwmod is
being setup.

Quickly tested on OMAP4 Panda and OMAP5 uEVM.

 Tomi

Tomi Valkeinen (6):
  ARM: OMAP2+: hwmod: add parent_hwmod support
  ARM: OMAP5: hwmod: set DSS submodule parent hwmods
  ARM: OMAP4: hwmod: set DSS submodule parent hwmods
  ARM: OMAP4: hwmod: use MODULEMODE properly
  ARM: OMAP4: fix RFBI iclk
  ARM: dts: omap4.dtsi: remove dss_fck

 arch/arm/boot/dts/omap4.dtsi               |  2 +-
 arch/arm/boot/dts/omap44xx-clocks.dtsi     |  8 --------
 arch/arm/mach-omap2/omap_hwmod.c           | 22 ++++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod.h           |  1 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 25 ++++++++++++++++---------
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  5 +++++
 6 files changed, 45 insertions(+), 18 deletions(-)

-- 
2.1.1

[RFC PATCH 1/6] ARM: OMAP2+: hwmod: add parent_hwmod support

[Tomi Valkeinen]

Add parent_hwmod pointer to omap_hwmod. This can be set to point to a
"parent" hwmod that needs to be enabled for the "child" hwmod to work.

This is used at hwmod setup time: when doing the initial setup and
reset, first enable the parent hwmod, and after setup and reset is done,
restore the parent hwmod to postsetup_state.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c | 22 ++++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod.h |  1 +
 2 files changed, 23 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 9e91a4e7519a..6e0cac89bcfe 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2719,11 +2719,33 @@ static int __init _setup(struct omap_hwmod *oh, void *data)
 	if (oh->_state != _HWMOD_STATE_INITIALIZED)
 		return 0;
 
+	if (oh->parent_hwmod) {
+		int r;
+
+		r = _enable(oh->parent_hwmod);
+		WARN(r, "hwmod: %s: setup: failed to enable parent hwmod %s\n",
+			oh->name, oh->parent_hwmod->name);
+	}
+
 	_setup_iclk_autoidle(oh);
 
 	if (!_setup_reset(oh))
 		_setup_postsetup(oh);
 
+	if (oh->parent_hwmod) {
+		u8 postsetup_state;
+
+		postsetup_state = oh->parent_hwmod->_postsetup_state;
+
+		if (postsetup_state == _HWMOD_STATE_IDLE)
+			_idle(oh->parent_hwmod);
+		else if (postsetup_state == _HWMOD_STATE_DISABLED)
+			_shutdown(oh->parent_hwmod);
+		else if (postsetup_state != _HWMOD_STATE_ENABLED)
+			WARN(1, "hwmod: %s: unknown postsetup state %d! defaulting to enabled\n",
+			     oh->parent_hwmod->name, postsetup_state);
+	}
+
 	return 0;
 }
 
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 0f97d635ff90..7bd2b59857c2 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -676,6 +676,7 @@ struct omap_hwmod {
 	u8				_int_flags;
 	u8				_state;
 	u8				_postsetup_state;
+	struct omap_hwmod		*parent_hwmod;
 };
 
 struct omap_hwmod *omap_hwmod_lookup(const char *name);
-- 
2.1.1

Re: [RFC PATCH 1/6] ARM: OMAP2+: hwmod: add parent_hwmod support

[Archit Taneja]

Hi,

On Thu, Oct 9, 2014 at 7:33 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Add parent_hwmod pointer to omap_hwmod. This can be set to point to a
> "parent" hwmod that needs to be enabled for the "child" hwmod to work.
>
> This is used at hwmod setup time: when doing the initial setup and
> reset, first enable the parent hwmod, and after setup and reset is done,
> restore the parent hwmod to postsetup_state.
>

This method is better. It's less intrusive and only takes place at setup time.

Reviewed-by: Archit Taneja <archit.taneja@gmail.com>

Re: [RFC PATCH 1/6] ARM: OMAP2+: hwmod: add parent_hwmod support

[Paul Walmsley]

Hi

On Thu, 9 Oct 2014, Tomi Valkeinen wrote:

> Add parent_hwmod pointer to omap_hwmod. This can be set to point to a
> "parent" hwmod that needs to be enabled for the "child" hwmod to work.
> 
> This is used at hwmod setup time: when doing the initial setup and
> reset, first enable the parent hwmod, and after setup and reset is done,
> restore the parent hwmod to postsetup_state.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

This one has been updated here to add some kerneldoc documentation.  
Please let me know if you have any objections.


- Paul

From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Thu, 9 Oct 2014 17:03:14 +0300
Subject: [PATCH] ARM: OMAP2+: hwmod: add parent_hwmod support

Add parent_hwmod pointer to omap_hwmod. This can be set to point to a
"parent" hwmod that needs to be enabled for the "child" hwmod to work.

This is used at hwmod setup time: when doing the initial setup and
reset, first enable the parent hwmod, and after setup and reset is done,
restore the parent hwmod to postsetup_state.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit.taneja@gmail.com>
[paul@pwsan.com: add kerneldoc documentation for parent_hwmod; note that it
 is a temporary workaround]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/omap_hwmod.c | 22 ++++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod.h |  8 ++++++++
 2 files changed, 30 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index acae6d5d1151..a2c7b300fe89 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2719,11 +2719,33 @@ static int __init _setup(struct omap_hwmod *oh, void *data)
 	if (oh->_state != _HWMOD_STATE_INITIALIZED)
 		return 0;
 
+	if (oh->parent_hwmod) {
+		int r;
+
+		r = _enable(oh->parent_hwmod);
+		WARN(r, "hwmod: %s: setup: failed to enable parent hwmod %s\n",
+		     oh->name, oh->parent_hwmod->name);
+	}
+
 	_setup_iclk_autoidle(oh);
 
 	if (!_setup_reset(oh))
 		_setup_postsetup(oh);
 
+	if (oh->parent_hwmod) {
+		u8 postsetup_state;
+
+		postsetup_state = oh->parent_hwmod->_postsetup_state;
+
+		if (postsetup_state == _HWMOD_STATE_IDLE)
+			_idle(oh->parent_hwmod);
+		else if (postsetup_state == _HWMOD_STATE_DISABLED)
+			_shutdown(oh->parent_hwmod);
+		else if (postsetup_state != _HWMOD_STATE_ENABLED)
+			WARN(1, "hwmod: %s: unknown postsetup state %d! defaulting to enabled\n",
+			     oh->parent_hwmod->name, postsetup_state);
+	}
+
 	return 0;
 }
 
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 512f809a3f4d..35ca6efbec31 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -633,6 +633,7 @@ struct omap_hwmod_link {
  * @flags: hwmod flags (documented below)
  * @_lock: spinlock serializing operations on this hwmod
  * @node: list node for hwmod list (internal use)
+ * @parent_hwmod: (temporary) a pointer to the hierarchical parent of this hwmod
  *
  * @main_clk refers to this module's "main clock," which for our
  * purposes is defined as "the functional clock needed for register
@@ -643,6 +644,12 @@ struct omap_hwmod_link {
  * the omap_hwmod code and should not be set during initialization.
  *
  * @masters and @slaves are now deprecated.
+ *
+ * @parent_hwmod is temporary; there should be no need for it, as this
+ * information should already be expressed in the OCP interface
+ * structures.  @parent_hwmod is present as a workaround until we improve
+ * handling for hwmods with multiple parents (e.g., OMAP4+ DSS with
+ * multiple register targets across different interconnects).
  */
 struct omap_hwmod {
 	const char			*name;
@@ -680,6 +687,7 @@ struct omap_hwmod {
 	u8				_int_flags;
 	u8				_state;
 	u8				_postsetup_state;
+	struct omap_hwmod		*parent_hwmod;
 };
 
 struct omap_hwmod *omap_hwmod_lookup(const char *name);
-- 
2.1.3

Re: [RFC PATCH 1/6] ARM: OMAP2+: hwmod: add parent_hwmod support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

Hi Paul,

On 20/11/14 09:03, Paul Walmsley wrote:
> Hi
> 
> On Thu, 9 Oct 2014, Tomi Valkeinen wrote:
> 
>> Add parent_hwmod pointer to omap_hwmod. This can be set to point to a
>> "parent" hwmod that needs to be enabled for the "child" hwmod to work.
>>
>> This is used at hwmod setup time: when doing the initial setup and
>> reset, first enable the parent hwmod, and after setup and reset is done,
>> restore the parent hwmod to postsetup_state.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> 
> This one has been updated here to add some kerneldoc documentation.  
> Please let me know if you have any objections.

Thanks, looks good to me. Sorry I missed adding the kernel doc.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[RFC PATCH 2/6] ARM: OMAP5: hwmod: set DSS submodule parent hwmods

[Tomi Valkeinen]

Set DSS core hwmod as the parent for all the DSS submodules.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 1103aa0e0d29..229c7fb7e1c3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -421,6 +421,7 @@ static struct omap_hwmod omap54xx_dss_dispc_hwmod = {
 	.opt_clks	= dss_dispc_opt_clks,
 	.opt_clks_cnt	= ARRAY_SIZE(dss_dispc_opt_clks),
 	.dev_attr	= &dss_dispc_dev_attr,
+	.parent_hwmod	= &omap54xx_dss_hwmod,
 };
 
 /*
@@ -462,6 +463,7 @@ static struct omap_hwmod omap54xx_dss_dsi1_a_hwmod = {
 	},
 	.opt_clks	= dss_dsi1_a_opt_clks,
 	.opt_clks_cnt	= ARRAY_SIZE(dss_dsi1_a_opt_clks),
+	.parent_hwmod	= &omap54xx_dss_hwmod,
 };
 
 /* dss_dsi1_c */
@@ -482,6 +484,7 @@ static struct omap_hwmod omap54xx_dss_dsi1_c_hwmod = {
 	},
 	.opt_clks	= dss_dsi1_c_opt_clks,
 	.opt_clks_cnt	= ARRAY_SIZE(dss_dsi1_c_opt_clks),
+	.parent_hwmod	= &omap54xx_dss_hwmod,
 };
 
 /*
@@ -521,6 +524,7 @@ static struct omap_hwmod omap54xx_dss_hdmi_hwmod = {
 	},
 	.opt_clks	= dss_hdmi_opt_clks,
 	.opt_clks_cnt	= ARRAY_SIZE(dss_hdmi_opt_clks),
+	.parent_hwmod	= &omap54xx_dss_hwmod,
 };
 
 /*
@@ -560,6 +564,7 @@ static struct omap_hwmod omap54xx_dss_rfbi_hwmod = {
 	},
 	.opt_clks	= dss_rfbi_opt_clks,
 	.opt_clks_cnt	= ARRAY_SIZE(dss_rfbi_opt_clks),
+	.parent_hwmod	= &omap54xx_dss_hwmod,
 };
 
 /*
-- 
2.1.1

[RFC PATCH 3/6] ARM: OMAP4: hwmod: set DSS submodule parent hwmods

[Tomi Valkeinen]

Set DSS core hwmod as the parent for all the DSS submodules.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 44e5634bba34..df8dc0f6530f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -647,7 +647,8 @@ static struct omap_hwmod omap44xx_dss_dispc_hwmod = {
 			.context_offs = OMAP4_RM_DSS_DSS_CONTEXT_OFFSET,
 		},
 	},
-	.dev_attr	= &omap44xx_dss_dispc_dev_attr
+	.dev_attr	= &omap44xx_dss_dispc_dev_attr,
+	.parent_hwmod	= &omap44xx_dss_hwmod,
 };
 
 /*
@@ -701,6 +702,7 @@ static struct omap_hwmod omap44xx_dss_dsi1_hwmod = {
 	},
 	.opt_clks	= dss_dsi1_opt_clks,
 	.opt_clks_cnt	= ARRAY_SIZE(dss_dsi1_opt_clks),
+	.parent_hwmod	= &omap44xx_dss_hwmod,
 };
 
 /* dss_dsi2 */
@@ -733,6 +735,7 @@ static struct omap_hwmod omap44xx_dss_dsi2_hwmod = {
 	},
 	.opt_clks	= dss_dsi2_opt_clks,
 	.opt_clks_cnt	= ARRAY_SIZE(dss_dsi2_opt_clks),
+	.parent_hwmod	= &omap44xx_dss_hwmod,
 };
 
 /*
@@ -790,6 +793,7 @@ static struct omap_hwmod omap44xx_dss_hdmi_hwmod = {
 	},
 	.opt_clks	= dss_hdmi_opt_clks,
 	.opt_clks_cnt	= ARRAY_SIZE(dss_hdmi_opt_clks),
+	.parent_hwmod	= &omap44xx_dss_hwmod,
 };
 
 /*
@@ -836,6 +840,7 @@ static struct omap_hwmod omap44xx_dss_rfbi_hwmod = {
 	},
 	.opt_clks	= dss_rfbi_opt_clks,
 	.opt_clks_cnt	= ARRAY_SIZE(dss_rfbi_opt_clks),
+	.parent_hwmod	= &omap44xx_dss_hwmod,
 };
 
 /*
@@ -859,6 +864,7 @@ static struct omap_hwmod omap44xx_dss_venc_hwmod = {
 			.context_offs = OMAP4_RM_DSS_DSS_CONTEXT_OFFSET,
 		},
 	},
+	.parent_hwmod	= &omap44xx_dss_hwmod,
 };
 
 /*
-- 
2.1.1

[RFC PATCH 4/6] ARM: OMAP4: hwmod: use MODULEMODE properly

[Tomi Valkeinen]

Instead of using a hacky "dss_fck" clock (which toggles the MODULEMODE
bit) as DSS L3 interface clock, set the .modulemode field in the
omap44xx_dss_hwmod. This works now that the DSS core hwmod is enabled
during DSS submodule resets.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index df8dc0f6530f..8126f178d57e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -589,6 +589,7 @@ static struct omap_hwmod omap44xx_dss_hwmod = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_DSS_DSS_CLKCTRL_OFFSET,
 			.context_offs = OMAP4_RM_DSS_DSS_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
 		},
 	},
 	.opt_clks	= dss_opt_clks,
@@ -3677,7 +3678,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_dma_addrs[] = {
 static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss = {
 	.master		= &omap44xx_l3_main_2_hwmod,
 	.slave		= &omap44xx_dss_hwmod,
-	.clk		= "dss_fck",
+	.clk		= "l3_div_ck",
 	.addr		= omap44xx_dss_dma_addrs,
 	.user		= OCP_USER_SDMA,
 };
@@ -3713,7 +3714,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_dispc_dma_addrs[] = {
 static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_dispc = {
 	.master		= &omap44xx_l3_main_2_hwmod,
 	.slave		= &omap44xx_dss_dispc_hwmod,
-	.clk		= "dss_fck",
+	.clk		= "l3_div_ck",
 	.addr		= omap44xx_dss_dispc_dma_addrs,
 	.user		= OCP_USER_SDMA,
 };
@@ -3749,7 +3750,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_dsi1_dma_addrs[] = {
 static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_dsi1 = {
 	.master		= &omap44xx_l3_main_2_hwmod,
 	.slave		= &omap44xx_dss_dsi1_hwmod,
-	.clk		= "dss_fck",
+	.clk		= "l3_div_ck",
 	.addr		= omap44xx_dss_dsi1_dma_addrs,
 	.user		= OCP_USER_SDMA,
 };
@@ -3785,7 +3786,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_dsi2_dma_addrs[] = {
 static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_dsi2 = {
 	.master		= &omap44xx_l3_main_2_hwmod,
 	.slave		= &omap44xx_dss_dsi2_hwmod,
-	.clk		= "dss_fck",
+	.clk		= "l3_div_ck",
 	.addr		= omap44xx_dss_dsi2_dma_addrs,
 	.user		= OCP_USER_SDMA,
 };
@@ -3821,7 +3822,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_hdmi_dma_addrs[] = {
 static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_hdmi = {
 	.master		= &omap44xx_l3_main_2_hwmod,
 	.slave		= &omap44xx_dss_hdmi_hwmod,
-	.clk		= "dss_fck",
+	.clk		= "l3_div_ck",
 	.addr		= omap44xx_dss_hdmi_dma_addrs,
 	.user		= OCP_USER_SDMA,
 };
@@ -3857,7 +3858,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_rfbi_dma_addrs[] = {
 static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_rfbi = {
 	.master		= &omap44xx_l3_main_2_hwmod,
 	.slave		= &omap44xx_dss_rfbi_hwmod,
-	.clk		= "dss_fck",
+	.clk		= "l3_div_ck",
 	.addr		= omap44xx_dss_rfbi_dma_addrs,
 	.user		= OCP_USER_SDMA,
 };
@@ -3893,7 +3894,7 @@ static struct omap_hwmod_addr_space omap44xx_dss_venc_dma_addrs[] = {
 static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_venc = {
 	.master		= &omap44xx_l3_main_2_hwmod,
 	.slave		= &omap44xx_dss_venc_hwmod,
-	.clk		= "dss_fck",
+	.clk		= "l3_div_ck",
 	.addr		= omap44xx_dss_venc_dma_addrs,
 	.user		= OCP_USER_SDMA,
 };
-- 
2.1.1

[RFC PATCH 5/6] ARM: OMAP4: fix RFBI iclk

[Tomi Valkeinen]

RFBI iclk was set to point to hacky "dss_fck", which will be removed.
Instead use "l3_div_ck", which is the proper clock for this. "l3_div_ck"
is the parent of "dss_fck", so the clock rate is the same as previously.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/boot/dts/omap4.dtsi               | 2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 69408b53200d..4c15409a9056 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -880,7 +880,7 @@
 				reg = <0x58002000 0x1000>;
 				status = "disabled";
 				ti,hwmods = "dss_rfbi";
-				clocks = <&dss_dss_clk>, <&dss_fck>;
+				clocks = <&dss_dss_clk>, <&l3_div_ck>;
 				clock-names = "fck", "ick";
 			};
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 8126f178d57e..d6f41e1b6d1b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -824,7 +824,7 @@ static struct omap_hwmod_dma_info omap44xx_dss_rfbi_sdma_reqs[] = {
 };
 
 static struct omap_hwmod_opt_clk dss_rfbi_opt_clks[] = {
-	{ .role = "ick", .clk = "dss_fck" },
+	{ .role = "ick", .clk = "l3_div_ck" },
 };
 
 static struct omap_hwmod omap44xx_dss_rfbi_hwmod = {
-- 
2.1.1

[RFC PATCH 6/6] ARM: dts: omap4.dtsi: remove dss_fck

[Tomi Valkeinen]

"dss_fck" is a hacky clock, used to work around problems with MODULEMODE
bit handling in DSS hwmods.

These problems have now been solved, so we can remove the dss_fck clock.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/boot/dts/omap44xx-clocks.dtsi | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/boot/dts/omap44xx-clocks.dtsi b/arch/arm/boot/dts/omap44xx-clocks.dtsi
index c821ff5e9b8d..f2c48f09824e 100644
--- a/arch/arm/boot/dts/omap44xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap44xx-clocks.dtsi
@@ -1018,14 +1018,6 @@
 		reg = <0x1120>;
 	};
 
-	dss_fck: dss_fck {
-		#clock-cells = <0>;
-		compatible = "ti,gate-clock";
-		clocks = <&l3_div_ck>;
-		ti,bit-shift = <1>;
-		reg = <0x1120>;
-	};
-
 	fdif_fck: fdif_fck {
 		#clock-cells = <0>;
 		compatible = "ti,divider-clock";
-- 
2.1.1

Re: [RFC PATCH 0/6] ARM: OMAP4+: hwmod: fixing omap4+ DSS hwmods

[Archit Taneja]

On Thu, Oct 9, 2014 at 7:33 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> This is an RFC to fix the issues with boot time DSS hwmod setup.
>
> There was an earlier series sent by Archit here:
>
> http://www.spinics.net/lists/linux-omap/msg107700.html
>
> This series takes different approach, and just tries to fix the issue at setup
> time by making sure the DSS core hwmod is enabled when a DSS submodule hwmod is
> being setup.
>
> Quickly tested on OMAP4 Panda and OMAP5 uEVM.

The series looks good to me.

Reviewed-by: Archit Taneja <archit.taneja@gmail.com>

Archit

Re: [RFC PATCH 0/6] ARM: OMAP4+: hwmod: fixing omap4+ DSS hwmods

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

Hi Paul,

On 09/10/14 17:03, Tomi Valkeinen wrote:
> This is an RFC to fix the issues with boot time DSS hwmod setup.
> 
> There was an earlier series sent by Archit here:
> 
> http://www.spinics.net/lists/linux-omap/msg107700.html
> 
> This series takes different approach, and just tries to fix the issue at setup
> time by making sure the DSS core hwmod is enabled when a DSS submodule hwmod is
> being setup.
> 
> Quickly tested on OMAP4 Panda and OMAP5 uEVM.
> 
>  Tomi
> 
> Tomi Valkeinen (6):
>   ARM: OMAP2+: hwmod: add parent_hwmod support
>   ARM: OMAP5: hwmod: set DSS submodule parent hwmods
>   ARM: OMAP4: hwmod: set DSS submodule parent hwmods
>   ARM: OMAP4: hwmod: use MODULEMODE properly
>   ARM: OMAP4: fix RFBI iclk
>   ARM: dts: omap4.dtsi: remove dss_fck
> 
>  arch/arm/boot/dts/omap4.dtsi               |  2 +-
>  arch/arm/boot/dts/omap44xx-clocks.dtsi     |  8 --------
>  arch/arm/mach-omap2/omap_hwmod.c           | 22 ++++++++++++++++++++++
>  arch/arm/mach-omap2/omap_hwmod.h           |  1 +
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 25 ++++++++++++++++---------
>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  5 +++++
>  6 files changed, 45 insertions(+), 18 deletions(-)
> 

Ping. Would this series be acceptable?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC PATCH 0/6] ARM: OMAP4+: hwmod: fixing omap4+ DSS hwmods

[Paul Walmsley]

Hi Tomi,

thanks for the ping.

On Fri, 14 Nov 2014, Tomi Valkeinen wrote:

> On 09/10/14 17:03, Tomi Valkeinen wrote:
> > This is an RFC to fix the issues with boot time DSS hwmod setup.
> > 
> > There was an earlier series sent by Archit here:
> > 
> > http://www.spinics.net/lists/linux-omap/msg107700.html
> > 
> > This series takes different approach, and just tries to fix the issue at setup
> > time by making sure the DSS core hwmod is enabled when a DSS submodule hwmod is
> > being setup.
> > 
> > Quickly tested on OMAP4 Panda and OMAP5 uEVM.
> > 
> >  Tomi
> > 
> > Tomi Valkeinen (6):
> >   ARM: OMAP2+: hwmod: add parent_hwmod support
> >   ARM: OMAP5: hwmod: set DSS submodule parent hwmods
> >   ARM: OMAP4: hwmod: set DSS submodule parent hwmods
> >   ARM: OMAP4: hwmod: use MODULEMODE properly
> >   ARM: OMAP4: fix RFBI iclk
> >   ARM: dts: omap4.dtsi: remove dss_fck
> > 
> >  arch/arm/boot/dts/omap4.dtsi               |  2 +-
> >  arch/arm/boot/dts/omap44xx-clocks.dtsi     |  8 --------
> >  arch/arm/mach-omap2/omap_hwmod.c           | 22 ++++++++++++++++++++++
> >  arch/arm/mach-omap2/omap_hwmod.h           |  1 +
> >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 25 ++++++++++++++++---------
> >  arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  5 +++++
> >  6 files changed, 45 insertions(+), 18 deletions(-)
> > 
> 
> Ping. Would this series be acceptable?

Yes, it looks good for the short term, and definitely moves us closer to 
where we should be.  

Queued with Archit's Reviewed-by:, with some extra documentation added to 
the first patch.  If you have a spare moment, could you take a quick look 
at it?  It should not result in any functional changes.

In theory, that .parent_hwmod information should come from the 
omap_hwmod_ocp_if data.  But as you know, unfortunately due to some 
limitations in the hwmod code, we don't handle IP blocks with multiple 
interconnect parents very well right now.  Ultimately we should only have 
one "OCP" interface between each of the DSS IP blocks.  But for that to 
work, the physical address code needs to be overhauled, and the data 
should be specified as offsets rather than absolute addresses.  One of 
these days.


- Paul