Clock support for rk3066,rk3188 and rk3288

From: Boris BREZILLON <[email protected]>

In case the rate_hw does not implement determine_rate, but only round_rate we fallback to best_parent selection if mux_hw is present and support reparenting.

Signed-off-by Boris BREZILLON <[email protected]>

This also fixes a rate calculation problem when using the standard div and mux ops, as in this case currently only the mux->determine_rate is used in the composite rate calculation.
So when for example the composite clock has two parents at 600 and 800MHz, the requested rate is 75MHz, which the divider could provide, without this change the rate would be set 600MHz ignoring the divider completely. This may be way out of spec for the component.

[fixed the output to actually return a rate instead of the diff]

Signed-off-by Heiko Stuebner <[email protected]>

Acked-by Max Schwarz <[email protected]>

Tested-by Max Schwarz <[email protected]>

on a stih416 board

Tested-by Gabriel Fernandez <[email protected]>

---
Gabriel, I hope it is ok that I converted test-success to a Tested-by-Tag :-)

 drivers/clk/clk-composite.c | 48 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 47 insertions(+), 1 deletion(-)

drivers/clk/clk-composite.c +47 -2

index 57a078e..9548bfc 100644
@@ -64,11 +64,56 @@ static long clk_composite_determine_rate(struct clk_hw *hw, unsigned long rate,
        const struct clk_ops *mux_ops = composite->mux_ops;
        struct clk_hw *rate_hw = composite->rate_hw;
        struct clk_hw *mux_hw = composite->mux_hw;
+       struct clk *parent;
+       unsigned long parent_rate;
+       long tmp_rate, best_rate = 0;
+       unsigned long rate_diff;
+       unsigned long best_rate_diff = ULONG_MAX;
+       int i;
 
        if (rate_hw && rate_ops && rate_ops->determine_rate) {
                rate_hw->clk = hw->clk;
                return rate_ops->determine_rate(rate_hw, rate, best_parent_rate,
                                                best_parent_p);
+       } else if (rate_hw && rate_ops && rate_ops->round_rate &&
+                  mux_hw && mux_ops && mux_ops->set_parent) {
+               *best_parent_p = NULL;
+
+               if (__clk_get_flags(hw->clk) & CLK_SET_RATE_NO_REPARENT) {
+                       *best_parent_p = clk_get_parent(mux_hw->clk);
+                       *best_parent_rate = __clk_get_rate(*best_parent_p);
+
+                       return rate_ops->round_rate(rate_hw, rate,
+                                                   best_parent_rate);
+               }
+
+               for (i = 0; i < __clk_get_num_parents(mux_hw->clk); i++) {
+                       parent = clk_get_parent_by_index(mux_hw->clk, i);
+                       if (!parent)
+                               continue;
+
+                       parent_rate = __clk_get_rate(parent);
+
+                       tmp_rate = rate_ops->round_rate(rate_hw, rate,
+                                                       &parent_rate);
+                       if (tmp_rate < 0)
+                               continue;
+
+                       rate_diff = abs(rate - tmp_rate);
+
+                       if (!rate_diff || !*best_parent_p
+                                      || best_rate_diff > rate_diff) {
+                               *best_parent_p = parent;
+                               *best_parent_rate = parent_rate;
+                               best_rate_diff = rate_diff;
+                               best_rate = tmp_rate;
+                       }
+
+                       if (!rate_diff)
+                               return rate;
+               }
+
+               return best_rate;
        } else if (mux_hw && mux_ops && mux_ops->determine_rate) {
                mux_hw->clk = hw->clk;
                return mux_ops->determine_rate(mux_hw, rate, best_parent_rate,

@@ -196,7 +241,8 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
                composite->rate_hw = rate_hw;
                composite->rate_ops = rate_ops;
                clk_composite_ops->recalc_rate = clk_composite_recalc_rate;
-               if (rate_ops->determine_rate)
+               if (rate_ops->determine_rate ||
+                   (rate_ops->round_rate && clk_composite_ops->set_parent))
                        clk_composite_ops->determine_rate = clk_composite_determine_rate;
        }
 
--

1.9.0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Hi Heiko,
Sorry for the delay...

I have tested your patch with below cases.

                   -----

CH0 -----------+--| | ----- CLK1

               |  | MUX |-------| DIV |-----

CH1 ----+---------| | -----

        |      |   -----
        |      |   
        |      |   -----
        |      
        |      +--|     |        -----    CLK2
        |      
        |      |  | MUX |-------| DIV |-----

        +---------|     |        -----

        |      |   -----
        |      |   
        |      |   -----
        |      
        |      +--|     |        -----    CLK3
        |      
        |         | MUX |-------| DIV |-----

        +---------|     |        -----

                   -----

CH0 = 297000000 Hz
CH1 = 148352000 Hz

i set:
CLK1 -> 297000000
CLK2 -> 148352000
CLK3 -> 148352000/2

I was a little confused first time because CLK1,CLK2,CL3 had the clk_flags set to CLK_SET_RATE_PARENT.

result
set rate CLK1 -> 297000000
---> CLK1 = 297000000 (parent CH0)

set rate CLK2 -> 148352000
---> CLK1 = 297000000 (parent CH0)
---> CLK2 = 148352000 (parent CH1)

set rate CLK3 -> 148352000/2
---> CLK1 = 148352000/2 (parent CH0)
---> CLK2 = 148352000 (parent CH1)
---> CLK3 = 148352000/2 (parent CH0)

We try to find the best parent but without considering the DIV... For me output clocks are not at all predictable in this case. what is your feeling about that ? is it a true probleme or a bad use case ?

If clk_flags NOT set to CLK_SET_RATE_PARENT it's ok for me

result
set rate CLK1 -> 297000000
---> CLK1 = 297000000 (parent CH0)

set rate CLK2 -> 148352000
---> CLK1 = 297000000 (parent CH0)
---> CLK2 = 148352000 (parent CH1)

set rate CLK3 -> 148352000/2
---> CLK1 = 297000000 (parent CH0)
---> CLK2 = 148352000 (parent CH1)
---> CLK3 = 148352000/2 (parent CH0)

Quoted 127 lines

From: Boris BREZILLON <[email protected]>

In case the rate_hw does not implement determine_rate, but only round_rate we fallback to best_parent selection if mux_hw is present and support reparenting.

Signed-off-by Boris BREZILLON <[email protected]>

This also fixes a rate calculation problem when using the standard div and mux ops, as in this case currently only the mux->determine_rate is used in the composite rate calculation.
So when for example the composite clock has two parents at 600 and 800MHz, the requested rate is 75MHz, which the divider could provide, without this change the rate would be set 600MHz ignoring the divider completely. This may be way out of spec for the component.

[fixed the output to actually return a rate instead of the diff]

Signed-off-by Heiko Stuebner <[email protected]>

Acked-by Max Schwarz <[email protected]>

Tested-by Max Schwarz <[email protected]>

on a stih416 board

Tested-by Gabriel Fernandez <[email protected]>

---
Gabriel, I hope it is ok that I converted test-success to a Tested-by-Tag :-)>

 drivers/clk/clk-composite.c | 48

++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 47 insertions(+), 1 deletion(-)

drivers/clk/clk-composite.c +13 -0

index 57a078e..9548bfc 100644
@@ -64,11 +64,56 @@ static long clk_composite_determine_rate(struct clk_hw
 *hw, unsigned long rate,> 
        const struct clk_ops *mux_ops = composite->mux_ops;
        struct clk_hw *rate_hw = composite->rate_hw;
        struct clk_hw *mux_hw = composite->mux_hw;
 
+       struct clk *parent;
+       unsigned long parent_rate;
+       long tmp_rate, best_rate = 0;
+       unsigned long rate_diff;
+       unsigned long best_rate_diff = ULONG_MAX;
+       int i;
 
        if (rate_hw && rate_ops && rate_ops->determine_rate) {
 
                rate_hw->clk = hw->clk;
                return rate_ops->determine_rate(rate_hw, rate,
                best_parent_rate,
 
                                                best_parent_p);
 
+       } else if (rate_hw && rate_ops && rate_ops->round_rate &&
+                  mux_hw && mux_ops && mux_ops->set_parent) {
+               *best_parent_p = NULL;
+
+               if (__clk_get_flags(hw->clk) & CLK_SET_RATE_NO_REPARENT) {
+                       *best_parent_p = clk_get_parent(mux_hw->clk);
+                       *best_parent_rate =

__clk_get_rate(*best_parent_p);

drivers/clk/clk-composite.c +32 -0

+
+                       return rate_ops->round_rate(rate_hw, rate,
+                                                   best_parent_rate);
+               }
+
+               for (i = 0; i < __clk_get_num_parents(mux_hw->clk); i++) {
+                       parent = clk_get_parent_by_index(mux_hw->clk, i);
+                       if (!parent)
+                               continue;
+
+                       parent_rate = __clk_get_rate(parent);
+
+                       tmp_rate = rate_ops->round_rate(rate_hw, rate,
+                                                       &parent_rate);
+                       if (tmp_rate < 0)
+                               continue;
+
+                       rate_diff = abs(rate - tmp_rate);
+
+                       if (!rate_diff || !*best_parent_p
+                                      || best_rate_diff > rate_diff) {
+                               *best_parent_p = parent;
+                               *best_parent_rate = parent_rate;
+                               best_rate_diff = rate_diff;
+                               best_rate = tmp_rate;
+                       }
+
+                       if (!rate_diff)
+                               return rate;
+               }
+
+               return best_rate;
 
        } else if (mux_hw && mux_ops && mux_ops->determine_rate) {
 
                mux_hw->clk = hw->clk;
                return mux_ops->determine_rate(mux_hw, rate,
                best_parent_rate,

@@ -196,7 +241,8 @@ struct clk *clk_register_composite(struct device *dev,

const char *name,>

                composite->rate_hw = rate_hw;
                composite->rate_ops = rate_ops;
                clk_composite_ops->recalc_rate =
                clk_composite_recalc_rate;

drivers/clk/clk-composite.c +2 -1

-               if (rate_ops->determine_rate)
+               if (rate_ops->determine_rate ||
+                   (rate_ops->round_rate &&

clk_composite_ops->set_parent))>

                        clk_composite_ops->determine_rate =
                        clk_composite_determine_rate;
        
        }

--
1.9.0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

This series adds a clock driver infrastructure for Rockchip SoCs in general and clock-definitions for the RK3188 and RK3288 in particular.

Apart from the arch/arm patches included here, there are some more in the waiting line, like adding the i2c nodes and possibly the pwm, i2s and spi nodes if the relevant drivers get accepted, where the ids defined in the dt-binding headers are needed.

So if the whole thing is acceptable could we either offer a branch from the clk-tree that can get merged or take the whole series through the arm tree?

changes since v4.2:
- fix uninitialized compiler warning in patch4
- add cleanup patch for clk-composite from Mike Turquette
- fix some softrst-issues in patch6
changes since v4.1:
- forgot the From override, Boris is the original author changes since v4:
- address comments from Gabriel Fernandez
- use abs()
- init best_rate
changes since v3:
- add rk3288 clock controller
- add reset controller ids
- fix some incorrect values in rk3188-cru and export some more clocks
- fold new rk3066 clock tree into the rk3188 one, as can be easily seen the differences are not really big between them
- expand the composite fix description to highlight the underlying issue changes since v2:
- drop the special cpuclk type until coordinated range changes matured, as mentioned in the Samsung cpufreq thread.
- add the patch from Boris BREZILLON that reenables correct rate calculations in composite clocks
- change pll handling to better handle the pll output mux and also the enabling/disabling of the pll clock
- change core code to handle composite clock branches instead of individual basic clock definitions
- use the newly defined GRF syscon instead of mapping a grf register individually
changes since v1:
- adapt to apply on current clk-next branch
- add saradc clock
- add rk3188a cru, which has a slightly different handling of one pll value (bwadj)

Boris BREZILLON (1):
clk: composite: support determine_rate using rate_ops->round_rate +

    mux_ops->set_parent

Heiko Stuebner (12):
clk: composite: allow read-only clocks
clk: rockchip: add basic infrastructure for clock branches
clk: rockchip: add clock type for pll clocks and pll used on rk3066
clk: rockchip: add reset controller
dt-bindings: add documentation for rk3188 clock and reset unit
clk: rockchip: add clock driver for rk3188 and rk3066 clocks
dt-bindings: add documentation for rk3288 cru
clk: rockchip: add clock controller for rk3288
ARM: rockchip: Select ARCH_HAS_RESET_CONTROLLER
ARM: dts: rockchip: add cru nodes and update device clocks to use it
ARM: dts: rockchip: move oscillator input clock into main dtsi
arm: dts: rockchip: remove obsolete clock gate definitions

Mike Turquette (1):
clk: composite: improve rate_hw sanity check logic

 .../bindings/clock/rockchip,rk3188-cru.txt         |  61 ++
 .../bindings/clock/rockchip,rk3288-cru.txt         |  61 ++
 .../devicetree/bindings/clock/rockchip.txt         |   3 +
 arch/arm/boot/dts/rk3066a-clocks.dtsi              | 299 ---------
 arch/arm/boot/dts/rk3066a.dtsi                     |  30 +-
 arch/arm/boot/dts/rk3188-clocks.dtsi               | 289 ---------
 arch/arm/boot/dts/rk3188.dtsi                      |  19 +-
 arch/arm/boot/dts/rk3xxx.dtsi                      |  22 +-
 arch/arm/mach-rockchip/Kconfig                     |   1 +
 drivers/clk/clk-composite.c                        |  79 ++-
 drivers/clk/rockchip/Makefile                      |   6 +
 drivers/clk/rockchip/clk-pll.c                     | 431 +++++++++++++
 drivers/clk/rockchip/clk-rk3188.c                  | 672 +++++++++++++++++++
 drivers/clk/rockchip/clk-rk3288.c                  | 717 +++++++++++++++++++++
 drivers/clk/rockchip/clk.c                         | 244 +++++++
 drivers/clk/rockchip/clk.h                         | 347 ++++++++++
 drivers/clk/rockchip/softrst.c                     | 118 ++++
 include/dt-bindings/clock/rk3066a-cru.h            |  35 +
 include/dt-bindings/clock/rk3188-cru-common.h      | 249 +++++++
 include/dt-bindings/clock/rk3188-cru.h             |  51 ++
 include/dt-bindings/clock/rk3288-cru.h             | 278 ++++++++
 21 files changed, 3386 insertions(+), 626 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.txt
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt
 delete mode 100644 arch/arm/boot/dts/rk3066a-clocks.dtsi
 delete mode 100644 arch/arm/boot/dts/rk3188-clocks.dtsi
 create mode 100644 drivers/clk/rockchip/clk-pll.c
 create mode 100644 drivers/clk/rockchip/clk-rk3188.c
 create mode 100644 drivers/clk/rockchip/clk-rk3288.c
 create mode 100644 drivers/clk/rockchip/clk.c
 create mode 100644 drivers/clk/rockchip/clk.h
 create mode 100644 drivers/clk/rockchip/softrst.c
 create mode 100644 include/dt-bindings/clock/rk3066a-cru.h
 create mode 100644 include/dt-bindings/clock/rk3188-cru-common.h
 create mode 100644 include/dt-bindings/clock/rk3188-cru.h
 create mode 100644 include/dt-bindings/clock/rk3288-cru.h

Signature · 1 line

1.9.0

Quoting Heiko St?bner (2014-07-02 16:53:24)

Quoted 11 lines

This series adds a clock driver infrastructure for Rockchip SoCs in general and clock-definitions for the RK3188 and RK3288 in particular.

Apart from the arch/arm patches included here, there are some more in the waiting line, like adding the i2c nodes and possibly the pwm, i2s and spi nodes if the relevant drivers get accepted, where the ids defined in the dt-binding headers are needed.

So if the whole thing is acceptable could we either offer a branch from the clk-tree that can get merged or take the whole series through the arm tree?

Heiko,

This version looks good. I've pushed a branch with all 14 of these patches based on 3.16-rc3 to the clk tree. See:

git://git.linaro.org/people/mike.turquette/linux.git clk-rockchip

If everyone is OK to merge that stable branch then I will merge clk-rockchip into clk-next and we're all good. If the arm-soc guys want to carve it up a bit further or handle it in a different way then we can do that. I've Cc'd arm-soc for clarification.

Hi,

On Sun, Jul 13, 2014 at 12:46 PM, Mike Turquette <[email protected]>

Quoted 19 lines

Quoting Heiko St?bner (2014-07-02 16:53:24)

Quoted 11 lines

This series adds a clock driver infrastructure for Rockchip SoCs in general and clock-definitions for the RK3188 and RK3288 in particular.

Apart from the arch/arm patches included here, there are some more in the waiting line, like adding the i2c nodes and possibly the pwm, i2s and spi nodes if the relevant drivers get accepted, where the ids defined in the dt-binding headers are needed.

So if the whole thing is acceptable could we either offer a branch from the clk-tree that can get merged or take the whole series through the arm tree?

Heiko,

This version looks good. I've pushed a branch with all 14 of these patches based on 3.16-rc3 to the clk tree. See:

Quoted 6 lines

git://git.linaro.org/people/mike.turquette/linux.git clk-rockchip

If everyone is OK to merge that stable branch then I will merge clk-rockchip into clk-next and we're all good. If the arm-soc guys want to carve it up a bit further or handle it in a different way then we can do that. I've Cc'd arm-soc for clarification.

Traditionally we usually take the DT changes through arm-soc, but as long as we share the branch we might be ok. We tend to stick them in different branches in our tree though, so rockchip will be a little mis-sorted this release. Not a big deal, and we can deal with it.

So, I'll leave it to Heiko to choose here, he knows best what other DT changes are coming this release. If he wants to carry the DT changes separately, then patches 1-10 would be for the clk tree, so it should be easy to reset the branch back a bit (and 11-14 would be for arm-soc).

Hi Olof,

Am Sonntag, 13. Juli 2014, 20:12:07 schrieb Olof Johansson:

Quoted 3 lines

Hi,

On Sun, Jul 13, 2014 at 12:46 PM, Mike Turquette <[email protected]>

Quoted 32 lines · wrote:

Quoted 20 lines

Quoting Heiko St?bner (2014-07-02 16:53:24)

Quoted 9 lines

This series adds a clock driver infrastructure for Rockchip SoCs in general and clock-definitions for the RK3188 and RK3288 in particular.

Apart from the arch/arm patches included here, there are some more in the waiting line, like adding the i2c nodes and possibly the pwm, i2s
and spi nodes if the relevant drivers get accepted, where the ids defined in the dt-binding headers are needed.

Quoted 3 lines

So if the whole thing is acceptable could we either offer a branch from the clk-tree that can get merged or take the whole series through the arm tree?

Heiko,

This version looks good. I've pushed a branch with all 14 of these patches based on 3.16-rc3 to the clk tree. See:

Quoted 6 lines

git://git.linaro.org/people/mike.turquette/linux.git clk-rockchip

If everyone is OK to merge that stable branch then I will merge clk-rockchip into clk-next and we're all good. If the arm-soc guys want to carve it up a bit further or handle it in a different way then we can do that. I've Cc'd arm-soc for clarification.

Traditionally we usually take the DT changes through arm-soc, but as long as we share the branch we might be ok. We tend to stick them in different branches in our tree though, so rockchip will be a little mis-sorted this release. Not a big deal, and we can deal with it.

Quoted 5 lines

So, I'll leave it to Heiko to choose here, he knows best what other DT changes are coming this release. If he wants to carry the DT changes separately, then patches 1-10 would be for the clk tree, so it should be easy to reset the branch back a bit (and 11-14 would be for arm-soc).

hmm, there are essentially two changeset/branches upcoming:
- the collected dts changes for rk3066 and rk3188 I posted saturday These essentially extend patches 12-14
- rk3288 support which would start off patch 11 (the reset controller)

So if we were to separate the series I would say patches 1-11 in the shared branch and patch 12-14 as the first ones for a rk3066/rk3188 specific branch.

Hi Mike,

Am Montag, 14. Juli 2014, 10:07:01 schrieb Heiko St?bner:

Quoted 46 lines

Hi Olof,

Am Sonntag, 13. Juli 2014, 20:12:07 schrieb Olof Johansson:

Quoted 3 lines

Hi,

On Sun, Jul 13, 2014 at 12:46 PM, Mike Turquette <[email protected]>

Quoted 32 lines · wrote:

Quoted 20 lines

Quoting Heiko St?bner (2014-07-02 16:53:24)

Quoted 9 lines

This series adds a clock driver infrastructure for Rockchip SoCs in general and clock-definitions for the RK3188 and RK3288 in particular.

Apart from the arch/arm patches included here, there are some more in the waiting line, like adding the i2c nodes and possibly the pwm, i2s
and spi nodes if the relevant drivers get accepted, where the ids defined in the dt-binding headers are needed.

Quoted 3 lines

So if the whole thing is acceptable could we either offer a branch from the clk-tree that can get merged or take the whole series through the arm tree?

Heiko,

This version looks good. I've pushed a branch with all 14 of these patches based on 3.16-rc3 to the clk tree. See:

Quoted 6 lines

git://git.linaro.org/people/mike.turquette/linux.git clk-rockchip

If everyone is OK to merge that stable branch then I will merge clk-rockchip into clk-next and we're all good. If the arm-soc guys want to carve it up a bit further or handle it in a different way then we can do that. I've Cc'd arm-soc for clarification.

Traditionally we usually take the DT changes through arm-soc, but as long as we share the branch we might be ok. We tend to stick them in different branches in our tree though, so rockchip will be a little mis-sorted this release. Not a big deal, and we can deal with it.

Quoted 5 lines

So, I'll leave it to Heiko to choose here, he knows best what other DT changes are coming this release. If he wants to carry the DT changes separately, then patches 1-10 would be for the clk tree, so it should be easy to reset the branch back a bit (and 11-14 would be for arm-soc).

Quoted 8 lines

hmm, there are essentially two changeset/branches upcoming:
- the collected dts changes for rk3066 and rk3188 I posted saturday These essentially extend patches 12-14
- rk3288 support which would start off patch 11 (the reset controller)

So if we were to separate the series I would say patches 1-11 in the shared branch and patch 12-14 as the first ones for a rk3066/rk3188 specific branch.

are you ok with simply resetting the clk-rockchip branch to
"ARM: rockchip: Select ARCH_HAS_RESET_CONTROLLER"
being the last commit and the last 3 patches going through arm-soc?

As we're already at -rc6 now, it would be very cool if we could get this sorted soon.

Thanks
Heiko