[PATCH] OMAP4: Extend clock data.

[PATCH] OMAP4: Extend clock data.

[Thara Gopinath]

This patch extends the OMAP4 clock data to include
various x2 clock nodes as the clock framework
skips a *2 whie calculating the dpll locked frequency.

Signed-off-by: Thara Gopinath <thara@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
---
Currently the framework is extended to include x2 nodes
only for a few clocks critical for OMAP4 DVFS. This
exercise needs to be done for most of the other post divider
clocks as and when necessary.
This patch has a checkpatch.pl warning due to the clock
data base omap44xx_clks having all the entries
exceeding 80 chars. Since this data base is auto-generated
to maintain consistency the new entries added also exceed
80 chars.

 arch/arm/mach-omap2/clock44xx_data.c |   40 +++++++++++++++++++++++++++------
 1 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index e10db7a..b66e224 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -486,14 +486,21 @@ static struct clk dpll_core_m5_ck = {
 	.set_rate	= &omap2_clksel_set_rate,
 };
 
+static struct clk dpll_core_m5x2_ck = {
+	.name		= "dpll_core_m5x2_ck",
+	.parent		= &dpll_core_m5_ck,
+	.ops		= &clkops_null,
+	.recalc		= &omap3_clkoutx2_recalc,
+};
+
 static const struct clksel div_core_div[] = {
-	{ .parent = &dpll_core_m5_ck, .rates = div2_1to2_rates },
+	{ .parent = &dpll_core_m5x2_ck, .rates = div2_1to2_rates },
 	{ .parent = NULL },
 };
 
 static struct clk div_core_ck = {
 	.name		= "div_core_ck",
-	.parent		= &dpll_core_m5_ck,
+	.parent		= &dpll_core_m5x2_ck,
 	.clksel		= div_core_div,
 	.clksel_reg	= OMAP4430_CM_CLKSEL_CORE,
 	.clksel_mask	= OMAP4430_CLKSEL_CORE_MASK,
@@ -512,13 +519,13 @@ static const struct clksel_rate div4_1to8_rates[] = {
 };
 
 static const struct clksel div_iva_hs_clk_div[] = {
-	{ .parent = &dpll_core_m5_ck, .rates = div4_1to8_rates },
+	{ .parent = &dpll_core_m5x2_ck, .rates = div4_1to8_rates },
 	{ .parent = NULL },
 };
 
 static struct clk div_iva_hs_clk = {
 	.name		= "div_iva_hs_clk",
-	.parent		= &dpll_core_m5_ck,
+	.parent		= &dpll_core_m5x2_ck,
 	.clksel		= div_iva_hs_clk_div,
 	.clksel_reg	= OMAP4430_CM_BYPCLK_DPLL_IVA,
 	.clksel_mask	= OMAP4430_CLKSEL_0_1_MASK,
@@ -530,7 +537,7 @@ static struct clk div_iva_hs_clk = {
 
 static struct clk div_mpu_hs_clk = {
 	.name		= "div_mpu_hs_clk",
-	.parent		= &dpll_core_m5_ck,
+	.parent		= &dpll_core_m5x2_ck,
 	.clksel		= div_iva_hs_clk_div,
 	.clksel_reg	= OMAP4430_CM_BYPCLK_DPLL_MPU,
 	.clksel_mask	= OMAP4430_CLKSEL_0_1_MASK,
@@ -656,6 +663,13 @@ static struct clk dpll_iva_m4_ck = {
 	.set_rate	= &omap2_clksel_set_rate,
 };
 
+static struct clk dpll_iva_m4x2_ck = {
+	.name		= "dpll_iva_m4x2_ck",
+	.parent		= &dpll_iva_m4_ck,
+	.ops		= &clkops_null,
+	.recalc		= &omap3_clkoutx2_recalc,
+};
+
 static struct clk dpll_iva_m5_ck = {
 	.name		= "dpll_iva_m5_ck",
 	.parent		= &dpll_iva_ck,
@@ -668,6 +682,13 @@ static struct clk dpll_iva_m5_ck = {
 	.set_rate	= &omap2_clksel_set_rate,
 };
 
+static struct clk dpll_iva_m5x2_ck = {
+	.name		= "dpll_iva_m5x2_ck",
+	.parent		= &dpll_iva_m5_ck,
+	.ops		= &clkops_null,
+	.recalc		= &omap3_clkoutx2_recalc,
+};
+
 /* DPLL_MPU */
 static struct dpll_data dpll_mpu_dd = {
 	.mult_div1_reg	= OMAP4430_CM_CLKSEL_DPLL_MPU,
@@ -1807,7 +1828,7 @@ static struct clk ivahd_ick = {
 	.enable_reg	= OMAP4430_CM_IVAHD_IVAHD_CLKCTRL,
 	.enable_bit	= OMAP4430_MODULEMODE_HWCTRL,
 	.clkdm_name	= "ivahd_clkdm",
-	.parent		= &dpll_iva_m5_ck,
+	.parent		= &dpll_iva_m5x2_ck,
 	.recalc		= &followparent_recalc,
 };
 
@@ -2161,7 +2182,7 @@ static struct clk sl2_ick = {
 	.enable_reg	= OMAP4430_CM_IVAHD_SL2_CLKCTRL,
 	.enable_bit	= OMAP4430_MODULEMODE_HWCTRL,
 	.clkdm_name	= "ivahd_clkdm",
-	.parent		= &dpll_iva_m5_ck,
+	.parent		= &dpll_iva_m5x2_ck,
 	.recalc		= &followparent_recalc,
 };
 
@@ -2221,7 +2242,7 @@ static struct clk tesla_ick = {
 	.enable_reg	= OMAP4430_CM_TESLA_TESLA_CLKCTRL,
 	.enable_bit	= OMAP4430_MODULEMODE_HWCTRL,
 	.clkdm_name	= "tesla_clkdm",
-	.parent		= &dpll_iva_m4_ck,
+	.parent		= &dpll_iva_m4x2_ck,
 	.recalc		= &followparent_recalc,
 };
 
@@ -2502,6 +2523,7 @@ static struct omap_clk omap44xx_clks[] = {
 	CLK(NULL,	"dpll_core_m2_ck",		&dpll_core_m2_ck,	CK_443X),
 	CLK(NULL,	"ddrphy_ck",			&ddrphy_ck,	CK_443X),
 	CLK(NULL,	"dpll_core_m5_ck",		&dpll_core_m5_ck,	CK_443X),
+	CLK(NULL,	"dpll_core_m5x2_ck",		&dpll_core_m5x2_ck,	CK_443X),
 	CLK(NULL,	"div_core_ck",			&div_core_ck,	CK_443X),
 	CLK(NULL,	"div_iva_hs_clk",		&div_iva_hs_clk,	CK_443X),
 	CLK(NULL,	"div_mpu_hs_clk",		&div_mpu_hs_clk,	CK_443X),
@@ -2513,7 +2535,9 @@ static struct omap_clk omap44xx_clks[] = {
 	CLK(NULL,	"iva_hsd_byp_clk_mux_ck",	&iva_hsd_byp_clk_mux_ck,	CK_443X),
 	CLK(NULL,	"dpll_iva_ck",			&dpll_iva_ck,	CK_443X),
 	CLK(NULL,	"dpll_iva_m4_ck",		&dpll_iva_m4_ck,	CK_443X),
+	CLK(NULL,	"dpll_iva_m4x2_ck",		&dpll_iva_m4x2_ck,	CK_443X),
 	CLK(NULL,	"dpll_iva_m5_ck",		&dpll_iva_m5_ck,	CK_443X),
+	CLK(NULL,	"dpll_iva_m5x2_ck",		&dpll_iva_m5x2_ck,	CK_443X),
 	CLK(NULL,	"dpll_mpu_ck",			&dpll_mpu_ck,	CK_443X),
 	CLK(NULL,	"dpll_mpu_m2_ck",		&dpll_mpu_m2_ck,	CK_443X),
 	CLK(NULL,	"per_hs_clk_div_ck",		&per_hs_clk_div_ck,	CK_443X),
-- 
1.7.0.4

Re: [PATCH] OMAP4: Extend clock data.

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1208 bytes --]

Hello Thara,

On Thu, 30 Sep 2010, Thara Gopinath wrote:

> This patch extends the OMAP4 clock data to include
> various x2 clock nodes as the clock framework
> skips a *2 whie calculating the dpll locked frequency.
> 
> Signed-off-by: Thara Gopinath <thara@ti.com>
> Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
> ---
> Currently the framework is extended to include x2 nodes
> only for a few clocks critical for OMAP4 DVFS. This
> exercise needs to be done for most of the other post divider
> clocks as and when necessary.

Benoît and I have been discussing this - I think we should probably fix 
this problem for all of the DPLLs and HSDIVIDERs in one patch.  I'll let 
Benoît comment further, but I think the current plan will be to generate a 
CLKOUTX2 node after the DPLLs, and then to use that as the parent for 
the various HSDIVIDERs that use that X2 output.

Also, I think we should make this change in a consistent way with regards 
to what the autogeneration scripts should generate.  This way, we won't 
have to redo it later and cause unnecessary patch noise.

Perhaps you can help Benoît update the autogeneration scripts for the 
above changes?


- Paul

Re: [PATCH] OMAP4: Extend clock data.

[Cousson, Benoit]

Hi Thara,

On 9/30/2010 10:57 AM, Paul Walmsley wrote:
> Hello Thara,
>
> On Thu, 30 Sep 2010, Thara Gopinath wrote:
>
>> This patch extends the OMAP4 clock data to include
>> various x2 clock nodes as the clock framework
>> skips a *2 whie calculating the dpll locked frequency.
>>
>> Signed-off-by: Thara Gopinath<thara@ti.com>
>> Acked-by: Kevin Hilman<khilman@deeprootsystems.com>
>> ---
>> Currently the framework is extended to include x2 nodes
>> only for a few clocks critical for OMAP4 DVFS. This
>> exercise needs to be done for most of the other post divider
>> clocks as and when necessary.
>
> Benoît and I have been discussing this - I think we should probably fix
> this problem for all of the DPLLs and HSDIVIDERs in one patch.  I'll let
> Benoît comment further, but I think the current plan will be to generate a
> CLKOUTX2 node after the DPLLs, and then to use that as the parent for
> the various HSDIVIDERs that use that X2 output.

Here is


> Also, I think we should make this change in a consistent way with regards
> to what the autogeneration scripts should generate.  This way, we won't
> have to redo it later and cause unnecessary patch noise.
>
> Perhaps you can help Benoît update the autogeneration scripts for the
> above changes?
>
>
> - Paul

--
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

Re: [PATCH] OMAP4: Extend clock data.

[Cousson, Benoit]

On 9/30/2010 11:16 AM, Cousson, Benoit wrote:
> Hi Thara,
>
> On 9/30/2010 10:57 AM, Paul Walmsley wrote:
>> Hello Thara,
>>
>> On Thu, 30 Sep 2010, Thara Gopinath wrote:
>>
>>> This patch extends the OMAP4 clock data to include
>>> various x2 clock nodes as the clock framework
>>> skips a *2 whie calculating the dpll locked frequency.
>>>
>>> Signed-off-by: Thara Gopinath<thara@ti.com>
>>> Acked-by: Kevin Hilman<khilman@deeprootsystems.com>
>>> ---
>>> Currently the framework is extended to include x2 nodes
>>> only for a few clocks critical for OMAP4 DVFS. This
>>> exercise needs to be done for most of the other post divider
>>> clocks as and when necessary.
>>
>> Benoît and I have been discussing this - I think we should probably fix
>> this problem for all of the DPLLs and HSDIVIDERs in one patch.  I'll let
>> Benoît comment further, but I think the current plan will be to generate a
>> CLKOUTX2 node after the DPLLs, and then to use that as the parent for
>> the various HSDIVIDERs that use that X2 output.
>
> Here is

That's a nice cliffhanger, isn't it? You'll have the remaining part in
a next episode...

Benoit

>> Also, I think we should make this change in a consistent way with regards
>> to what the autogeneration scripts should generate.  This way, we won't
>> have to redo it later and cause unnecessary patch noise.
>>
>> Perhaps you can help Benoît update the autogeneration scripts for the
>> above changes?
>>
>>
>> - Paul
>
> --
> 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

--
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

Re: [PATCH] OMAP4: Extend clock data.

[Cousson, Benoit]

Hi Thara,

Here is the full email...

On 9/30/2010 10:57 AM, Paul Walmsley wrote:
> Hello Thara,
>
> On Thu, 30 Sep 2010, Thara Gopinath wrote:
>
>> This patch extends the OMAP4 clock data to include
>> various x2 clock nodes as the clock framework
>> skips a *2 whie calculating the dpll locked frequency.
>>
>> Signed-off-by: Thara Gopinath<thara@ti.com>
>> Acked-by: Kevin Hilman<khilman@deeprootsystems.com>
>> ---
>> Currently the framework is extended to include x2 nodes
>> only for a few clocks critical for OMAP4 DVFS. This
>> exercise needs to be done for most of the other post divider
>> clocks as and when necessary.
>
> Benoît and I have been discussing this - I think we should probably fix
> this problem for all of the DPLLs and HSDIVIDERs in one patch.  I'll let
> Benoît comment further, but I think the current plan will be to generate a
> CLKOUTX2 node after the DPLLs, and then to use that as the parent for
> the various HSDIVIDERs that use that X2 output.

Here is the way it should look for my point of view in order to be 
closer to the HW implementation:

                              +-> /2 -> M2
                              |
                    +-> M2x2 -+------->
                    |	
  DPLL ---> DPLLx2 -+-----------------> M3 (should be M3x2)
                    |
                    +-----------------> M4 (should be M4x2)
                    |
                    +-----------------> M5 (should be M5x2)
                    |
                    +-----------------> M6 (should be M6x2)
                    |
                    +-----------------> M7 (should be M7x2)


All DPLL, except the USB one, will use the same pattern. Only the number 
of HS dividers will change.

For information, here is an extract from the ES1 DB. The HS name is
indeed not very consistent.
There is no x2 in the HS dividers name whereas it should.

      'dpll_abe': {
          'outputs': {
              'm2': 'dpll_abe_m2',
              'm2x2': 'dpll_abe_m2x2',
              'm3': 'dpll_abe_m3'},
      'dpll_core': {
          'outputs': {
              'm2': 'dpll_core_m2',
              'm3': 'dpll_core_m3',
              'm4': 'dpll_core_m4',
              'm5': 'dpll_core_m5',
              'm6': 'dpll_core_m6',
              'm7': 'dpll_core_m7'},
      'dpll_iva': {
          'outputs': {
              'm4': 'dpll_iva_m4',
              'm5': 'dpll_iva_m5'},
      'dpll_mpu': {
          'outputs': {
              'm2': 'dpll_mpu_m2'},
      'dpll_per': {
          'outputs': {
              'm2': 'dpll_per_m2',
              'm2x2': 'dpll_per_m2x2',
              'm3': 'dpll_per_m3',
              'm4': 'dpll_per_m4',
              'm5': 'dpll_per_m5',
              'm6': 'dpll_per_m6',
              'm7': 'dpll_per_m7'},
      'dpll_unipro': {
          'outputs': {
              'm2x2': 'dpll_unipro_m2x2'},
      'dpll_usb': {
          'outputs': {
              'clkdcoldo': 'dpll_usb_clkdcoldo',
              'm2': 'dpll_usb_m2'},


So we should probably rename all the m3..m7 with m3x2..m7x2 name.

> Also, I think we should make this change in a consistent way with regards
> to what the autogeneration scripts should generate.  This way, we won't
> have to redo it later and cause unnecessary patch noise.
>
> Perhaps you can help Benoît update the autogeneration scripts for the
> above changes?

You can ask Rajendra if you need some detail about the tools.

Regards,
Benoit
--
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