SPEAr: Move to common clock framework

CLK_GATE_SET_TO_DISABLE is mistakenly written as CLK_GATE_SET_DISABLE in comment. Fix it.

Signed-off-by Viresh Kumar <[email protected]>

---
?include/linux/clk-provider.h | ? ?2 +-
?1 files changed, 1 insertions(+), 1 deletions(-)

include/linux/clk-provider.h +0 -0

index 50ee80b..d98bdbc 100644
@@ -166,7 +166,7 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,

?* Clock which can gate its output. ?Implements .enable & .disable ?*
?* Flags:
- * CLK_GATE_SET_DISABLE - by default this clock sets the bit at bit_idx to
+ * CLK_GATE_SET_TO_DISABLE - by default this clock sets the bit at bit_idx to ?* ? ? enable the clock. ?Setting this flag does the opposite: setting the bit ?* ? ? disable the clock and clearing it enables the clock
?*/
--
1.7.9

All macros used for creating different kind of clocks have similar code for initializing struct clk. This patch removes those redundant lines and create another macro DEFINE_CLK.

Signed-off-by Viresh Kumar <[email protected]>

---
?include/linux/clk-private.h | ? 59 ++++++++++++++---------------------------- ?1 files changed, 20 insertions(+), 39 deletions(-)

include/linux/clk-private.h +0 -0

index e7032fd..eeae7a3 100644
@@ -55,6 +55,18 @@ struct clk {

?* alternative macro for static initialization
?*/

include/linux/clk-private.h +12 -0

+#define DEFINE_CLK(_name, _ops, _flags, _parent_names, ? ? ? ? \
+ ? ? ? ? ? ? ? _parents) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
+ ? ? ? static struct clk _name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
+ ? ? ? ? ? ? ? .name = #_name, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
+ ? ? ? ? ? ? ? .ops = &_ops, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
+ ? ? ? ? ? ? ? .hw = &_name##_hw.hw, ? ? ? ? ? ? ? ? ? ? ? ? ? \
+ ? ? ? ? ? ? ? .parent_names = _parent_names, ? ? ? ? ? ? ? ? ?\
+ ? ? ? ? ? ? ? .num_parents = ARRAY_SIZE(_parent_names), ? ? ? \
+ ? ? ? ? ? ? ? .parents = _parents, ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
+ ? ? ? ? ? ? ? .flags = _flags, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
+ ? ? ? }
+

?#define DEFINE_CLK_FIXED_RATE(_name, _flags, _rate, ? ? ? ? ? ?\
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?_fixed_rate_flags) ? ? ? ? ? ? ?\
? ? ? ?static struct clk _name; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\

include/linux/clk-private.h +8 -39

@@ -66,15 +78,8 @@ struct clk {
 ? ? ? ? ? ? ? ?.fixed_rate = _rate, ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
 ? ? ? ? ? ? ? ?.flags = _fixed_rate_flags, ? ? ? ? ? ? ? ? ? ? \
 ? ? ? ?}; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? static struct clk _name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .name = #_name, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .ops = &clk_fixed_rate_ops, ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .hw = &_name##_hw.hw, ? ? ? ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .parent_names = _name##_parent_names, ? ? ? ? ? \
- ? ? ? ? ? ? ? .num_parents = ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? ? ? ? ? ? ? ? ? ARRAY_SIZE(_name##_parent_names), ? ? ? \
- ? ? ? ? ? ? ? .flags = _flags, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? };
+ ? ? ? DEFINE_CLK(_name, clk_fixed_rate_ops, _flags, ? ? ? ? ? \
+ ? ? ? ? ? ? ? ? ? ? ? _name##_parent_names, NULL);
 
 ?#define DEFINE_CLK_GATE(_name, _parent_name, _parent_ptr, ? ? ?\
 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?_flags, _reg, _bit_idx, ? ? ? ? \

@@ -95,16 +100,8 @@ struct clk {
 ? ? ? ? ? ? ? ?.flags = _gate_flags, ? ? ? ? ? ? ? ? ? ? ? ? ? \
 ? ? ? ? ? ? ? ?.lock = _lock, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
 ? ? ? ?}; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? static struct clk _name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .name = #_name, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .ops = &clk_gate_ops, ? ? ? ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .hw = &_name##_hw.hw, ? ? ? ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .parent_names = _name##_parent_names, ? ? ? ? ? \
- ? ? ? ? ? ? ? .num_parents = ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? ? ? ? ? ? ? ? ? ARRAY_SIZE(_name##_parent_names), ? ? ? \
- ? ? ? ? ? ? ? .parents = _name##_parents, ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .flags = _flags, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? };
+ ? ? ? DEFINE_CLK(_name, clk_gate_ops, _flags, ? ? ? ? ? ? ? ? \
+ ? ? ? ? ? ? ? ? ? ? ? _name##_parent_names, _name##_parents);
 
 ?#define DEFINE_CLK_DIVIDER(_name, _parent_name, _parent_ptr, ? \
 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?_flags, _reg, _shift, _width, ? \

@@ -126,16 +123,8 @@ struct clk {
 ? ? ? ? ? ? ? ?.flags = _divider_flags, ? ? ? ? ? ? ? ? ? ? ? ?\
 ? ? ? ? ? ? ? ?.lock = _lock, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
 ? ? ? ?}; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? static struct clk _name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .name = #_name, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .ops = &clk_divider_ops, ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? ? ? ? ? .hw = &_name##_hw.hw, ? ? ? ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .parent_names = _name##_parent_names, ? ? ? ? ? \
- ? ? ? ? ? ? ? .num_parents = ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? ? ? ? ? ? ? ? ? ARRAY_SIZE(_name##_parent_names), ? ? ? \
- ? ? ? ? ? ? ? .parents = _name##_parents, ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .flags = _flags, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? };
+ ? ? ? DEFINE_CLK(_name, clk_divider_ops, _flags, ? ? ? ? ? ? ?\
+ ? ? ? ? ? ? ? ? ? ? ? _name##_parent_names, _name##_parents);
 
 ?#define DEFINE_CLK_MUX(_name, _parent_names, _parents, _flags, \
 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?_reg, _shift, _width, ? ? ? ? ? \

@@ -151,16 +140,8 @@ struct clk {
 ? ? ? ? ? ? ? ?.flags = _mux_flags, ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
 ? ? ? ? ? ? ? ?.lock = _lock, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
 ? ? ? ?}; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? static struct clk _name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .name = #_name, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .ops = &clk_mux_ops, ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? ? ? ? ? .hw = &_name##_hw.hw, ? ? ? ? ? ? ? ? ? ? ? ? ? \
- ? ? ? ? ? ? ? .parent_names = _parent_names, ? ? ? ? ? ? ? ? ?\
- ? ? ? ? ? ? ? .num_parents = ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? ? ? ? ? ? ? ? ? ARRAY_SIZE(_parent_names), ? ? ? ? ? ? ?\
- ? ? ? ? ? ? ? .parents = _parents, ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? ? ? ? ? .flags = _flags, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
- ? ? ? };
+ ? ? ? DEFINE_CLK(_name, clk_mux_ops, _flags, _parent_names, ? \
+ ? ? ? ? ? ? ? ? ? ? ? _parents);
 

?/**
?* __clk_init - initialize the data structures in a struct clk --
1.7.9

This patch tries to remove duplicate code for clk_gate clocks. This creates another routine clk_gate_endisable() which will take care of enable/disable clock with knowledge of CLK_GATE_SET_TO_DISABLE flag.

It works on following logic:

For enabling clock, enable = 1
? ? ? ?set2dis = 1 ? ? -> clear bit ? ?-> set = 0
? ? ? ?set2dis = 0 ? ? -> set bit ? ? ?-> set = 1

For disabling clock, enable = 0
? ? ? ?set2dis = 1 ? ? -> set bit ? ? ?-> set = 1
? ? ? ?set2dis = 0 ? ? -> clear bit ? ?-> set = 0

So, result is always: enable xor set2dis.

Signed-off-by Viresh Kumar <[email protected]>

---
?drivers/clk/clk-gate.c | ? 54 ++++++++++++++++++++++------------------------- ?1 files changed, 25 insertions(+), 29 deletions(-)

drivers/clk/clk-gate.c +25 -30

index 288fb5e..f8d70b5 100644
@@ -28,32 +28,38 @@
 
 ?#define to_clk_gate(_hw) container_of(_hw, struct clk_gate, hw)
 
-static void clk_gate_set_bit(struct clk_gate *gate)
+/*
+ * It works on following logic:
+ *
+ * For enabling clock, enable = 1
+ * ? ? set2dis = 1 ? ? -> clear bit ? ?-> set = 0
+ * ? ? set2dis = 0 ? ? -> set bit ? ? ?-> set = 1
+ *
+ * For disabling clock, enable = 0
+ * ? ? set2dis = 1 ? ? -> set bit ? ? ?-> set = 1
+ * ? ? set2dis = 0 ? ? -> clear bit ? ?-> set = 0
+ *
+ * So, result is always: enable xor set2dis.
+ */
+static void clk_gate_endisable(struct clk_hw *hw, int enable)
 ?{
- ? ? ? u32 reg;
+ ? ? ? struct clk_gate *gate = to_clk_gate(hw);
+ ? ? ? int set = gate->flags & CLK_GATE_SET_TO_DISABLE ? 1 : 0;
 ? ? ? ?unsigned long flags = 0;
+ ? ? ? u32 reg;
+
+ ? ? ? set ^= enable;
 
 ? ? ? ?if (gate->lock)
 ? ? ? ? ? ? ? ?spin_lock_irqsave(gate->lock, flags);
 
 ? ? ? ?reg = readl(gate->reg);
- ? ? ? reg |= BIT(gate->bit_idx);
- ? ? ? writel(reg, gate->reg);
-
- ? ? ? if (gate->lock)
- ? ? ? ? ? ? ? spin_unlock_irqrestore(gate->lock, flags);
-}
-
-static void clk_gate_clear_bit(struct clk_gate *gate)
-{
- ? ? ? u32 reg;
- ? ? ? unsigned long flags = 0;
 
- ? ? ? if (gate->lock)
- ? ? ? ? ? ? ? spin_lock_irqsave(gate->lock, flags);
+ ? ? ? if (set)
+ ? ? ? ? ? ? ? reg |= BIT(gate->bit_idx);
+ ? ? ? else
+ ? ? ? ? ? ? ? reg &= ~BIT(gate->bit_idx);
 
- ? ? ? reg = readl(gate->reg);
- ? ? ? reg &= ~BIT(gate->bit_idx);
 ? ? ? ?writel(reg, gate->reg);
 
 ? ? ? ?if (gate->lock)

@@ -62,24 +68,14 @@ static void clk_gate_clear_bit(struct clk_gate *gate)
 
 ?static int clk_gate_enable(struct clk_hw *hw)
 ?{
- ? ? ? struct clk_gate *gate = to_clk_gate(hw);
-
- ? ? ? if (gate->flags & CLK_GATE_SET_TO_DISABLE)
- ? ? ? ? ? ? ? clk_gate_clear_bit(gate);
- ? ? ? else
- ? ? ? ? ? ? ? clk_gate_set_bit(gate);
+ ? ? ? clk_gate_endisable(hw, 1);
 
 ? ? ? ?return 0;
 ?}
 
 ?static void clk_gate_disable(struct clk_hw *hw)
 ?{
- ? ? ? struct clk_gate *gate = to_clk_gate(hw);
-
- ? ? ? if (gate->flags & CLK_GATE_SET_TO_DISABLE)
- ? ? ? ? ? ? ? clk_gate_set_bit(gate);
- ? ? ? else
- ? ? ? ? ? ? ? clk_gate_clear_bit(gate);
+ ? ? ? clk_gate_endisable(hw, 0);
 ?}
 
 ?static int clk_gate_is_enabled(struct clk_hw *hw)
--

1.7.9

if (!clk->ops->round_rate && (clk->flags & CLK_SET_RATE_PARENT)) is true, then we don't need to set clk->new_rate here, as we will call clk_calc_subtree() afterwards and it also sets clk->new_rate.

Signed-off-by Viresh Kumar <[email protected]>

---
?drivers/clk/clk.c | ? ?2 +-
?1 files changed, 1 insertions(+), 1 deletions(-)

drivers/clk/clk.c +1 -2

index af2bf12..865d0dd 100644
@@ -789,7 +789,7 @@ static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate)
 
 ? ? ? ?if (!clk->ops->round_rate) {
 ? ? ? ? ? ? ? ?top = clk_calc_new_rates(clk->parent, rate);
- ? ? ? ? ? ? ? new_rate = clk->new_rate = clk->parent->new_rate;
+ ? ? ? ? ? ? ? new_rate = clk->parent->new_rate;
 
 ? ? ? ? ? ? ? ?goto out;
 ? ? ? ?}
--

1.7.9

All SPEAr SoC's contain Auxiliary Synthesizers. Their Fout is derived based on values of eq, x and y.

arch/arm/plat-spear/clk-aux-synth.c new file +5 -0

+static unsigned long clk_aux_recalc_rate(struct clk_hw *hw,
+		unsigned long parent_rate)
+{
+	struct clk_aux *aux = to_clk_aux(hw);
+	unsigned int num = 1, den = 1, val, eqn;

arch/arm/plat-spear/clk-aux-synth.c new file +9 -0

+struct clk *clk_register_aux(const char *aux_name, const char *gate_name,
+		const char *parent_name, unsigned long flags, void __iomem *reg,
+		struct aux_clk_masks *masks, struct aux_rate_tbl *rtbl,
+		u8 rtbl_cnt, spinlock_t *lock, struct clk **gate_clk)
+{
+	struct clk_aux *aux;
+	struct clk *clk, *tgate_clk;
+
+	if (!aux_name || !gate_name || !parent_name || !reg || !rtbl ||

Quoted 7 lines

arch/arm/plat-spear/clk-aux-synth.c new file +7 -0

+{
+     struct clk_aux *aux = to_clk_aux(hw);
+     unsigned int num = 1, den = 1, val, eqn;
+     unsigned long flags = 0;
+
+     if (aux->lock)
+             spin_lock_irqsave(aux->lock, flags);

arch/arm/plat-spear/clk-aux-synth.c line 90

Quoted 6 lines

arch/arm/plat-spear/clk-aux-synth.c new file +6 -0

+
+     val = readl_relaxed(aux->reg);
+
+     if (aux->lock)
+             spin_unlock_irqrestore(aux->lock, flags);
+

A single read is atomic and needs no lock.

Quoted 7 lines · Sascha Hauer

Quoted 7 lines

arch/arm/plat-spear/clk-aux-synth.c new file +7 -0

+{
+     struct clk_aux *aux = to_clk_aux(hw);
+     unsigned int num = 1, den = 1, val, eqn;
+     unsigned long flags = 0;
+
+     if (aux->lock)
+             spin_lock_irqsave(aux->lock, flags);

Quoted 8 lines

arch/arm/plat-spear/clk-aux-synth.c line 90

Quoted 6 lines

arch/arm/plat-spear/clk-aux-synth.c new file +6 -0

+
+     val = readl_relaxed(aux->reg);
+
+     if (aux->lock)
+             spin_unlock_irqrestore(aux->lock, flags);
+

A single read is atomic and needs no lock.

That depends on whether the read has any side-effects. There is another function that does a read-modify-write on the same register, and you might need to prevent this one from reading the register between the other read and the following write.

The spinlock also has the benefit of enforcing the ordering of the read with regard to your instruction stream, otherwise it can be delayed on out-of-order CPUs until the value is actually used.

With common clock framework, it is must to call clk_{un}prepare() before/after

clk_{dis}enable. This patch fixes this for SPEAr timer.

Signed-off-by Viresh Kumar<[email protected]>

With common clock framework, it is must to call clk_{un}prepare() before/after clk_{dis}enable. This patch fixes this for SPEAr timer.

Signed-off-by Viresh Kumar <[email protected]>

---
?arch/arm/plat-spear/time.c | ? ?8 ++++----
?1 files changed, 4 insertions(+), 4 deletions(-)

arch/arm/plat-spear/time.c +0 -0

index a3164d1..4f05d26 100644

arch/arm/plat-spear/time.c +3 -3

 ? ? ? ?if (ret < 0) {
- ? ? ? ? ? ? ? pr_err("%s:couldn't enable gpt clock\n", __func__);
- ? ? ? ? ? ? ? goto err_clk;
+ ? ? ? ? ? ? ? pr_err("%s:couldn't prepare-enable gpt clock\n", __func__);
+ ? ? ? ? ? ? ? goto err_prepare_enable_clk;
 ? ? ? ?}
 
 ? ? ? ?spear_clockevent_init(irq);

@@ -229,7 +229,7 @@ void __init spear_setup_timer(resource_size_t base, int irq)
 
 ? ? ? ?return;
 
-err_clk:
+err_prepare_enable_clk:
 ? ? ? ?clk_put(gpt_clk);

?err_iomap:
? ? ? ?iounmap(gpt_base);
--
1.7.9

Quoted 20 lines · Mike

Quoted 18 lines · Viresh Kumar

With common clock framework, it is must to call clk_{un}prepare() before/after
clk_{dis}enable. This patch fixes this for SPEAr timer.

Signed-off-by Viresh Kumar <[email protected]>

---
?arch/arm/plat-spear/time.c | ? ?8 ++++----
?1 files changed, 4 insertions(+), 4 deletions(-)

arch/arm/plat-spear/time.c +0 -0

index a3164d1..4f05d26 100644
@@ -218,10 +218,10 @@ void __init spear_setup_timer(resource_size_t
 base, int irq)
 ? ? ? ? ? ? ? ?goto err_iomap;
 ? ? ? ?}
 

Quoted 4 lines

arch/arm/plat-spear/time.c void __init spear_setup_timer(resource_size_t · line 222

Quoted 2 lines

arch/arm/plat-spear/time.c +1 -1

- ? ? ? ret = clk_enable(gpt_clk);
+ ? ? ? ret = clk_prepare_enable(gpt_clk);

Where do you call clk_enable? ?Further down in the code somewhere?

I called prepare_enable() here.
Did i get your question correctly?

Quoted 3 lines

Also does this change break git bisect for your platform? ?Maybe you should move this change before patch 12/13 to prevent run-time breakage?

Correct.

--
Viresh

SPEAr now supports common clock framework. This patchset contains changes related to this. It also contain few dependency commits for clock framework that are earlier sent separately.

@Mike: It would be easiest to get these through ARM-SoC tree. So, would need your Acked-by on these patches. But firstly they must get reivewed :)

 MAINTAINERS                                     |    4 +-
 arch/arm/Kconfig                                |    1 +
 arch/arm/mach-spear3xx/clock.c                  | 1354 +++++++++--------------
 arch/arm/mach-spear3xx/include/mach/generic.h   |    4 +-
 arch/arm/mach-spear3xx/include/mach/misc_regs.h |    2 +
 arch/arm/mach-spear3xx/include/mach/spear.h     |   13 +
 arch/arm/mach-spear3xx/spear300.c               |    1 -
 arch/arm/mach-spear3xx/spear310.c               |    1 -
 arch/arm/mach-spear3xx/spear320.c               |   12 +-
 arch/arm/mach-spear3xx/spear3xx.c               |    2 +
 arch/arm/mach-spear6xx/clock.c                  | 1015 +++++------------

 arch/arm/mach-spear6xx/include/mach/misc_regs.h |    2 +
 arch/arm/mach-spear6xx/spear6xx.c               |    5 +-
 arch/arm/plat-spear/Makefile                    |    3 +-
 arch/arm/plat-spear/clk-aux-synth.c             |  195 ++++
 arch/arm/plat-spear/clk-frac-synth.c            |  156 +++
 arch/arm/plat-spear/clk-gpt-synth.c             |  145 +++
 arch/arm/plat-spear/clk-vco-pll.c               |  346 ++++++
 arch/arm/plat-spear/clock.c                     | 1005 -----------------

I wonder: should the clock drivers remain part of the platform directory, or get moved into a subdirectory of drivers/clk? I was assuming that we'd do the latter, but I haven't been following the clk discussions that closely.

Quoted 5 lines · Arnd Bergmann

I wonder: should the clock drivers remain part of the platform directory, or get moved into a subdirectory of drivers/clk? I was assuming that we'd do the latter, but I haven't been following the clk discussions that closely.

Mike had some comment [1] there, and I would second that.

Regards,
Shawn

[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/158320/focus=158543

Quoted 4 lines · Viresh Kumar

SPEAr now supports common clock framework. This patchset contains changes related to this. It also contain few dependency commits for clock framework that are earlier sent separately.

Quoted 2 lines

@Mike: It would be easiest to get these through ARM-SoC tree. So, would need your Acked-by on these patches. But firstly they must get reivewed :)

We should agree on how we want to do the common clk patches for v3.5. The two options I see are either we take all the patches that Mike Acks into arm-soc, or Mike applies the patches in his own tree and submits them to arm-soc. I think either way is fine for me, but some people might feel strongly one way or another.

Quoted 5 lines · Arnd Bergmann

Quoted 4 lines · Viresh Kumar

SPEAr now supports common clock framework. This patchset contains changes related to this. It also contain few dependency commits for clock framework that are earlier sent separately.

Quoted 8 lines

Quoted 2 lines

@Mike: It would be easiest to get these through ARM-SoC tree. So, would need your Acked-by on these patches. But firstly they must get reivewed :)

We should agree on how we want to do the common clk patches for v3.5. The two options I see are either we take all the patches that Mike Acks into arm-soc, or Mike applies the patches in his own tree and submits them to arm-soc. I think either way is fine for me, but some people might feel strongly one way or another.

I would prefer the latter (I maintain a branch and submit it). Is arm-soc still the right place for common clk patches in 3.5 and beyond? I don't mind hosting a branch for inclusion into linux-next and sending a pull request to Linus. There is nothing ARM-specific about the common framework.

Quoted 15 lines · Mike

Quoted 5 lines · Arnd Bergmann

Quoted 4 lines · Viresh Kumar

SPEAr now supports common clock framework. This patchset contains changes related to this. It also contain few dependency commits for clock framework that are earlier sent separately.

Quoted 8 lines

Quoted 2 lines

@Mike: It would be easiest to get these through ARM-SoC tree. So, would need your Acked-by on these patches. But firstly they must get reivewed :)

We should agree on how we want to do the common clk patches for v3.5. The two options I see are either we take all the patches that Mike Acks into arm-soc, or Mike applies the patches in his own tree and submits them to arm-soc. I think either way is fine for me, but some people might feel strongly one way or another.

Quoted 5 lines

I would prefer the latter (I maintain a branch and submit it). ?Is arm-soc still the right place for common clk patches in 3.5 and beyond? ?I don't mind hosting a branch for inclusion into linux-next and sending a pull request to Linus. ?There is nothing ARM-specific about the common framework.

Either way is fine with me, but it's really important that all the floating clock framework patches begin to materialize in a visible branch.

Quoted 22 lines · Sascha Hauer

Quoted 20 lines · Mike

Quoted 5 lines · Arnd Bergmann

Quoted 4 lines · Viresh Kumar

SPEAr now supports common clock framework. This patchset contains changes related to this. It also contain few dependency commits for clock framework that are earlier sent separately.

Quoted 8 lines

Quoted 2 lines

@Mike: It would be easiest to get these through ARM-SoC tree. So, would need your Acked-by on these patches. But firstly they must get reivewed :)

We should agree on how we want to do the common clk patches for v3.5. The two options I see are either we take all the patches that Mike Acks into arm-soc, or Mike applies the patches in his own tree and submits them to arm-soc. I think either way is fine for me, but some people might feel strongly one way or another.

I would prefer the latter (I maintain a branch and submit it). ?Is arm-soc still the right place for common clk patches in 3.5 and beyond? ?I don't mind hosting a branch for inclusion into linux-next and sending a pull request to Linus. ?There is nothing ARM-specific about the common framework.

Quoted 3 lines

Either way is fine with me, but it's really important that all the floating clock framework patches begin to materialize in a visible branch.

Agreed. ?I've been busy the last several days with some tasks besides common clk maintenance, but I'm going through all the patches now and will have a -next branch up soon on git.linaro.org.

Quoted 5 lines · Mike

I've taken patches 02 - 06 into my -next branch. ?Patch 01 isn't for me really, and I've not yet tested patch 07 (I'll take it everything looks good). ?The rest of your series (08 - 13) should probably go through Arnd.

Yes you are correct. Even to get spear clk? patches through arnd, I would need fixed-factor clk's patch of Sascha to
go through your tree. What are your plans
for that patch.

Viresh

I've taken patches 02 - 06 into my -next branch. Patch 01 isn't for me really, and I've not yet tested patch 07 (I'll take it everything looks good). The rest of your series (08 - 13) should probably go through Arnd.

My preference would be to have the whole series go through your tree and move the implementation of the spear clock code to drivers/clk in the process. This will reduce interdependencies between the spear clock branch and other branches that have spear patches.

Quoted 4 lines · Arnd Bergmann

My preference would be to have the whole series go through your tree and move the implementation of the spear clock code to drivers/clk in the process. This will reduce interdependencies between the spear clock branch and other branches that have spear patches.

Atleast for now, SPEAr clock patches have dependency on earlier SPEAr patches for which i have already sent you pull request.

So, this time atleast, these may go through your tree only.

You are talking about moving all clk files to drivers/clk or part of them (plat/clk-*.c or mach/clock.c)

Also, i don't know what's the best way, but arch/arm/*spear* looks to be the better place for SPEAr clock stuff. As it shares lot of registers/macros with non-clock stuff. If we keep them in drivers/clk we have to include <mach/...> files.

Quoted 4 lines · Mike

I've taken patches 02 - 06 into my -next branch. ?Patch 01 isn't for me really, and I've not yet tested patch 07 (I'll take it everything looks good). ?The rest of your series (08 - 13) should probably go through Arnd.

My preference would be to have the whole series go through your tree and move the implementation of the spear clock code to drivers/clk in the process. This will reduce interdependencies between the spear clock branch and other branches that have spear patches.

I also think it's a good idea if you submit the clk patches to Linus directly for the next merge window, but it's ok to use arm-soc if that makes you feel more confident about it.