[PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[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(-)

-- 
1.8.3.2

[PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[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(-)

-- 
1.8.3.2

[PATCH 1/8] clk: divider: fix rate calculation for fractional rates

[Tomi Valkeinen]

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 <tomi.valkeinen@ti.com>
Cc: Mike Turquette <mturquette@linaro.org>
---
 drivers/clk/clk-divider.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 5543b7df8e16..ec22112e569f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -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);
 
 	if (value > div_mask(divider))
-- 
1.8.3.2

[PATCH 1/8] clk: divider: fix rate calculation for fractional rates

[Tomi Valkeinen]

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 <tomi.valkeinen@ti.com>
Cc: Mike Turquette <mturquette@linaro.org>
---
 drivers/clk/clk-divider.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 5543b7df8e16..ec22112e569f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -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);
 
 	if (value > div_mask(divider))
-- 
1.8.3.2

Re: [PATCH 1/8] clk: divider: fix rate calculation for fractional rates

[Tero Kristo]

On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
> 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 <tomi.valkeinen@ti.com>
> Cc: Mike Turquette <mturquette@linaro.org>
> ---
>   drivers/clk/clk-divider.c | 10 +++++-----
>   1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index 5543b7df8e16..ec22112e569f 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -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);
>
>   	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

[PATCH 1/8] clk: divider: fix rate calculation for fractional rates

[Tero Kristo]

On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
> 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 <tomi.valkeinen@ti.com>
> Cc: Mike Turquette <mturquette@linaro.org>
> ---
>   drivers/clk/clk-divider.c | 10 +++++-----
>   1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index 5543b7df8e16..ec22112e569f 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -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);
>
>   	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

Re: [PATCH 1/8] clk: divider: fix rate calculation for fractional rates

[Mike Turquette]

Quoting Tero Kristo (2014-02-14 05:45:22)
> On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
> > 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 <tomi.valkeinen@ti.com>
> > Cc: Mike Turquette <mturquette@linaro.org>
> > ---
> >   drivers/clk/clk-divider.c | 10 +++++-----
> >   1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> > index 5543b7df8e16..ec22112e569f 100644
> > --- a/drivers/clk/clk-divider.c
> > +++ b/drivers/clk/clk-divider.c
> > @@ -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);
> >
> >       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.

Regards,
Mike

> 
> -Tero
> 

[PATCH 1/8] clk: divider: fix rate calculation for fractional rates

[Mike Turquette]

Quoting Tero Kristo (2014-02-14 05:45:22)
> On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
> > 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 <tomi.valkeinen@ti.com>
> > Cc: Mike Turquette <mturquette@linaro.org>
> > ---
> >   drivers/clk/clk-divider.c | 10 +++++-----
> >   1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> > index 5543b7df8e16..ec22112e569f 100644
> > --- a/drivers/clk/clk-divider.c
> > +++ b/drivers/clk/clk-divider.c
> > @@ -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);
> >
> >       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.

Regards,
Mike

> 
> -Tero
> 

Re: [PATCH 1/8] clk: divider: fix rate calculation for fractional rates

[Tomi Valkeinen]

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

On 27/02/14 04:25, Mike Turquette wrote:

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

Thanks. I understand there's a possibility this could break some other
driver. I still wish we could get this to 3.14, as this would fix OMAP
display subsystem.

 Tomi



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

[PATCH 1/8] clk: divider: fix rate calculation for fractional rates

[Tomi Valkeinen]

On 27/02/14 04:25, Mike Turquette wrote:

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

Thanks. I understand there's a possibility this could break some other
driver. I still wish we could get this to 3.14, as this would fix OMAP
display subsystem.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140228/ffb9e296/attachment.sig>

Re: [PATCH 1/8] clk: divider: fix rate calculation for fractional rates

[Tomi Valkeinen]

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

On 27/02/14 04:25, Mike Turquette wrote:
> Quoting Tero Kristo (2014-02-14 05:45:22)
>> On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
>>> 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 <tomi.valkeinen@ti.com>
>>> Cc: Mike Turquette <mturquette@linaro.org>
>>> ---
>>>   drivers/clk/clk-divider.c | 10 +++++-----
>>>   1 file changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
>>> index 5543b7df8e16..ec22112e569f 100644
>>> --- a/drivers/clk/clk-divider.c
>>> +++ b/drivers/clk/clk-divider.c
>>> @@ -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);
>>>
>>>       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.

Are these on the way to 3.15?

 Tomi



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

[PATCH 1/8] clk: divider: fix rate calculation for fractional rates

[Tomi Valkeinen]

On 27/02/14 04:25, Mike Turquette wrote:
> Quoting Tero Kristo (2014-02-14 05:45:22)
>> On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
>>> 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 <tomi.valkeinen@ti.com>
>>> Cc: Mike Turquette <mturquette@linaro.org>
>>> ---
>>>   drivers/clk/clk-divider.c | 10 +++++-----
>>>   1 file changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
>>> index 5543b7df8e16..ec22112e569f 100644
>>> --- a/drivers/clk/clk-divider.c
>>> +++ b/drivers/clk/clk-divider.c
>>> @@ -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);
>>>
>>>       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.

Are these on the way to 3.15?

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140317/f4945404/attachment-0001.sig>

Re: [PATCH 1/8] clk: divider: fix rate calculation for fractional rates

[Mike Turquette]

Quoting Tomi Valkeinen (2014-03-17 05:53:03)
> On 27/02/14 04:25, Mike Turquette wrote:
> > Quoting Tero Kristo (2014-02-14 05:45:22)
> >> On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
> >>> 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 <tomi.valkeinen@ti.com>
> >>> Cc: Mike Turquette <mturquette@linaro.org>
> >>> ---
> >>>   drivers/clk/clk-divider.c | 10 +++++-----
> >>>   1 file changed, 5 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> >>> index 5543b7df8e16..ec22112e569f 100644
> >>> --- a/drivers/clk/clk-divider.c
> >>> +++ b/drivers/clk/clk-divider.c
> >>> @@ -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);
> >>>
> >>>       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.
> 
> Are these on the way to 3.15?

Yes, they've been in -next for a couple of weeks.

Regards,
Mike

> 
>  Tomi
> 
> 

[PATCH 1/8] clk: divider: fix rate calculation for fractional rates

[Mike Turquette]

Quoting Tomi Valkeinen (2014-03-17 05:53:03)
> On 27/02/14 04:25, Mike Turquette wrote:
> > Quoting Tero Kristo (2014-02-14 05:45:22)
> >> On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
> >>> 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 <tomi.valkeinen@ti.com>
> >>> Cc: Mike Turquette <mturquette@linaro.org>
> >>> ---
> >>>   drivers/clk/clk-divider.c | 10 +++++-----
> >>>   1 file changed, 5 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> >>> index 5543b7df8e16..ec22112e569f 100644
> >>> --- a/drivers/clk/clk-divider.c
> >>> +++ b/drivers/clk/clk-divider.c
> >>> @@ -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);
> >>>
> >>>       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.
> 
> Are these on the way to 3.15?

Yes, they've been in -next for a couple of weeks.

Regards,
Mike

> 
>  Tomi
> 
> 

[PATCH 2/8] clk: ti/divider: fix rate calculation for fractional rates

[Tomi Valkeinen]

ti/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 ti/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 <tomi.valkeinen@ti.com>
---
 drivers/clk/ti/divider.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/ti/divider.c b/drivers/clk/ti/divider.c
index a15e445570b2..e6aa10db7bba 100644
--- a/drivers/clk/ti/divider.c
+++ b/drivers/clk/ti/divider.c
@@ -112,7 +112,7 @@ static unsigned long ti_clk_divider_recalc_rate(struct clk_hw *hw,
 		return parent_rate;
 	}
 
-	return parent_rate / div;
+	return DIV_ROUND_UP(parent_rate, div);
 }
 
 /*
@@ -182,7 +182,7 @@ static int ti_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;
@@ -205,7 +205,7 @@ static long ti_clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
 	int div;
 	div = ti_clk_divider_bestdiv(hw, rate, prate);
 
-	return *prate / div;
+	return DIV_ROUND_UP(*prate, div);
 }
 
 static int ti_clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -216,7 +216,7 @@ static int ti_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))
-- 
1.8.3.2

[PATCH 2/8] clk: ti/divider: fix rate calculation for fractional rates

[Tomi Valkeinen]

ti/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 ti/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 <tomi.valkeinen@ti.com>
---
 drivers/clk/ti/divider.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/ti/divider.c b/drivers/clk/ti/divider.c
index a15e445570b2..e6aa10db7bba 100644
--- a/drivers/clk/ti/divider.c
+++ b/drivers/clk/ti/divider.c
@@ -112,7 +112,7 @@ static unsigned long ti_clk_divider_recalc_rate(struct clk_hw *hw,
 		return parent_rate;
 	}
 
-	return parent_rate / div;
+	return DIV_ROUND_UP(parent_rate, div);
 }
 
 /*
@@ -182,7 +182,7 @@ static int ti_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;
@@ -205,7 +205,7 @@ static long ti_clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
 	int div;
 	div = ti_clk_divider_bestdiv(hw, rate, prate);
 
-	return *prate / div;
+	return DIV_ROUND_UP(*prate, div);
 }
 
 static int ti_clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -216,7 +216,7 @@ static int ti_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))
-- 
1.8.3.2

[PATCH 3/8] ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT

[Tomi Valkeinen]

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 <tomi.valkeinen@ti.com>
---
 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(+)

diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
index 3b05aea56d1f..11ed9152e665 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -433,7 +433,9 @@ static const struct clk_ops dpll4_m5x2_ck_ops = {
 	.enable		= &omap2_dflt_clk_enable,
 	.disable	= &omap2_dflt_clk_disable,
 	.is_enabled	= &omap2_dflt_clk_is_enabled,
+	.set_rate	= &omap3_clkoutx2_set_rate,
 	.recalc_rate	= &omap3_clkoutx2_recalc,
+	.round_rate	= &omap3_clkoutx2_round_rate,
 };
 
 static const struct clk_ops dpll4_m5x2_ck_3630_ops = {
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 3185ced807c9..4ba7e90e127b 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -672,6 +672,68 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
 	return rate;
 }
 
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+					unsigned long parent_rate)
+{
+	return 0;
+}
+
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
+		unsigned long *prate)
+{
+	const struct dpll_data *dd;
+	u32 v;
+	struct clk_hw_omap *pclk = NULL;
+	struct clk *parent;
+
+	if (!*prate)
+		return 0;
+
+	/* Walk up the parents of clk, looking for a DPLL */
+	do {
+		do {
+			parent = __clk_get_parent(hw->clk);
+			hw = __clk_get_hw(parent);
+		} while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
+		if (!hw)
+			break;
+		pclk = to_clk_hw_omap(hw);
+	} while (pclk && !pclk->dpll_data);
+
+	/* clk does not have a DPLL as a parent?  error in the clock data */
+	if (!pclk) {
+		WARN_ON(1);
+		return 0;
+	}
+
+	dd = pclk->dpll_data;
+
+	/* TYPE J does not have a clkoutx2 */
+	if (dd->flags & DPLL_J_TYPE) {
+		*prate = __clk_round_rate(__clk_get_parent(pclk->hw.clk), rate);
+		return *prate;
+	}
+
+	WARN_ON(!dd->enable_mask);
+
+	v = omap2_clk_readl(pclk, dd->control_reg) & dd->enable_mask;
+	v >>= __ffs(dd->enable_mask);
+
+	/* If in bypass, the rate is fixed to the bypass rate*/
+	if (v != OMAP3XXX_EN_DPLL_LOCKED)
+		return *prate;
+
+	if (__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT) {
+		unsigned long best_parent;
+
+		best_parent = (rate / 2);
+		*prate = __clk_round_rate(__clk_get_parent(hw->clk),
+				best_parent);
+	}
+
+	return *prate * 2;
+}
+
 /* OMAP3/4 non-CORE DPLL clkops */
 const struct clk_hw_omap_ops clkhwops_omap3_dpll = {
 	.allow_idle	= omap3_dpll_allow_idle,
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 092b64168d7f..4a21a872dbbd 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -245,6 +245,10 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
 void omap2_init_clk_clkdm(struct clk_hw *clk);
 unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
 				    unsigned long parent_rate);
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+					unsigned long parent_rate);
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
+		unsigned long *prate);
 int omap2_clkops_enable_clkdm(struct clk_hw *hw);
 void omap2_clkops_disable_clkdm(struct clk_hw *hw);
 int omap2_clk_disable_autoidle_all(void);
-- 
1.8.3.2

[PATCH 3/8] ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT

[Tomi Valkeinen]

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 <tomi.valkeinen@ti.com>
---
 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(+)

diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
index 3b05aea56d1f..11ed9152e665 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -433,7 +433,9 @@ static const struct clk_ops dpll4_m5x2_ck_ops = {
 	.enable		= &omap2_dflt_clk_enable,
 	.disable	= &omap2_dflt_clk_disable,
 	.is_enabled	= &omap2_dflt_clk_is_enabled,
+	.set_rate	= &omap3_clkoutx2_set_rate,
 	.recalc_rate	= &omap3_clkoutx2_recalc,
+	.round_rate	= &omap3_clkoutx2_round_rate,
 };
 
 static const struct clk_ops dpll4_m5x2_ck_3630_ops = {
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 3185ced807c9..4ba7e90e127b 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -672,6 +672,68 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
 	return rate;
 }
 
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+					unsigned long parent_rate)
+{
+	return 0;
+}
+
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
+		unsigned long *prate)
+{
+	const struct dpll_data *dd;
+	u32 v;
+	struct clk_hw_omap *pclk = NULL;
+	struct clk *parent;
+
+	if (!*prate)
+		return 0;
+
+	/* Walk up the parents of clk, looking for a DPLL */
+	do {
+		do {
+			parent = __clk_get_parent(hw->clk);
+			hw = __clk_get_hw(parent);
+		} while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
+		if (!hw)
+			break;
+		pclk = to_clk_hw_omap(hw);
+	} while (pclk && !pclk->dpll_data);
+
+	/* clk does not have a DPLL as a parent?  error in the clock data */
+	if (!pclk) {
+		WARN_ON(1);
+		return 0;
+	}
+
+	dd = pclk->dpll_data;
+
+	/* TYPE J does not have a clkoutx2 */
+	if (dd->flags & DPLL_J_TYPE) {
+		*prate = __clk_round_rate(__clk_get_parent(pclk->hw.clk), rate);
+		return *prate;
+	}
+
+	WARN_ON(!dd->enable_mask);
+
+	v = omap2_clk_readl(pclk, dd->control_reg) & dd->enable_mask;
+	v >>= __ffs(dd->enable_mask);
+
+	/* If in bypass, the rate is fixed to the bypass rate*/
+	if (v != OMAP3XXX_EN_DPLL_LOCKED)
+		return *prate;
+
+	if (__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT) {
+		unsigned long best_parent;
+
+		best_parent = (rate / 2);
+		*prate = __clk_round_rate(__clk_get_parent(hw->clk),
+				best_parent);
+	}
+
+	return *prate * 2;
+}
+
 /* OMAP3/4 non-CORE DPLL clkops */
 const struct clk_hw_omap_ops clkhwops_omap3_dpll = {
 	.allow_idle	= omap3_dpll_allow_idle,
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 092b64168d7f..4a21a872dbbd 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -245,6 +245,10 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
 void omap2_init_clk_clkdm(struct clk_hw *clk);
 unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
 				    unsigned long parent_rate);
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+					unsigned long parent_rate);
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
+		unsigned long *prate);
 int omap2_clkops_enable_clkdm(struct clk_hw *hw);
 void omap2_clkops_disable_clkdm(struct clk_hw *hw);
 int omap2_clk_disable_autoidle_all(void);
-- 
1.8.3.2

Re: [PATCH 3/8] ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT

[Tomi Valkeinen]

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

On 13/02/14 12:04, Tomi Valkeinen wrote:
> 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 <tomi.valkeinen@ti.com>
> ---
>  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(+)

Argh. This patch 3/8 was an old version, and not valid. It does not work for
omap3430. I had earlier posted a proper version, but somehow I managed to get
an old version for this series.

The correct version can be found from

http://mid.gmane.org/1391080640-23370-1-git-send-email-tomi.valkeinen@ti.com

and I'll also include it below.

 Tomi

From 0d46054a8b33bc1f7a37bc9b17dd1631b1a06047 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Thu, 30 Jan 2014 13:17:20 +0200
Subject: [PATCH] ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT

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 got broken when
d0f58bd3bba3877fb1af4664c4e33273d36f00e4 and related patches were merged
for v3.14, as omapdss driver now relies more on the clk-framework and
CLK_SET_RATE_PARENT.

This patch implements set_rate and round_rate for clkoutx2.

Tested on OMAP3430, OMAP3630, OMAP4460.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/cclock3xxx_data.c |  2 +
 arch/arm/mach-omap2/dpll3xxx.c        | 92 +++++++++++++++++++++++++++++------
 include/linux/clk/ti.h                |  4 ++
 3 files changed, 83 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
index 3b05aea56d1f..11ed9152e665 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -433,7 +433,9 @@ static const struct clk_ops dpll4_m5x2_ck_ops = {
 	.enable		= &omap2_dflt_clk_enable,
 	.disable	= &omap2_dflt_clk_disable,
 	.is_enabled	= &omap2_dflt_clk_is_enabled,
+	.set_rate	= &omap3_clkoutx2_set_rate,
 	.recalc_rate	= &omap3_clkoutx2_recalc,
+	.round_rate	= &omap3_clkoutx2_round_rate,
 };
 
 static const struct clk_ops dpll4_m5x2_ck_3630_ops = {
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 3185ced807c9..3c418ea54bbe 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -623,6 +623,32 @@ void omap3_dpll_deny_idle(struct clk_hw_omap *clk)
 
 /* Clock control for DPLL outputs */
 
+/* Find the parent DPLL for the given clkoutx2 clock */
+static struct clk_hw_omap *omap3_find_clkoutx2_dpll(struct clk_hw *hw)
+{
+	struct clk_hw_omap *pclk = NULL;
+	struct clk *parent;
+
+	/* Walk up the parents of clk, looking for a DPLL */
+	do {
+		do {
+			parent = __clk_get_parent(hw->clk);
+			hw = __clk_get_hw(parent);
+		} while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
+		if (!hw)
+			break;
+		pclk = to_clk_hw_omap(hw);
+	} while (pclk && !pclk->dpll_data);
+
+	/* clk does not have a DPLL as a parent?  error in the clock data */
+	if (!pclk) {
+		WARN_ON(1);
+		return NULL;
+	}
+
+	return pclk;
+}
+
 /**
  * omap3_clkoutx2_recalc - recalculate DPLL X2 output virtual clock rate
  * @clk: DPLL output struct clk
@@ -637,27 +663,14 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
 	unsigned long rate;
 	u32 v;
 	struct clk_hw_omap *pclk = NULL;
-	struct clk *parent;
 
 	if (!parent_rate)
 		return 0;
 
-	/* Walk up the parents of clk, looking for a DPLL */
-	do {
-		do {
-			parent = __clk_get_parent(hw->clk);
-			hw = __clk_get_hw(parent);
-		} while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
-		if (!hw)
-			break;
-		pclk = to_clk_hw_omap(hw);
-	} while (pclk && !pclk->dpll_data);
+	pclk = omap3_find_clkoutx2_dpll(hw);
 
-	/* clk does not have a DPLL as a parent?  error in the clock data */
-	if (!pclk) {
-		WARN_ON(1);
+	if (!pclk)
 		return 0;
-	}
 
 	dd = pclk->dpll_data;
 
@@ -672,6 +685,55 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
 	return rate;
 }
 
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+					unsigned long parent_rate)
+{
+	return 0;
+}
+
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
+		unsigned long *prate)
+{
+	const struct dpll_data *dd;
+	u32 v;
+	struct clk_hw_omap *pclk = NULL;
+
+	if (!*prate)
+		return 0;
+
+	pclk = omap3_find_clkoutx2_dpll(hw);
+
+	if (!pclk)
+		return 0;
+
+	dd = pclk->dpll_data;
+
+	/* TYPE J does not have a clkoutx2 */
+	if (dd->flags & DPLL_J_TYPE) {
+		*prate = __clk_round_rate(__clk_get_parent(pclk->hw.clk), rate);
+		return *prate;
+	}
+
+	WARN_ON(!dd->enable_mask);
+
+	v = omap2_clk_readl(pclk, dd->control_reg) & dd->enable_mask;
+	v >>= __ffs(dd->enable_mask);
+
+	/* If in bypass, the rate is fixed to the bypass rate*/
+	if (v != OMAP3XXX_EN_DPLL_LOCKED)
+		return *prate;
+
+	if (__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT) {
+		unsigned long best_parent;
+
+		best_parent = (rate / 2);
+		*prate = __clk_round_rate(__clk_get_parent(hw->clk),
+				best_parent);
+	}
+
+	return *prate * 2;
+}
+
 /* OMAP3/4 non-CORE DPLL clkops */
 const struct clk_hw_omap_ops clkhwops_omap3_dpll = {
 	.allow_idle	= omap3_dpll_allow_idle,
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 092b64168d7f..4a21a872dbbd 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -245,6 +245,10 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
 void omap2_init_clk_clkdm(struct clk_hw *clk);
 unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
 				    unsigned long parent_rate);
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+					unsigned long parent_rate);
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
+		unsigned long *prate);
 int omap2_clkops_enable_clkdm(struct clk_hw *hw);
 void omap2_clkops_disable_clkdm(struct clk_hw *hw);
 int omap2_clk_disable_autoidle_all(void);
-- 
1.8.3.2




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

[PATCH 3/8] ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT

[Tomi Valkeinen]

On 13/02/14 12:04, Tomi Valkeinen wrote:
> 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 <tomi.valkeinen@ti.com>
> ---
>  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(+)

Argh. This patch 3/8 was an old version, and not valid. It does not work for
omap3430. I had earlier posted a proper version, but somehow I managed to get
an old version for this series.

The correct version can be found from

http://mid.gmane.org/1391080640-23370-1-git-send-email-tomi.valkeinen at ti.com

and I'll also include it below.

 Tomi

>From 0d46054a8b33bc1f7a37bc9b17dd1631b1a06047 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Thu, 30 Jan 2014 13:17:20 +0200
Subject: [PATCH] ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT

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 got broken when
d0f58bd3bba3877fb1af4664c4e33273d36f00e4 and related patches were merged
for v3.14, as omapdss driver now relies more on the clk-framework and
CLK_SET_RATE_PARENT.

This patch implements set_rate and round_rate for clkoutx2.

Tested on OMAP3430, OMAP3630, OMAP4460.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/cclock3xxx_data.c |  2 +
 arch/arm/mach-omap2/dpll3xxx.c        | 92 +++++++++++++++++++++++++++++------
 include/linux/clk/ti.h                |  4 ++
 3 files changed, 83 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
index 3b05aea56d1f..11ed9152e665 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -433,7 +433,9 @@ static const struct clk_ops dpll4_m5x2_ck_ops = {
 	.enable		= &omap2_dflt_clk_enable,
 	.disable	= &omap2_dflt_clk_disable,
 	.is_enabled	= &omap2_dflt_clk_is_enabled,
+	.set_rate	= &omap3_clkoutx2_set_rate,
 	.recalc_rate	= &omap3_clkoutx2_recalc,
+	.round_rate	= &omap3_clkoutx2_round_rate,
 };
 
 static const struct clk_ops dpll4_m5x2_ck_3630_ops = {
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 3185ced807c9..3c418ea54bbe 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -623,6 +623,32 @@ void omap3_dpll_deny_idle(struct clk_hw_omap *clk)
 
 /* Clock control for DPLL outputs */
 
+/* Find the parent DPLL for the given clkoutx2 clock */
+static struct clk_hw_omap *omap3_find_clkoutx2_dpll(struct clk_hw *hw)
+{
+	struct clk_hw_omap *pclk = NULL;
+	struct clk *parent;
+
+	/* Walk up the parents of clk, looking for a DPLL */
+	do {
+		do {
+			parent = __clk_get_parent(hw->clk);
+			hw = __clk_get_hw(parent);
+		} while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
+		if (!hw)
+			break;
+		pclk = to_clk_hw_omap(hw);
+	} while (pclk && !pclk->dpll_data);
+
+	/* clk does not have a DPLL as a parent?  error in the clock data */
+	if (!pclk) {
+		WARN_ON(1);
+		return NULL;
+	}
+
+	return pclk;
+}
+
 /**
  * omap3_clkoutx2_recalc - recalculate DPLL X2 output virtual clock rate
  * @clk: DPLL output struct clk
@@ -637,27 +663,14 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
 	unsigned long rate;
 	u32 v;
 	struct clk_hw_omap *pclk = NULL;
-	struct clk *parent;
 
 	if (!parent_rate)
 		return 0;
 
-	/* Walk up the parents of clk, looking for a DPLL */
-	do {
-		do {
-			parent = __clk_get_parent(hw->clk);
-			hw = __clk_get_hw(parent);
-		} while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
-		if (!hw)
-			break;
-		pclk = to_clk_hw_omap(hw);
-	} while (pclk && !pclk->dpll_data);
+	pclk = omap3_find_clkoutx2_dpll(hw);
 
-	/* clk does not have a DPLL as a parent?  error in the clock data */
-	if (!pclk) {
-		WARN_ON(1);
+	if (!pclk)
 		return 0;
-	}
 
 	dd = pclk->dpll_data;
 
@@ -672,6 +685,55 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
 	return rate;
 }
 
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+					unsigned long parent_rate)
+{
+	return 0;
+}
+
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
+		unsigned long *prate)
+{
+	const struct dpll_data *dd;
+	u32 v;
+	struct clk_hw_omap *pclk = NULL;
+
+	if (!*prate)
+		return 0;
+
+	pclk = omap3_find_clkoutx2_dpll(hw);
+
+	if (!pclk)
+		return 0;
+
+	dd = pclk->dpll_data;
+
+	/* TYPE J does not have a clkoutx2 */
+	if (dd->flags & DPLL_J_TYPE) {
+		*prate = __clk_round_rate(__clk_get_parent(pclk->hw.clk), rate);
+		return *prate;
+	}
+
+	WARN_ON(!dd->enable_mask);
+
+	v = omap2_clk_readl(pclk, dd->control_reg) & dd->enable_mask;
+	v >>= __ffs(dd->enable_mask);
+
+	/* If in bypass, the rate is fixed to the bypass rate*/
+	if (v != OMAP3XXX_EN_DPLL_LOCKED)
+		return *prate;
+
+	if (__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT) {
+		unsigned long best_parent;
+
+		best_parent = (rate / 2);
+		*prate = __clk_round_rate(__clk_get_parent(hw->clk),
+				best_parent);
+	}
+
+	return *prate * 2;
+}
+
 /* OMAP3/4 non-CORE DPLL clkops */
 const struct clk_hw_omap_ops clkhwops_omap3_dpll = {
 	.allow_idle	= omap3_dpll_allow_idle,
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 092b64168d7f..4a21a872dbbd 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -245,6 +245,10 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
 void omap2_init_clk_clkdm(struct clk_hw *clk);
 unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
 				    unsigned long parent_rate);
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+					unsigned long parent_rate);
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
+		unsigned long *prate);
 int omap2_clkops_enable_clkdm(struct clk_hw *hw);
 void omap2_clkops_disable_clkdm(struct clk_hw *hw);
 int omap2_clk_disable_autoidle_all(void);
-- 
1.8.3.2



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140213/1f45fc18/attachment.sig>

[PATCH 4/8] ARM: dts: fix omap3 dss clock handle names

[Tomi Valkeinen]

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 <tomi.valkeinen@ti.com>
---
 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(-)

diff --git a/arch/arm/boot/dts/omap3430es1-clocks.dtsi b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
index 02f6c7fabbec..f9202656168f 100644
--- a/arch/arm/boot/dts/omap3430es1-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
@@ -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 {
diff --git a/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi b/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
index af9ae5346bf2..080fb3f4e429 100644
--- a/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
@@ -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 {
-- 
1.8.3.2

[PATCH 4/8] ARM: dts: fix omap3 dss clock handle names

[Tomi Valkeinen]

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 <tomi.valkeinen@ti.com>
---
 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(-)

diff --git a/arch/arm/boot/dts/omap3430es1-clocks.dtsi b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
index 02f6c7fabbec..f9202656168f 100644
--- a/arch/arm/boot/dts/omap3430es1-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
@@ -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 {
diff --git a/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi b/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
index af9ae5346bf2..080fb3f4e429 100644
--- a/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
@@ -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 {
-- 
1.8.3.2

Re: [PATCH 4/8] ARM: dts: fix omap3 dss clock handle names

[Tero Kristo]

On 02/13/2014 12:04 PM, Tomi Valkeinen wrote:
> 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 <tomi.valkeinen@ti.com>

Acked-by: Tero Kristo <t-kristo@ti.com>

> ---
>   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(-)
>
> diff --git a/arch/arm/boot/dts/omap3430es1-clocks.dtsi b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
> index 02f6c7fabbec..f9202656168f 100644
> --- a/arch/arm/boot/dts/omap3430es1-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
> @@ -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 {
> diff --git a/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi b/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
> index af9ae5346bf2..080fb3f4e429 100644
> --- a/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
> @@ -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 {
>

[PATCH 4/8] ARM: dts: fix omap3 dss clock handle names

[Tero Kristo]

On 02/13/2014 12:04 PM, Tomi Valkeinen wrote:
> 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 <tomi.valkeinen@ti.com>

Acked-by: Tero Kristo <t-kristo@ti.com>

> ---
>   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(-)
>
> diff --git a/arch/arm/boot/dts/omap3430es1-clocks.dtsi b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
> index 02f6c7fabbec..f9202656168f 100644
> --- a/arch/arm/boot/dts/omap3430es1-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
> @@ -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 {
> diff --git a/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi b/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
> index af9ae5346bf2..080fb3f4e429 100644
> --- a/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
> @@ -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 {
>

[PATCH 5/8] ARM: dts: fix DPLL4 x2 clkouts on 3630

[Tomi Valkeinen]

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 <tomi.valkeinen@ti.com>
---
 arch/arm/boot/dts/omap36xx-clocks.dtsi | 20 ++++++++++++++++++++
 arch/arm/boot/dts/omap36xx.dtsi        |  2 +-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi b/arch/arm/boot/dts/omap36xx-clocks.dtsi
index 2fcf253b677c..0b2df76b9d38 100644
--- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
@@ -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";
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 7e8dee9175d6..5e1bcd06a996 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -52,7 +52,7 @@
 	};
 };
 
-/include/ "omap36xx-clocks.dtsi"
 /include/ "omap34xx-omap36xx-clocks.dtsi"
 /include/ "omap36xx-omap3430es2plus-clocks.dtsi"
 /include/ "omap36xx-am35xx-omap3430es2plus-clocks.dtsi"
+/include/ "omap36xx-clocks.dtsi"
-- 
1.8.3.2

[PATCH 5/8] ARM: dts: fix DPLL4 x2 clkouts on 3630

[Tomi Valkeinen]

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 <tomi.valkeinen@ti.com>
---
 arch/arm/boot/dts/omap36xx-clocks.dtsi | 20 ++++++++++++++++++++
 arch/arm/boot/dts/omap36xx.dtsi        |  2 +-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi b/arch/arm/boot/dts/omap36xx-clocks.dtsi
index 2fcf253b677c..0b2df76b9d38 100644
--- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
@@ -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";
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 7e8dee9175d6..5e1bcd06a996 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -52,7 +52,7 @@
 	};
 };
 
-/include/ "omap36xx-clocks.dtsi"
 /include/ "omap34xx-omap36xx-clocks.dtsi"
 /include/ "omap36xx-omap3430es2plus-clocks.dtsi"
 /include/ "omap36xx-am35xx-omap3430es2plus-clocks.dtsi"
+/include/ "omap36xx-clocks.dtsi"
-- 
1.8.3.2

Re: [PATCH 5/8] ARM: dts: fix DPLL4 x2 clkouts on 3630

[Tero Kristo]

On 02/13/2014 12:04 PM, Tomi Valkeinen wrote:
> 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 <tomi.valkeinen@ti.com>
> ---
>   arch/arm/boot/dts/omap36xx-clocks.dtsi | 20 ++++++++++++++++++++
>   arch/arm/boot/dts/omap36xx.dtsi        |  2 +-
>   2 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi b/arch/arm/boot/dts/omap36xx-clocks.dtsi
> index 2fcf253b677c..0b2df76b9d38 100644
> --- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
> @@ -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";
> diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
> index 7e8dee9175d6..5e1bcd06a996 100644
> --- a/arch/arm/boot/dts/omap36xx.dtsi
> +++ b/arch/arm/boot/dts/omap36xx.dtsi
> @@ -52,7 +52,7 @@
>   	};
>   };
>
> -/include/ "omap36xx-clocks.dtsi"
>   /include/ "omap34xx-omap36xx-clocks.dtsi"
>   /include/ "omap36xx-omap3430es2plus-clocks.dtsi"
>   /include/ "omap36xx-am35xx-omap3430es2plus-clocks.dtsi"
> +/include/ "omap36xx-clocks.dtsi"
>

I think this re-ordering of the includes is unnecessary.

Other than that, the patch looks okay to me, so acked.

-Tero

[PATCH 5/8] ARM: dts: fix DPLL4 x2 clkouts on 3630

[Tero Kristo]

On 02/13/2014 12:04 PM, Tomi Valkeinen wrote:
> 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 <tomi.valkeinen@ti.com>
> ---
>   arch/arm/boot/dts/omap36xx-clocks.dtsi | 20 ++++++++++++++++++++
>   arch/arm/boot/dts/omap36xx.dtsi        |  2 +-
>   2 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi b/arch/arm/boot/dts/omap36xx-clocks.dtsi
> index 2fcf253b677c..0b2df76b9d38 100644
> --- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
> @@ -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";
> diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
> index 7e8dee9175d6..5e1bcd06a996 100644
> --- a/arch/arm/boot/dts/omap36xx.dtsi
> +++ b/arch/arm/boot/dts/omap36xx.dtsi
> @@ -52,7 +52,7 @@
>   	};
>   };
>
> -/include/ "omap36xx-clocks.dtsi"
>   /include/ "omap34xx-omap36xx-clocks.dtsi"
>   /include/ "omap36xx-omap3430es2plus-clocks.dtsi"
>   /include/ "omap36xx-am35xx-omap3430es2plus-clocks.dtsi"
> +/include/ "omap36xx-clocks.dtsi"
>

I think this re-ordering of the includes is unnecessary.

Other than that, the patch looks okay to me, so acked.

-Tero

[PATCH 6/8] ARM: dts: use ti,fixed-factor-clock for dpll4_m4x2_mul_ck

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

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +-
 arch/arm/boot/dts/omap3xxx-clocks.dtsi | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi b/arch/arm/boot/dts/omap36xx-clocks.dtsi
index 0b2df76b9d38..6b5280d04a0e 100644
--- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
@@ -79,7 +79,7 @@
 };
 
 &dpll4_m4x2_mul_ck {
-	clock-mult = <1>;
+	ti,clock-mult = <1>;
 };
 
 &dpll4_m5x2_mul_ck {
diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
index cb04d4b37e7f..df3c699a1893 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -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 {
-- 
1.8.3.2

[PATCH 6/8] ARM: dts: use ti, fixed-factor-clock for dpll4_m4x2_mul_ck

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

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +-
 arch/arm/boot/dts/omap3xxx-clocks.dtsi | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi b/arch/arm/boot/dts/omap36xx-clocks.dtsi
index 0b2df76b9d38..6b5280d04a0e 100644
--- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
@@ -79,7 +79,7 @@
 };
 
 &dpll4_m4x2_mul_ck {
-	clock-mult = <1>;
+	ti,clock-mult = <1>;
 };
 
 &dpll4_m5x2_mul_ck {
diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
index cb04d4b37e7f..df3c699a1893 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -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 {
-- 
1.8.3.2

Re: [PATCH 6/8] ARM: dts: use ti,fixed-factor-clock for dpll4_m4x2_mul_ck

[Tero Kristo]

On 02/13/2014 12:04 PM, Tomi Valkeinen wrote:
> 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...?

-Tero

>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>   arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +-
>   arch/arm/boot/dts/omap3xxx-clocks.dtsi | 6 +++---
>   2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi b/arch/arm/boot/dts/omap36xx-clocks.dtsi
> index 0b2df76b9d38..6b5280d04a0e 100644
> --- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
> @@ -79,7 +79,7 @@
>   };
>
>   &dpll4_m4x2_mul_ck {
> -	clock-mult = <1>;
> +	ti,clock-mult = <1>;
>   };
>
>   &dpll4_m5x2_mul_ck {
> diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> index cb04d4b37e7f..df3c699a1893 100644
> --- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> @@ -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 {
>

[PATCH 6/8] ARM: dts: use ti, fixed-factor-clock for dpll4_m4x2_mul_ck

[Tero Kristo]

On 02/13/2014 12:04 PM, Tomi Valkeinen wrote:
> 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...?

-Tero

>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>   arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +-
>   arch/arm/boot/dts/omap3xxx-clocks.dtsi | 6 +++---
>   2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi b/arch/arm/boot/dts/omap36xx-clocks.dtsi
> index 0b2df76b9d38..6b5280d04a0e 100644
> --- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
> @@ -79,7 +79,7 @@
>   };
>
>   &dpll4_m4x2_mul_ck {
> -	clock-mult = <1>;
> +	ti,clock-mult = <1>;
>   };
>
>   &dpll4_m5x2_mul_ck {
> diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> index cb04d4b37e7f..df3c699a1893 100644
> --- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> @@ -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 {
>

Re: [PATCH 6/8] ARM: dts: use ti,fixed-factor-clock for dpll4_m4x2_mul_ck

[Tomi Valkeinen]

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

On 14/02/14 15:54, Tero Kristo wrote:
> On 02/13/2014 12:04 PM, Tomi Valkeinen wrote:
>> 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...?

Hmm, yes, I should mention that the flag itself is set in a following patch.

 Tomi



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

[PATCH 6/8] ARM: dts: use ti, fixed-factor-clock for dpll4_m4x2_mul_ck

[Tomi Valkeinen]

On 14/02/14 15:54, Tero Kristo wrote:
> On 02/13/2014 12:04 PM, Tomi Valkeinen wrote:
>> 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...?

Hmm, yes, I should mention that the flag itself is set in a following patch.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140214/bb600c28/attachment.sig>

[PATCH 7/8] ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path

[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).

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

diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
index df3c699a1893..12be2b35dae9 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -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 {
-- 
1.8.3.2

[PATCH 7/8] ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path

[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).

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

diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
index df3c699a1893..12be2b35dae9 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -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 {
-- 
1.8.3.2

Re: [PATCH 7/8] ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path

[Tero Kristo]

On 02/13/2014 12:04 PM, Tomi Valkeinen wrote:
> 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?

-Tero

>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>   arch/arm/boot/dts/omap3xxx-clocks.dtsi | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> index df3c699a1893..12be2b35dae9 100644
> --- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> @@ -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 {
>

[PATCH 7/8] ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path

[Tero Kristo]

On 02/13/2014 12:04 PM, Tomi Valkeinen wrote:
> 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?

-Tero

>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>   arch/arm/boot/dts/omap3xxx-clocks.dtsi | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> index df3c699a1893..12be2b35dae9 100644
> --- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> @@ -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 {
>

Re: [PATCH 7/8] ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path

[Tomi Valkeinen]

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

On 14/02/14 15:54, Tero Kristo wrote:
> On 02/13/2014 12:04 PM, Tomi Valkeinen wrote:
>> 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?

I got no problem with that, but I think it's cleaner to separate these
two things. #6 converts the clock to use a different driver, and by
having these separate, it's easier to see that #6 converts the node 1:1
without other functional change.

 Tomi



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

[PATCH 7/8] ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path

[Tomi Valkeinen]

On 14/02/14 15:54, Tero Kristo wrote:
> On 02/13/2014 12:04 PM, Tomi Valkeinen wrote:
>> 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?

I got no problem with that, but I think it's cleaner to separate these
two things. #6 converts the clock to use a different driver, and by
having these separate, it's easier to see that #6 converts the node 1:1
without other functional change.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140214/74d12cda/attachment.sig>

[PATCH 8/8] OMAPDSS: fix rounding when calculating fclk rate

[Tomi Valkeinen]

"clk: divider: fix rate calculation for fractional rates" patch (and
similar for TI specific divider) fixes the clk-divider's rounding. This
patch updates the DSS driver to round the rates accordingly.

This fixes the DSS's warnings about clock rate mismatch, and also fixes
the wrong fclk rate being set.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/dss.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 9a145da35ad3..efe7c308341d 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -471,7 +471,7 @@ bool dss_div_calc(unsigned long pck, unsigned long fck_min,
 	fckd_stop = max(DIV_ROUND_UP(prate * m, fck_hw_max), 1ul);
 
 	for (fckd = fckd_start; fckd >= fckd_stop; --fckd) {
-		fck = prate / fckd * m;
+		fck = DIV_ROUND_UP(prate, fckd) * m;
 
 		if (func(fck, data))
 			return true;
@@ -520,7 +520,7 @@ static int dss_setup_default_clock(void)
 
 		fck_div = DIV_ROUND_UP(prate * dss.feat->dss_fck_multiplier,
 				max_dss_fck);
-		fck = prate / fck_div * dss.feat->dss_fck_multiplier;
+		fck = DIV_ROUND_UP(prate, fck_div) * dss.feat->dss_fck_multiplier;
 	}
 
 	r = dss_set_fck_rate(fck);
-- 
1.8.3.2

[PATCH 8/8] OMAPDSS: fix rounding when calculating fclk rate

[Tomi Valkeinen]

"clk: divider: fix rate calculation for fractional rates" patch (and
similar for TI specific divider) fixes the clk-divider's rounding. This
patch updates the DSS driver to round the rates accordingly.

This fixes the DSS's warnings about clock rate mismatch, and also fixes
the wrong fclk rate being set.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/dss.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 9a145da35ad3..efe7c308341d 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -471,7 +471,7 @@ bool dss_div_calc(unsigned long pck, unsigned long fck_min,
 	fckd_stop = max(DIV_ROUND_UP(prate * m, fck_hw_max), 1ul);
 
 	for (fckd = fckd_start; fckd >= fckd_stop; --fckd) {
-		fck = prate / fckd * m;
+		fck = DIV_ROUND_UP(prate, fckd) * m;
 
 		if (func(fck, data))
 			return true;
@@ -520,7 +520,7 @@ static int dss_setup_default_clock(void)
 
 		fck_div = DIV_ROUND_UP(prate * dss.feat->dss_fck_multiplier,
 				max_dss_fck);
-		fck = prate / fck_div * dss.feat->dss_fck_multiplier;
+		fck = DIV_ROUND_UP(prate, fck_div) * dss.feat->dss_fck_multiplier;
 	}
 
 	r = dss_set_fck_rate(fck);
-- 
1.8.3.2

Re: [PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[Belisko Marek]

On Thu, Feb 13, 2014 at 11:03 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> 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.
Tested on gta04 board with DSS DT patches v3 (rebased on 3.14-rc2).
Panel is finally working fine.
Thanks.

Tested-by: Marek Belisko <marek@goldelico.com>

>
>  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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

BR,

marek

-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

[PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[Belisko Marek]

On Thu, Feb 13, 2014 at 11:03 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> 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.
Tested on gta04 board with DSS DT patches v3 (rebased on 3.14-rc2).
Panel is finally working fine.
Thanks.

Tested-by: Marek Belisko <marek@goldelico.com>

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

BR,

marek

-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

Re: [PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[Florian Vaussard]

Hi Tomi,

On 02/13/2014 11:03 AM, Tomi Valkeinen wrote:
> 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.
> 

I hit this issue when developing on top of 3.14-rc4, the DSS failed to
set fck. Your patches made the Overo (both OMAP35xx and OMAP36xx) to get
a working DVI output when booting via DT. And the board did not catch on
fire, contrary to what Mike hopped :)

Tested-by: Florian Vaussard <florian.vaussard@epfl.ch>

[PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[Florian Vaussard]

Hi Tomi,

On 02/13/2014 11:03 AM, Tomi Valkeinen wrote:
> 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.
> 

I hit this issue when developing on top of 3.14-rc4, the DSS failed to
set fck. Your patches made the Overo (both OMAP35xx and OMAP36xx) to get
a working DVI output when booting via DT. And the board did not catch on
fire, contrary to what Mike hopped :)

Tested-by: Florian Vaussard <florian.vaussard@epfl.ch>

Re: [PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[Tomi Valkeinen]

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

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

On 13/02/14 12:03, Tomi Valkeinen wrote:
> 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(-)
> 



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

[PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[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).

 Tomi

On 13/02/14 12:03, Tomi Valkeinen wrote:
> 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(-)
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140305/c929fbc3/attachment.sig>

Re: [PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[Tero Kristo]

On 03/05/2014 10:35 AM, Tomi Valkeinen wrote:
> 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.)

-Tero

>
>   Tomi
>
> On 13/02/14 12:03, Tomi Valkeinen wrote:
>> 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(-)
>>
>
>

[PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[Tero Kristo]

On 03/05/2014 10:35 AM, Tomi Valkeinen wrote:
> 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.)

-Tero

>
>   Tomi
>
> On 13/02/14 12:03, Tomi Valkeinen wrote:
>> 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(-)
>>
>
>

Re: [PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[Tomi Valkeinen]

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

On 05/03/14 12:12, Tero Kristo wrote:
> On 03/05/2014 10:35 AM, Tomi Valkeinen wrote:
>> 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.)

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?

 Tomi



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

[PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[Tomi Valkeinen]

On 05/03/14 12:12, Tero Kristo wrote:
> On 03/05/2014 10:35 AM, Tomi Valkeinen wrote:
>> 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.)

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?

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140305/76fc7352/attachment.sig>

Re: [PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140305 03:28]:
> On 05/03/14 12:12, Tero Kristo wrote:
> > On 03/05/2014 10:35 AM, Tomi Valkeinen wrote:
> >> 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.)
> 
> 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?

It's best that you take those four dts changes into your DSS branch.
They don't seem to conflict with anything I have queued, so:

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 0/8] OMAP: OMAP3 DSS related clock patches

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140305 03:28]:
> On 05/03/14 12:12, Tero Kristo wrote:
> > On 03/05/2014 10:35 AM, Tomi Valkeinen wrote:
> >> 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.)
> 
> 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?

It's best that you take those four dts changes into your DSS branch.
They don't seem to conflict with anything I have queued, so:

Acked-by: Tony Lindgren <tony@atomide.com>