Patchwork [PATCHv2,11/12] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks

login
register
mail settings
Submitter Paul Walmsley
Date June 11, 2012, 12:46 a.m.
Message ID <20120611004623.20034.52760.stgit@dusk>
Download mbox | patch
Permalink /patch/164032/
State New
Headers show

Comments

Paul Walmsley - June 11, 2012, 12:46 a.m.
Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated with it.  This
patch populates some clock structure clockdomain names to resolve the
following warnings during kernel init:

omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
---
 arch/arm/mach-omap2/clock44xx_data.c |    5 +++++
 1 file changed, 5 insertions(+)
Cousson, Benoit - June 11, 2012, 4:28 p.m.
Hi Paul,

On 6/11/2012 2:46 AM, Paul Walmsley wrote:
> Until the OMAP4 code is converted to disable the use of the clock
> framework-based clockdomain enable/disable sequence, any clock used as
> a hwmod main_clk must have a clockdomain associated with it.

But why? The clock domain information is already present in every hwmod 
nodes for OMAP4.

> This
> patch populates some clock structure clockdomain names to resolve the
> following warnings during kernel init:
>
> omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
> omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
> omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
> omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Benoît Cousson <b-cousson@ti.com>
> ---
>   arch/arm/mach-omap2/clock44xx_data.c |    5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
> index 2172f66..e2b701e 100644
> --- a/arch/arm/mach-omap2/clock44xx_data.c
> +++ b/arch/arm/mach-omap2/clock44xx_data.c
> @@ -84,6 +84,7 @@ static struct clk slimbus_clk = {
>
>   static struct clk sys_32k_ck = {
>   	.name		= "sys_32k_ck",
> +	.clkdm_name	= "prm_clkdm",

In fact, neither prm_clkdm not cm_clkdm are valid clock domain on OMAP4 :-(.

I've just realized that you introduced that for 3.5, but this is wrong. 
We should not start adding some fake clock domains just because the fmwk 
is not smart enough to allow a NULL clock domain.

The clkdomain should be optional, at least for clock nodes.
There is no need to enforce the presence of the clock domain in the 
structure. We should remove the warning and test the clkdm attribute 
before de-referencing it inside the clock core code.

This is the only proper fix for that issue for my point of view.

In a period of data size reduction, adding some fake information does 
not seems to be the right approach.
Don't you think so?

Regards,
Benoit


PS: I think we should revert 6ba5a69ee92c29c2ffc814dad6ac61c4cd49090c 
(ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common) and fix the 
OMAP4 hwmod data.
Paul Walmsley - June 11, 2012, 4:59 p.m.
On Mon, 11 Jun 2012, Cousson, Benoit wrote:

> In fact, neither prm_clkdm not cm_clkdm are valid clock domain on OMAP4 
> :-(.
> 
> I've just realized that you introduced that for 3.5, but this is wrong. 
> We should not start adding some fake clock domains just because the fmwk 
> is not smart enough to allow a NULL clock domain.
> 

...

> In a period of data size reduction, adding some fake information does 
> not seems to be the right approach. Don't you think so?

No, I do not.

These clockdomains are clearly documented in both the OMAP4 TRM[1]
and the NDA OMAP4 PRCM functional specifications.

I continue to be baffled as to why you assert that they are fake, given 
how clearly they are documented.


- Paul

1. See for example sections 3.6.6.1 "Overview", Figure 3-58 "CD_L4_PER 
Overview", Figure 3-59 "CD_L3_INIT Overview", Figure 3-62 "CD_EMU 
Overview", Figure 3-63 "CD_DSS Overview", Figure 3-74 "CD_L4_ALWON_CORE 
Overview" in the OMAP4 TRM Rev. AA (SWPU231AA).
Cousson, Benoit - June 11, 2012, 8:15 p.m.
On 6/11/2012 6:59 PM, Paul Walmsley wrote:
> On Mon, 11 Jun 2012, Cousson, Benoit wrote:
>
>> In fact, neither prm_clkdm not cm_clkdm are valid clock domain on OMAP4
>> :-(.
>>
>> I've just realized that you introduced that for 3.5, but this is wrong.
>> We should not start adding some fake clock domains just because the fmwk
>> is not smart enough to allow a NULL clock domain.
>>
>
> ...
>
>> In a period of data size reduction, adding some fake information does
>> not seems to be the right approach. Don't you think so?
>
> No, I do not.
>
> These clockdomains are clearly documented in both the OMAP4 TRM[1]
> and the NDA OMAP4 PRCM functional specifications.

Sorry for the confusion; I was just referring to the prm_clkdm and cm_clkdm.

> I continue to be baffled as to why you assert that they are fake, given
> how clearly they are documented.

In that case the clock domains are valid, but that does not change the 
fact that they are useless, at least for the moment.
The PRCM is already taking care of managing properly the domains based 
on module activity. Adding that to the clocks nodes is not wrong, but 
does add an information that is a duplication of what the HW is already 
doing.
That's why we should populate that information only if this is needed, 
like it was the case for the DPLL, but it should remain optional.

Regards,
Benoit

Patch

diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index 2172f66..e2b701e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -84,6 +84,7 @@  static struct clk slimbus_clk = {
 
 static struct clk sys_32k_ck = {
 	.name		= "sys_32k_ck",
+	.clkdm_name	= "prm_clkdm",
 	.rate		= 32768,
 	.ops		= &clkops_null,
 };
@@ -512,6 +513,7 @@  static struct clk ddrphy_ck = {
 	.name		= "ddrphy_ck",
 	.parent		= &dpll_core_m2_ck,
 	.ops		= &clkops_null,
+	.clkdm_name	= "l3_emif_clkdm",
 	.fixed_div	= 2,
 	.recalc		= &omap_fixed_divisor_recalc,
 };
@@ -769,6 +771,7 @@  static const struct clksel dpll_mpu_m2_div[] = {
 static struct clk dpll_mpu_m2_ck = {
 	.name		= "dpll_mpu_m2_ck",
 	.parent		= &dpll_mpu_ck,
+	.clkdm_name	= "cm_clkdm",
 	.clksel		= dpll_mpu_m2_div,
 	.clksel_reg	= OMAP4430_CM_DIV_M2_DPLL_MPU,
 	.clksel_mask	= OMAP4430_DPLL_CLKOUT_DIV_MASK,
@@ -1149,6 +1152,7 @@  static const struct clksel l3_div_div[] = {
 static struct clk l3_div_ck = {
 	.name		= "l3_div_ck",
 	.parent		= &div_core_ck,
+	.clkdm_name	= "cm_clkdm",
 	.clksel		= l3_div_div,
 	.clksel_reg	= OMAP4430_CM_CLKSEL_CORE,
 	.clksel_mask	= OMAP4430_CLKSEL_L3_MASK,
@@ -2824,6 +2828,7 @@  static const struct clksel trace_clk_div_div[] = {
 static struct clk trace_clk_div_ck = {
 	.name		= "trace_clk_div_ck",
 	.parent		= &pmd_trace_clk_mux_ck,
+	.clkdm_name	= "emu_sys_clkdm",
 	.clksel		= trace_clk_div_div,
 	.clksel_reg	= OMAP4430_CM_EMU_DEBUGSS_CLKCTRL,
 	.clksel_mask	= OMAP4430_CLKSEL_PMD_TRACE_CLK_MASK,