OMAP: OMAP3 DSS related clock patches

clk-divider.c does not calculate the rates consistently at the moment.

As an example, on OMAP3 we have a clock divider with a source clock of 864000000 Hz. With dividers 6, 7 and 8 the theoretical rates are:

6: 144000000
7: 123428571.428571...
8: 108000000

Calling clk_round_rate() with the rate in the first column will give the rate in the second column:

144000000 -> 144000000
143999999 -> 123428571
123428572 -> 123428571
123428571 -> 108000000

Note how clk_round_rate() returns 123428571 for rates from 123428572 to 143999999, which is mathematically correct, but when clk_round_rate() is called with 123428571, the returned value is surprisingly 108000000.

This means that the following code works a bit oddly:

rate = clk_round_rate(clk, 123428572);
clk_set_rate(clk, rate);

As clk_set_rate() also does clock rate rounding, the result is that the clock is set to the rate of 108000000, not 123428571 returned by the clk_round_rate.

This patch changes the clk-divider.c to use DIV_ROUND_UP when calculating the rate. This gives the following behavior which fixes the inconsistency:

144000000 -> 144000000
143999999 -> 123428572
123428572 -> 123428572
123428571 -> 108000000

Signed-off-by Tomi Valkeinen <[email protected]>

Cc Mike Turquette <[email protected]>

---
  drivers/clk/clk-divider.c | 10 +++++-----
  1 file changed, 5 insertions(+), 5 deletions(-)

drivers/clk/clk-divider.c +4 -4

index 5543b7df8e16..ec22112e569f 100644
@@ -24,7 +24,7 @@
   * Traits of this clock:
   * prepare - clk_prepare only ensures that parents are prepared
   * enable - clk_enable only ensures that parents are enabled
- * rate - rate is adjustable.  clk->rate = parent->rate / divisor
+ * rate - rate is adjustable.  clk->rate = DIV_ROUND_UP(parent->rate / divisor)
   * parent - fixed parent.  No clk_set_parent support
   */
 

@@ -115,7 +115,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
  		return parent_rate;
  	}
 
-	return parent_rate / div;
+	return DIV_ROUND_UP(parent_rate, div);
  }
 
  /*

@@ -185,7 +185,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
  		}
  		parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
  				MULT_ROUND_UP(rate, i));
-		now = parent_rate / i;
+		now = DIV_ROUND_UP(parent_rate, i);
  		if (now <= rate && now > best) {
  			bestdiv = i;
  			best = now;

@@ -207,7 +207,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
  	int div;
  	div = clk_divider_bestdiv(hw, rate, prate);
 
-	return *prate / div;
+	return DIV_ROUND_UP(*prate, div);
  }
 
  static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,

Quoted 93 lines

clk-divider.c does not calculate the rates consistently at the moment.

As an example, on OMAP3 we have a clock divider with a source clock of 864000000 Hz. With dividers 6, 7 and 8 the theoretical rates are:

6: 144000000
7: 123428571.428571...
8: 108000000

Calling clk_round_rate() with the rate in the first column will give the rate in the second column:

144000000 -> 144000000
143999999 -> 123428571
123428572 -> 123428571
123428571 -> 108000000

Note how clk_round_rate() returns 123428571 for rates from 123428572 to 143999999, which is mathematically correct, but when clk_round_rate() is called with 123428571, the returned value is surprisingly 108000000.

This means that the following code works a bit oddly:

rate = clk_round_rate(clk, 123428572);
clk_set_rate(clk, rate);

As clk_set_rate() also does clock rate rounding, the result is that the clock is set to the rate of 108000000, not 123428571 returned by the clk_round_rate.

This patch changes the clk-divider.c to use DIV_ROUND_UP when calculating the rate. This gives the following behavior which fixes the inconsistency:

144000000 -> 144000000
143999999 -> 123428572
123428572 -> 123428572
123428571 -> 108000000

Signed-off-by Tomi Valkeinen <[email protected]>

Cc Mike Turquette <[email protected]>

---
  drivers/clk/clk-divider.c | 10 +++++-----
  1 file changed, 5 insertions(+), 5 deletions(-)

drivers/clk/clk-divider.c +5 -5

index 5543b7df8e16..ec22112e569f 100644
@@ -24,7 +24,7 @@
   * Traits of this clock:
   * prepare - clk_prepare only ensures that parents are prepared
   * enable - clk_enable only ensures that parents are enabled
- * rate - rate is adjustable.  clk->rate = parent->rate / divisor
+ * rate - rate is adjustable.  clk->rate = DIV_ROUND_UP(parent->rate / divisor)
   * parent - fixed parent.  No clk_set_parent support
   */
 

@@ -115,7 +115,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
              return parent_rate;
      }
 
-     return parent_rate / div;
+     return DIV_ROUND_UP(parent_rate, div);
  }
 
  /*

@@ -185,7 +185,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
              }
              parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
                              MULT_ROUND_UP(rate, i));
-             now = parent_rate / i;
+             now = DIV_ROUND_UP(parent_rate, i);
              if (now <= rate && now > best) {
                      bestdiv = i;
                      best = now;

@@ -207,7 +207,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
      int div;
      div = clk_divider_bestdiv(hw, rate, prate);
 
-     return *prate / div;
+     return DIV_ROUND_UP(*prate, div);
  }
 
  static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,

@@ -218,7 +218,7 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
      unsigned long flags = 0;
      u32 val;
 
-     div = parent_rate / rate;
+     div = DIV_ROUND_UP(parent_rate, rate);
      value = _get_val(divider, div);
 

drivers/clk/clk-divider.c static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate, · line 224

Quoted 2 lines

drivers/clk/clk-divider.c +0 -0

      if (value > div_mask(divider))

Basically the patch looks good to me, but it might be good to have a testing round of sort with this. It can potentially cause regressions on multiple boards if the drivers happen to rely on the "broken" clock rates. Same for patch #2 which is a copy paste of this one, but only impacts TI boards.

-Tero

Quoted 5 lines

Basically the patch looks good to me, but it might be good to have a testing round of sort with this. It can potentially cause regressions on multiple boards if the drivers happen to rely on the "broken" clock rates. Same for patch #2 which is a copy paste of this one, but only impacts TI boards.

Agreed. I've taken patches #1 & #2 into clk-next. Let's let them stew in -next for a while and see if anyone's board catches on fire.

Quoting Tero Kristo (2014-02-14 05:45:22)

Quoted 94 lines · Tomi Valkeinen

Quoted 93 lines

clk-divider.c does not calculate the rates consistently at the moment.

As an example, on OMAP3 we have a clock divider with a source clock of 864000000 Hz. With dividers 6, 7 and 8 the theoretical rates are:

6: 144000000
7: 123428571.428571...
8: 108000000

Calling clk_round_rate() with the rate in the first column will give the rate in the second column:

144000000 -> 144000000
143999999 -> 123428571
123428572 -> 123428571
123428571 -> 108000000

Note how clk_round_rate() returns 123428571 for rates from 123428572 to 143999999, which is mathematically correct, but when clk_round_rate() is called with 123428571, the returned value is surprisingly 108000000.

This means that the following code works a bit oddly:

rate = clk_round_rate(clk, 123428572);
clk_set_rate(clk, rate);

As clk_set_rate() also does clock rate rounding, the result is that the clock is set to the rate of 108000000, not 123428571 returned by the clk_round_rate.

This patch changes the clk-divider.c to use DIV_ROUND_UP when calculating the rate. This gives the following behavior which fixes the inconsistency:

144000000 -> 144000000
143999999 -> 123428572
123428572 -> 123428572
123428571 -> 108000000

Signed-off-by Tomi Valkeinen <[email protected]>

Cc Mike Turquette <[email protected]>

---
  drivers/clk/clk-divider.c | 10 +++++-----
  1 file changed, 5 insertions(+), 5 deletions(-)

drivers/clk/clk-divider.c +5 -5

index 5543b7df8e16..ec22112e569f 100644
@@ -24,7 +24,7 @@
   * Traits of this clock:
   * prepare - clk_prepare only ensures that parents are prepared
   * enable - clk_enable only ensures that parents are enabled
- * rate - rate is adjustable.  clk->rate = parent->rate / divisor
+ * rate - rate is adjustable.  clk->rate = DIV_ROUND_UP(parent->rate / divisor)
   * parent - fixed parent.  No clk_set_parent support
   */
 

@@ -115,7 +115,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
              return parent_rate;
      }
 
-     return parent_rate / div;
+     return DIV_ROUND_UP(parent_rate, div);
  }
 
  /*

@@ -185,7 +185,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
              }
              parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
                              MULT_ROUND_UP(rate, i));
-             now = parent_rate / i;
+             now = DIV_ROUND_UP(parent_rate, i);
              if (now <= rate && now > best) {
                      bestdiv = i;
                      best = now;

@@ -207,7 +207,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
      int div;
      div = clk_divider_bestdiv(hw, rate, prate);
 
-     return *prate / div;
+     return DIV_ROUND_UP(*prate, div);
  }
 
  static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,

@@ -218,7 +218,7 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
      unsigned long flags = 0;
      u32 val;
 
-     div = parent_rate / rate;
+     div = DIV_ROUND_UP(parent_rate, rate);
      value = _get_val(divider, div);
 

Quoted 8 lines

drivers/clk/clk-divider.c static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate, · line 224

Quoted 2 lines

drivers/clk/clk-divider.c +0 -0

      if (value > div_mask(divider))

Basically the patch looks good to me, but it might be good to have a testing round of sort with this. It can potentially cause regressions on multiple boards if the drivers happen to rely on the "broken" clock rates. Same for patch #2 which is a copy paste of this one, but only impacts TI boards.

Agreed. I've taken patches #1 & #2 into clk-next. Let's let them stew in -next for a while and see if anyone's board catches on fire.

Quoted 104 lines

Quoting Tero Kristo (2014-02-14 05:45:22)

Quoted 102 lines · Tomi Valkeinen

Quoted 87 lines

clk-divider.c does not calculate the rates consistently at the moment.

As an example, on OMAP3 we have a clock divider with a source clock of 864000000 Hz. With dividers 6, 7 and 8 the theoretical rates are:

6: 144000000
7: 123428571.428571...
8: 108000000

Calling clk_round_rate() with the rate in the first column will give the rate in the second column:

144000000 -> 144000000
143999999 -> 123428571
123428572 -> 123428571
123428571 -> 108000000

Note how clk_round_rate() returns 123428571 for rates from 123428572 to 143999999, which is mathematically correct, but when clk_round_rate() is called with 123428571, the returned value is surprisingly 108000000.

This means that the following code works a bit oddly:

rate = clk_round_rate(clk, 123428572);
clk_set_rate(clk, rate);

As clk_set_rate() also does clock rate rounding, the result is that the clock is set to the rate of 108000000, not 123428571 returned by the clk_round_rate.

This patch changes the clk-divider.c to use DIV_ROUND_UP when calculating the rate. This gives the following behavior which fixes the inconsistency:

144000000 -> 144000000
143999999 -> 123428572
123428572 -> 123428572
123428571 -> 108000000

Signed-off-by Tomi Valkeinen <[email protected]>

Cc Mike Turquette <[email protected]>

---
  drivers/clk/clk-divider.c | 10 +++++-----
  1 file changed, 5 insertions(+), 5 deletions(-)

drivers/clk/clk-divider.c +4 -4

index 5543b7df8e16..ec22112e569f 100644
@@ -24,7 +24,7 @@
   * Traits of this clock:
   * prepare - clk_prepare only ensures that parents are prepared
   * enable - clk_enable only ensures that parents are enabled
- * rate - rate is adjustable.  clk->rate = parent->rate / divisor
+ * rate - rate is adjustable.  clk->rate = DIV_ROUND_UP(parent->rate / divisor)
   * parent - fixed parent.  No clk_set_parent support
   */
 

@@ -115,7 +115,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
              return parent_rate;
      }
 
-     return parent_rate / div;
+     return DIV_ROUND_UP(parent_rate, div);
  }
 
  /*

@@ -185,7 +185,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
              }
              parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
                              MULT_ROUND_UP(rate, i));
-             now = parent_rate / i;
+             now = DIV_ROUND_UP(parent_rate, i);
              if (now <= rate && now > best) {
                      bestdiv = i;
                      best = now;

@@ -207,7 +207,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
      int div;
      div = clk_divider_bestdiv(hw, rate, prate);
 
-     return *prate / div;
+     return DIV_ROUND_UP(*prate, div);
  }
 
  static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,

drivers/clk/clk-divider.c static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate, · line 224

Quoted 8 lines

drivers/clk/clk-divider.c +1 -1

@@ -218,7 +218,7 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
      unsigned long flags = 0;
      u32 val;
 
-     div = parent_rate / rate;
+     div = DIV_ROUND_UP(parent_rate, rate);
      value = _get_val(divider, div);
 
      if (value > div_mask(divider))

Basically the patch looks good to me, but it might be good to have a testing round of sort with this. It can potentially cause regressions on multiple boards if the drivers happen to rely on the "broken" clock rates. Same for patch #2 which is a copy paste of this one, but only impacts TI boards.

Quoted 2 lines

Agreed. I've taken patches #1 & #2 into clk-next. Let's let them stew in -next for a while and see if anyone's board catches on fire.

Are these on the way to 3.15?

Tomi

If CLK_SET_RATE_PARENT is set for a clkoutx2 clock, calling clk_set_rate() on the clock "skips" the x2 multiplier as there are no set_rate and round_rate functions defined for the clkoutx2.

This results in getting double the requested clock rates, breaking the display on omap3430 based devices.

This patch implements set_rate and round_rate for clkoutx2.

Signed-off-by Tomi Valkeinen <[email protected]>

---
 arch/arm/mach-omap2/cclock3xxx_data.c |  2 ++
 arch/arm/mach-omap2/dpll3xxx.c        | 62 +++++++++++++++++++++++++++++++++++
 include/linux/clk/ti.h                |  4 +++
 3 files changed, 68 insertions(+)

From 0d46054a8b33bc1f7a37bc9b17dd1631b1a06047 Mon Sep 17 00:00:00 2001

The DSS fclk and iclk handles are named differently on OMAP3430 ES1 than on later OMAP revisions. The ES1 has handles 'dss1_alwon_fck_3430es1' and 'dss_ick_3430es1', whereas later revisions have similar names but ending with 'es2'.

This means we don't have one clock handle to which we could refer to when defining the DSS clocks.

However, as the namespaces are separate for ES1 and ES2+ OMAPs, we can just rename the handles to 'dss1_alwon_fck' and 'dss_ick' for both ES1 and ES2+, removing the issue.

Signed-off-by Tomi Valkeinen <[email protected]>

---
  arch/arm/boot/dts/omap3430es1-clocks.dtsi                     | 6 +++---
  arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi | 6 +++---
  2 files changed, 6 insertions(+), 6 deletions(-)

arch/arm/boot/dts/omap3430es1-clocks.dtsi +3 -3

index 02f6c7fabbec..f9202656168f 100644
@@ -152,7 +152,7 @@
  		clocks = <&usb_l4_gate_ick>, <&usb_l4_div_ick>;
  	};
 
-	dss1_alwon_fck_3430es1: dss1_alwon_fck_3430es1 {
+	dss1_alwon_fck: dss1_alwon_fck_3430es1 {
  		#clock-cells = <0>;
  		compatible = "ti,gate-clock";
  		clocks = <&dpll4_m4x2_ck>;

@@ -161,7 +161,7 @@
  		ti,set-rate-parent;
  	};
 
-	dss_ick_3430es1: dss_ick_3430es1 {
+	dss_ick: dss_ick_3430es1 {
  		#clock-cells = <0>;
  		compatible = "ti,omap3-no-wait-interface-clock";
  		clocks = <&l4_ick>;

@@ -184,7 +184,7 @@
  	dss_clkdm: dss_clkdm {
  		compatible = "ti,clockdomain";
  		clocks = <&dss_tv_fck>, <&dss_96m_fck>, <&dss2_alwon_fck>,
-			 <&dss1_alwon_fck_3430es1>, <&dss_ick_3430es1>;
+			 <&dss1_alwon_fck>, <&dss_ick>;
  	};
 
  	d2d_clkdm: d2d_clkdm {

arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi +3 -3

index af9ae5346bf2..080fb3f4e429 100644
@@ -160,7 +160,7 @@
  		ti,bit-shift = <30>;
  	};
 
-	dss1_alwon_fck_3430es2: dss1_alwon_fck_3430es2 {
+	dss1_alwon_fck: dss1_alwon_fck_3430es2 {
  		#clock-cells = <0>;
  		compatible = "ti,dss-gate-clock";
  		clocks = <&dpll4_m4x2_ck>;

@@ -169,7 +169,7 @@
  		ti,set-rate-parent;
  	};
 
-	dss_ick_3430es2: dss_ick_3430es2 {
+	dss_ick: dss_ick_3430es2 {
  		#clock-cells = <0>;
  		compatible = "ti,omap3-dss-interface-clock";
  		clocks = <&l4_ick>;

@@ -216,7 +216,7 @@
  	dss_clkdm: dss_clkdm {
  		compatible = "ti,clockdomain";
  		clocks = <&dss_tv_fck>, <&dss_96m_fck>, <&dss2_alwon_fck>,
-			 <&dss1_alwon_fck_3430es2>, <&dss_ick_3430es2>;
+			 <&dss1_alwon_fck>, <&dss_ick>;
  	};
 
  	core_l4_clkdm: core_l4_clkdm {

OMAP3630 DPLL4 is different than on OMAP3430, in that it doesn't have the x2 multiplier for its outputs. This is not currently reflected in the clock DT data.

Fix the issue by setting the clock multiplier to 1 (instead of 2) for the DPLL4 output clocks.

Signed-off-by Tomi Valkeinen <[email protected]>

---
  arch/arm/boot/dts/omap36xx-clocks.dtsi | 20 ++++++++++++++++++++
  arch/arm/boot/dts/omap36xx.dtsi        |  2 +-
  2 files changed, 21 insertions(+), 1 deletion(-)

arch/arm/boot/dts/omap36xx-clocks.dtsi +20 -0

index 2fcf253b677c..0b2df76b9d38 100644
@@ -70,6 +70,26 @@
  	};
  };
 
+&dpll4_m2x2_mul_ck {
+	clock-mult = <1>;
+};
+
+&dpll4_m3x2_mul_ck {
+	clock-mult = <1>;
+};
+
+&dpll4_m4x2_mul_ck {
+	clock-mult = <1>;
+};
+
+&dpll4_m5x2_mul_ck {
+	clock-mult = <1>;
+};
+
+&dpll4_m6x2_mul_ck {
+	clock-mult = <1>;
+};
+
  &cm_clockdomains {
  	dpll4_clkdm: dpll4_clkdm {
  		compatible = "ti,clockdomain";

arch/arm/boot/dts/omap36xx.dtsi +0 -0

index 7e8dee9175d6..5e1bcd06a996 100644

We need to use set-rate-parent for dpll4_m4 clock path, so use the ti,fixed-factor-clock version which supports set-rate-parent property.

Signed-off-by Tomi Valkeinen <[email protected]>

---
  arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +-
  arch/arm/boot/dts/omap3xxx-clocks.dtsi | 6 +++---
  2 files changed, 4 insertions(+), 4 deletions(-)

arch/arm/boot/dts/omap36xx-clocks.dtsi +1 -1

index 0b2df76b9d38..6b5280d04a0e 100644
@@ -79,7 +79,7 @@
  };
 
  &dpll4_m4x2_mul_ck {
-	clock-mult = <1>;
+	ti,clock-mult = <1>;
  };
 
  &dpll4_m5x2_mul_ck {

arch/arm/boot/dts/omap3xxx-clocks.dtsi +3 -3

index cb04d4b37e7f..df3c699a1893 100644
@@ -425,10 +425,10 @@
 
  	dpll4_m4x2_mul_ck: dpll4_m4x2_mul_ck {
  		#clock-cells = <0>;
-		compatible = "fixed-factor-clock";
+		compatible = "ti,fixed-factor-clock";
  		clocks = <&dpll4_m4_ck>;
-		clock-mult = <2>;
-		clock-div = <1>;
+		ti,clock-mult = <2>;
+		ti,clock-div = <1>;
  	};
 
  	dpll4_m4x2_ck: dpll4_m4x2_ck {

Quoted 2 lines · Tomi Valkeinen

We need to use set-rate-parent for dpll4_m4 clock path, so use the ti,fixed-factor-clock version which supports set-rate-parent property.

.... you are talking about the flag but not introducing it in this patch, maybe squash this + patch 7...?

Set 'ti,set-rate-parent' property for clocks in the dpll4_m4 clock path, which is used for DSS functional clock. This fixes DSS driver's clock rate configuration, which needs the rate to be propagated properly to the divider node (dpll4_m4_ck).

Signed-off-by Tomi Valkeinen <[email protected]>

---
  arch/arm/boot/dts/omap3xxx-clocks.dtsi | 2 ++
  1 file changed, 2 insertions(+)

arch/arm/boot/dts/omap3xxx-clocks.dtsi +2 -0

index df3c699a1893..12be2b35dae9 100644
@@ -429,6 +429,7 @@
  		clocks = <&dpll4_m4_ck>;
  		ti,clock-mult = <2>;
  		ti,clock-div = <1>;
+		ti,set-rate-parent;
  	};
 
  	dpll4_m4x2_ck: dpll4_m4x2_ck {

@@ -438,6 +439,7 @@
  		ti,bit-shift = <0x1d>;
  		reg = <0x0d00>;
  		ti,set-bit-to-disable;
+		ti,set-rate-parent;
  	};
 
  	dpll4_m5_ck: dpll4_m5_ck {

Quoted 4 lines · Tomi Valkeinen

Set 'ti,set-rate-parent' property for clocks in the dpll4_m4 clock path, which is used for DSS functional clock. This fixes DSS driver's clock rate configuration, which needs the rate to be propagated properly to the divider node (dpll4_m4_ck).

... squash to #6?

Hi,

I've been debugging OMAP3 related issues with DSS clocks, and I hopefully have them all fixed with this series. This fixes the problems for both non-DT boot, but also for DT boot with DSS DT support (which is not merged yet).

The non-DT boot related fixes should be merged for 3.14, but I'd like the DT boot related fixes to be merged for 3.14 also, as that'll make handling the DSS DT support easier.

This is based on v3.14-rc2.

Tomi

Tomi Valkeinen (8):
clk: divider: fix rate calculation for fractional rates
clk: ti/divider: fix rate calculation for fractional rates
ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT
ARM: dts: fix omap3 dss clock handle names
ARM: dts: fix DPLL4 x2 clkouts on 3630
ARM: dts: use ti,fixed-factor-clock for dpll4_m4x2_mul_ck
ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path
OMAPDSS: fix rounding when calculating fclk rate

 arch/arm/boot/dts/omap3430es1-clocks.dtsi          |  6 +--
 .../omap36xx-am35xx-omap3430es2plus-clocks.dtsi    |  6 +--
 arch/arm/boot/dts/omap36xx-clocks.dtsi             | 20 +++++++
 arch/arm/boot/dts/omap36xx.dtsi                    |  2 +-
 arch/arm/boot/dts/omap3xxx-clocks.dtsi             |  8 +--
 arch/arm/mach-omap2/cclock3xxx_data.c              |  2 +
 arch/arm/mach-omap2/dpll3xxx.c                     | 62 ++++++++++++++++++++++
 drivers/clk/clk-divider.c                          | 10 ++--
 drivers/clk/ti/divider.c                           |  8 +--
 drivers/video/omap2/dss/dss.c                      |  4 +-
 include/linux/clk/ti.h                             |  4 ++
 11 files changed, 111 insertions(+), 21 deletions(-)

--
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi,

I've been debugging OMAP3 related issues with DSS clocks, and I hopefully have them all fixed with this series. This fixes the problems for both non-DT boot, but also for DT boot with DSS DT support (which is not merged yet).

The non-DT boot related fixes should be merged for 3.14, but I'd like the DT boot related fixes to be merged for 3.14 also, as that'll make handling the DSS DT support easier.

Hi,

I've been debugging OMAP3 related issues with DSS clocks, and I hopefully have them all fixed with this series. This fixes the problems for both non-DT boot, but also for DT boot with DSS DT support (which is not merged yet).

The non-DT boot related fixes should be merged for 3.14, but I'd like the DT boot related fixes to be merged for 3.14 also, as that'll make handling the DSS DT support easier.

This is based on v3.14-rc2.

Tomi

Tomi Valkeinen (8):
clk: divider: fix rate calculation for fractional rates
clk: ti/divider: fix rate calculation for fractional rates
ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT
ARM: dts: fix omap3 dss clock handle names
ARM: dts: fix DPLL4 x2 clkouts on 3630
ARM: dts: use ti,fixed-factor-clock for dpll4_m4x2_mul_ck
ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path
OMAPDSS: fix rounding when calculating fclk rate

 arch/arm/boot/dts/omap3430es1-clocks.dtsi          |  6 +--
 .../omap36xx-am35xx-omap3430es2plus-clocks.dtsi    |  6 +--
 arch/arm/boot/dts/omap36xx-clocks.dtsi             | 20 +++++++
 arch/arm/boot/dts/omap36xx.dtsi                    |  2 +-
 arch/arm/boot/dts/omap3xxx-clocks.dtsi             |  8 +--
 arch/arm/mach-omap2/cclock3xxx_data.c              |  2 +
 arch/arm/mach-omap2/dpll3xxx.c                     | 62 ++++++++++++++++++++++
 drivers/clk/clk-divider.c                          | 10 ++--
 drivers/clk/ti/divider.c                           |  8 +--
 drivers/video/omap2/dss/dss.c                      |  4 +-
 include/linux/clk/ti.h                             |  4 ++
 11 files changed, 111 insertions(+), 21 deletions(-)

Hi Tero,

What about the dts fixes in this series? DSS DT depends on those fixes. I'd like the dts fixes to be either merged for v3.14, or I can add them to my DSS DT series (with acks).

Tomi

Quoted 37 lines · Tomi Valkeinen

Hi,

I've been debugging OMAP3 related issues with DSS clocks, and I hopefully have them all fixed with this series. This fixes the problems for both non-DT boot, but also for DT boot with DSS DT support (which is not merged yet).

The non-DT boot related fixes should be merged for 3.14, but I'd like the DT boot related fixes to be merged for 3.14 also, as that'll make handling the DSS DT support easier.

This is based on v3.14-rc2.

Tomi

Tomi Valkeinen (8):
clk: divider: fix rate calculation for fractional rates
clk: ti/divider: fix rate calculation for fractional rates
ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT
ARM: dts: fix omap3 dss clock handle names
ARM: dts: fix DPLL4 x2 clkouts on 3630
ARM: dts: use ti,fixed-factor-clock for dpll4_m4x2_mul_ck
ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path
OMAPDSS: fix rounding when calculating fclk rate

  arch/arm/boot/dts/omap3430es1-clocks.dtsi          |  6 +--
  .../omap36xx-am35xx-omap3430es2plus-clocks.dtsi    |  6 +--
  arch/arm/boot/dts/omap36xx-clocks.dtsi             | 20 +++++++
  arch/arm/boot/dts/omap36xx.dtsi                    |  2 +-
  arch/arm/boot/dts/omap3xxx-clocks.dtsi             |  8 +--
  arch/arm/mach-omap2/cclock3xxx_data.c              |  2 +
  arch/arm/mach-omap2/dpll3xxx.c                     | 62 ++++++++++++++++++++++
  drivers/clk/clk-divider.c                          | 10 ++--
  drivers/clk/ti/divider.c                           |  8 +--
  drivers/video/omap2/dss/dss.c                      |  4 +-
  include/linux/clk/ti.h                             |  4 ++
  11 files changed, 111 insertions(+), 21 deletions(-)

Quoted 5 lines · Tomi Valkeinen

Hi Tero,

What about the dts fixes in this series? DSS DT depends on those fixes. I'd like the dts fixes to be either merged for v3.14, or I can add them to my DSS DT series (with acks).

Well, I am not a maintainer of any sort, so you are asking wrong person here. I am just tossing my acks around as my approval for the patches in case someone cares. :) You need to ask Benoit here (or maybe Tony.)

Quoted 7 lines · Tero Kristo

Quoted 5 lines · Tomi Valkeinen

Hi Tero,

What about the dts fixes in this series? DSS DT depends on those fixes. I'd like the dts fixes to be either merged for v3.14, or I can add them to my DSS DT series (with acks).

Quoted 3 lines

Well, I am not a maintainer of any sort, so you are asking wrong person here. I am just tossing my acks around as my approval for the patches in case someone cares. :) You need to ask Benoit here (or maybe Tony.)

Ok.

Benoit, Tony, can we get the dts fixes in this series to v3.14, or is it ok if I merge them via DSS DT branch for 3.15?