2015-07-28 14:29:49

by Dong Aisheng

[permalink] [raw]
Subject: [PATCH V3 0/5] clk: support clocks which requires parent clock on during operation

This patch series adds support in clock framework for clocks which operations
requires its parent clock is on.

Such clock type is initially met on Freescale i.MX7D platform that all clocks
operations, including enable/disable, rate change and re-parent, requires its
parent clock on. No sure if any other SoC has the similar clock type.

Current clock core can not support such type of clock well.

This patch introduce a new flag CLK_SET_PARENT_ON to handle this special case
in clock core that enable its parent clock firstly for each operation and disable
it later after operation complete.

The most special case is for set_parent() operation which requires both parent,
old one and new one, to be enabled at the same time during the operation.

The patch series is based on for-next branch of Michael's git:
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git

Change Log:
v2->v3:
* rebased version, no other changes.

v1->v2:
Mainly addressed Stephen Boyd's comments
* remove dupliciated code with __clk_set_parent_after
* introduce more clk_core_x APIs for core easily use
* move clk_disable_unused code position
* use clk_core_x API to make code more clean and easily read

Dong Aisheng (5):
clk: remove duplicated code with __clk_set_parent_after
clk: introduce clk_core_enable_lock and clk_core_disable_lock
functions
clk: move clk_disable_unused after clk_core_disable_unprepare function
clk: core: add CLK_OPS_PARENT_ON flags to support clocks require
parent on
clk: core: add CLK_OPS_PARENT_ON flags to support clocks require
parent on

drivers/clk/clk.c | 338 +++++++++++++++++++++++++------------------
include/linux/clk-provider.h | 5 +
2 files changed, 200 insertions(+), 143 deletions(-)

--
1.9.1


2015-07-28 14:29:57

by Dong Aisheng

[permalink] [raw]
Subject: [PATCH V3 1/5] clk: remove duplicated code with __clk_set_parent_after

__clk_set_parent_after() actually used the second argument then we
could put this duplicate logic in there and call it with a different
order of arguments in the success vs. error paths in this function.

Cc: Mike Turquette <[email protected]>
Cc: Stephen Boyd <[email protected]>
Suggested-by: Stephen Boyd <[email protected]>
Signed-off-by: Dong Aisheng <[email protected]>
---
drivers/clk/clk.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 7bb9757..4c7f7b2 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1185,14 +1185,8 @@ static int __clk_set_parent(struct clk_core *core, struct clk_core *parent,
flags = clk_enable_lock();
clk_reparent(core, old_parent);
clk_enable_unlock(flags);
+ __clk_set_parent_after(core, old_parent, parent);

- if (core->prepare_count) {
- flags = clk_enable_lock();
- clk_core_disable(core);
- clk_core_disable(parent);
- clk_enable_unlock(flags);
- clk_core_unprepare(parent);
- }
return ret;
}

--
1.9.1

2015-07-28 14:30:00

by Dong Aisheng

[permalink] [raw]
Subject: [PATCH V3 2/5] clk: introduce clk_core_enable_lock and clk_core_disable_lock functions

This can be useful when clock core wants to enable/disable clocks.
Then we don't have to convert the struct clk_core to struct clk to call
clk_enable/clk_disable which is a bit un-align with exist using.

And after introduce clk_core_{enable|disable}_lock, we can refine
clk_eanble and clk_disable a bit.

As well as clk_core_{enable|disable}_lock, we also added
clk_core_{prepare|unprepare}_lock and clk_core_prepare_enable/
clk_core_unprepare_disable for clock core to easily use.

Cc: Mike Turquette <[email protected]>
Cc: Stephen Boyd <[email protected]>
Signed-off-by: Dong Aisheng <[email protected]>
---
drivers/clk/clk.c | 85 +++++++++++++++++++++++++++++++++++++++++--------------
1 file changed, 63 insertions(+), 22 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 4c7f7b2..c2310d5 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -583,6 +583,13 @@ static void clk_core_unprepare(struct clk_core *core)
clk_core_unprepare(core->parent);
}

+static void clk_core_unprepare_lock(struct clk_core *core)
+{
+ clk_prepare_lock();
+ clk_core_unprepare(core);
+ clk_prepare_unlock();
+}
+
/**
* clk_unprepare - undo preparation of a clock source
* @clk: the clk being unprepared
@@ -599,9 +606,7 @@ void clk_unprepare(struct clk *clk)
if (IS_ERR_OR_NULL(clk))
return;

- clk_prepare_lock();
- clk_core_unprepare(clk->core);
- clk_prepare_unlock();
+ clk_core_unprepare_lock(clk->core);
}
EXPORT_SYMBOL_GPL(clk_unprepare);

@@ -637,6 +642,17 @@ static int clk_core_prepare(struct clk_core *core)
return 0;
}

+static int clk_core_prepare_lock(struct clk_core *core)
+{
+ int ret;
+
+ clk_prepare_lock();
+ ret = clk_core_prepare(core);
+ clk_prepare_unlock();
+
+ return ret;
+}
+
/**
* clk_prepare - prepare a clock source
* @clk: the clk being prepared
@@ -651,16 +667,10 @@ static int clk_core_prepare(struct clk_core *core)
*/
int clk_prepare(struct clk *clk)
{
- int ret;
-
if (!clk)
return 0;

- clk_prepare_lock();
- ret = clk_core_prepare(clk->core);
- clk_prepare_unlock();
-
- return ret;
+ return clk_core_prepare_lock(clk->core);
}
EXPORT_SYMBOL_GPL(clk_prepare);

@@ -687,6 +697,15 @@ static void clk_core_disable(struct clk_core *core)
clk_core_disable(core->parent);
}

+static void clk_core_disable_lock(struct clk_core *core)
+{
+ unsigned long flags;
+
+ flags = clk_enable_lock();
+ clk_core_disable(core);
+ clk_enable_unlock(flags);
+}
+
/**
* clk_disable - gate a clock
* @clk: the clk being gated
@@ -701,14 +720,10 @@ static void clk_core_disable(struct clk_core *core)
*/
void clk_disable(struct clk *clk)
{
- unsigned long flags;
-
if (IS_ERR_OR_NULL(clk))
return;

- flags = clk_enable_lock();
- clk_core_disable(clk->core);
- clk_enable_unlock(flags);
+ clk_core_disable_lock(clk->core);
}
EXPORT_SYMBOL_GPL(clk_disable);

@@ -747,6 +762,18 @@ static int clk_core_enable(struct clk_core *core)
return 0;
}

+static int clk_core_enable_lock(struct clk_core *core)
+{
+ unsigned long flags;
+ int ret;
+
+ flags = clk_enable_lock();
+ ret = clk_core_enable(core);
+ clk_enable_unlock(flags);
+
+ return ret;
+}
+
/**
* clk_enable - ungate a clock
* @clk: the clk being ungated
@@ -762,19 +789,33 @@ static int clk_core_enable(struct clk_core *core)
*/
int clk_enable(struct clk *clk)
{
- unsigned long flags;
- int ret;
-
if (!clk)
return 0;

- flags = clk_enable_lock();
- ret = clk_core_enable(clk->core);
- clk_enable_unlock(flags);
+ return clk_core_enable_lock(clk->core);
+}
+EXPORT_SYMBOL_GPL(clk_enable);
+
+static int clk_core_prepare_enable(struct clk_core *core)
+{
+ int ret;
+
+ ret = clk_core_prepare_lock(core);
+ if (ret)
+ return ret;
+
+ ret = clk_core_enable_lock(core);
+ if (ret)
+ clk_core_unprepare_lock(core);

return ret;
}
-EXPORT_SYMBOL_GPL(clk_enable);
+
+static void clk_core_disable_unprepare(struct clk_core *core)
+{
+ clk_core_disable_lock(core);
+ clk_core_unprepare_lock(core);
+}

static int clk_core_round_rate_nolock(struct clk_core *core,
struct clk_rate_request *req)
--
1.9.1

2015-07-28 14:31:30

by Dong Aisheng

[permalink] [raw]
Subject: [PATCH V3 3/5] clk: move clk_disable_unused after clk_core_disable_unprepare function

No function level change, just moving code place.
clk_disable_unused function will need to call clk_core_prepare_enable/
clk_core_disable_unprepare when adding CLK_OPS_PARENT_ON features.
So move it after clk_core_disable_unprepare to avoid adding forward
declared functions.

Cc: Mike Turquette <[email protected]>
Cc: Stephen Boyd <[email protected]>
Signed-off-by: Dong Aisheng <[email protected]>
---
drivers/clk/clk.c | 196 +++++++++++++++++++++++++++---------------------------
1 file changed, 98 insertions(+), 98 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index c2310d5..ac158c4 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -171,104 +171,6 @@ static bool clk_core_is_enabled(struct clk_core *core)
return core->ops->is_enabled(core->hw);
}

-static void clk_unprepare_unused_subtree(struct clk_core *core)
-{
- struct clk_core *child;
-
- lockdep_assert_held(&prepare_lock);
-
- hlist_for_each_entry(child, &core->children, child_node)
- clk_unprepare_unused_subtree(child);
-
- if (core->prepare_count)
- return;
-
- if (core->flags & CLK_IGNORE_UNUSED)
- return;
-
- if (clk_core_is_prepared(core)) {
- trace_clk_unprepare(core);
- if (core->ops->unprepare_unused)
- core->ops->unprepare_unused(core->hw);
- else if (core->ops->unprepare)
- core->ops->unprepare(core->hw);
- trace_clk_unprepare_complete(core);
- }
-}
-
-static void clk_disable_unused_subtree(struct clk_core *core)
-{
- struct clk_core *child;
- unsigned long flags;
-
- lockdep_assert_held(&prepare_lock);
-
- hlist_for_each_entry(child, &core->children, child_node)
- clk_disable_unused_subtree(child);
-
- flags = clk_enable_lock();
-
- if (core->enable_count)
- goto unlock_out;
-
- if (core->flags & CLK_IGNORE_UNUSED)
- goto unlock_out;
-
- /*
- * some gate clocks have special needs during the disable-unused
- * sequence. call .disable_unused if available, otherwise fall
- * back to .disable
- */
- if (clk_core_is_enabled(core)) {
- trace_clk_disable(core);
- if (core->ops->disable_unused)
- core->ops->disable_unused(core->hw);
- else if (core->ops->disable)
- core->ops->disable(core->hw);
- trace_clk_disable_complete(core);
- }
-
-unlock_out:
- clk_enable_unlock(flags);
-}
-
-static bool clk_ignore_unused;
-static int __init clk_ignore_unused_setup(char *__unused)
-{
- clk_ignore_unused = true;
- return 1;
-}
-__setup("clk_ignore_unused", clk_ignore_unused_setup);
-
-static int clk_disable_unused(void)
-{
- struct clk_core *core;
-
- if (clk_ignore_unused) {
- pr_warn("clk: Not disabling unused clocks\n");
- return 0;
- }
-
- clk_prepare_lock();
-
- hlist_for_each_entry(core, &clk_root_list, child_node)
- clk_disable_unused_subtree(core);
-
- hlist_for_each_entry(core, &clk_orphan_list, child_node)
- clk_disable_unused_subtree(core);
-
- hlist_for_each_entry(core, &clk_root_list, child_node)
- clk_unprepare_unused_subtree(core);
-
- hlist_for_each_entry(core, &clk_orphan_list, child_node)
- clk_unprepare_unused_subtree(core);
-
- clk_prepare_unlock();
-
- return 0;
-}
-late_initcall_sync(clk_disable_unused);
-
/*** helper functions ***/

const char *__clk_get_name(struct clk *clk)
@@ -817,6 +719,104 @@ static void clk_core_disable_unprepare(struct clk_core *core)
clk_core_unprepare_lock(core);
}

+static void clk_unprepare_unused_subtree(struct clk_core *core)
+{
+ struct clk_core *child;
+
+ lockdep_assert_held(&prepare_lock);
+
+ hlist_for_each_entry(child, &core->children, child_node)
+ clk_unprepare_unused_subtree(child);
+
+ if (core->prepare_count)
+ return;
+
+ if (core->flags & CLK_IGNORE_UNUSED)
+ return;
+
+ if (clk_core_is_prepared(core)) {
+ trace_clk_unprepare(core);
+ if (core->ops->unprepare_unused)
+ core->ops->unprepare_unused(core->hw);
+ else if (core->ops->unprepare)
+ core->ops->unprepare(core->hw);
+ trace_clk_unprepare_complete(core);
+ }
+}
+
+static void clk_disable_unused_subtree(struct clk_core *core)
+{
+ struct clk_core *child;
+ unsigned long flags;
+
+ lockdep_assert_held(&prepare_lock);
+
+ hlist_for_each_entry(child, &core->children, child_node)
+ clk_disable_unused_subtree(child);
+
+ flags = clk_enable_lock();
+
+ if (core->enable_count)
+ goto unlock_out;
+
+ if (core->flags & CLK_IGNORE_UNUSED)
+ goto unlock_out;
+
+ /*
+ * some gate clocks have special needs during the disable-unused
+ * sequence. call .disable_unused if available, otherwise fall
+ * back to .disable
+ */
+ if (clk_core_is_enabled(core)) {
+ trace_clk_disable(core);
+ if (core->ops->disable_unused)
+ core->ops->disable_unused(core->hw);
+ else if (core->ops->disable)
+ core->ops->disable(core->hw);
+ trace_clk_disable_complete(core);
+ }
+
+unlock_out:
+ clk_enable_unlock(flags);
+}
+
+static bool clk_ignore_unused;
+static int __init clk_ignore_unused_setup(char *__unused)
+{
+ clk_ignore_unused = true;
+ return 1;
+}
+__setup("clk_ignore_unused", clk_ignore_unused_setup);
+
+static int clk_disable_unused(void)
+{
+ struct clk_core *core;
+
+ if (clk_ignore_unused) {
+ pr_warn("clk: Not disabling unused clocks\n");
+ return 0;
+ }
+
+ clk_prepare_lock();
+
+ hlist_for_each_entry(core, &clk_root_list, child_node)
+ clk_disable_unused_subtree(core);
+
+ hlist_for_each_entry(core, &clk_orphan_list, child_node)
+ clk_disable_unused_subtree(core);
+
+ hlist_for_each_entry(core, &clk_root_list, child_node)
+ clk_unprepare_unused_subtree(core);
+
+ hlist_for_each_entry(core, &clk_orphan_list, child_node)
+ clk_unprepare_unused_subtree(core);
+
+ clk_prepare_unlock();
+
+ return 0;
+}
+late_initcall_sync(clk_disable_unused);
+
static int clk_core_round_rate_nolock(struct clk_core *core,
struct clk_rate_request *req)
{
--
1.9.1

2015-07-28 14:30:47

by Dong Aisheng

[permalink] [raw]
Subject: [PATCH V3 4/5] clk: core: add CLK_OPS_PARENT_ON flags to support clocks require parent on

On Freescale i.MX7D platform, all clocks operations, including
enable/disable, rate change and re-parent, requires its parent
clock on. Current clock core can not support it well.
This patch introduce a new flag CLK_OPS_PARENT_ON to handle this
special case in clock core that enable its parent clock firstly for
each operation and disable it later after operation complete.

This patch fixes disaling clocks while its parent is off.
This is a special case that is caused by a state mis-align between
HW and SW in clock tree during booting.
Usually in uboot, we may enable all clocks in HW by default.
And during kernel booting time, the parent clock could be disabled in its
driver probe due to calling clk_prepare_enable and clk_disable_unprepare.
Because it's child clock is only enabled in HW while its SW usecount
in clock tree is still 0, so clk_disable of parent clock will gate
the parent clock in both HW and SW usecount ultimately.
Then there will be a clock is on in HW while its parent is disabled.

Later when clock core does clk_disable_unused, this clock disable
will cause system hang due to the limitation of operation requiring
its parent clock on.

Cc: Mike Turquette <[email protected]>
Cc: Stephen Boyd <[email protected]>
Signed-off-by: Dong Aisheng <[email protected]>
---
drivers/clk/clk.c | 5 +++++
include/linux/clk-provider.h | 5 +++++
2 files changed, 10 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index ac158c4..cf31dc4 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -754,6 +754,9 @@ static void clk_disable_unused_subtree(struct clk_core *core)
hlist_for_each_entry(child, &core->children, child_node)
clk_disable_unused_subtree(child);

+ if (core->flags & CLK_OPS_PARENT_ON)
+ clk_core_prepare_enable(core->parent);
+
flags = clk_enable_lock();

if (core->enable_count)
@@ -778,6 +781,8 @@ static void clk_disable_unused_subtree(struct clk_core *core)

unlock_out:
clk_enable_unlock(flags);
+ if (core->flags & CLK_OPS_PARENT_ON)
+ clk_core_disable_unprepare(core->parent);
}

static bool clk_ignore_unused;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 06a56e5..006fafb 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -31,6 +31,11 @@
#define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate change */
#define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk accuracy */
#define CLK_RECALC_NEW_RATES BIT(9) /* recalc rates after notifications */
+/*
+ * parent clock must be on across any operation including
+ * clock gate/ungate, rate change and re-parent
+ */
+#define CLK_OPS_PARENT_ON BIT(10)

struct clk;
struct clk_hw;
--
1.9.1

2015-07-28 14:45:43

by Dong Aisheng

[permalink] [raw]
Subject: [PATCH V3 5/5] clk: core: add CLK_OPS_PARENT_ON flags to support clocks require parent on

On Freescale i.MX7D platform, all clocks operations, including
enable/disable, rate change and re-parent, requires its parent clock on.
Current clock core can not support it well.
This patch adding flag CLK_OPS_PARENT_ON to handle this special case in
clock core that enable its parent clock firstly for each operation and
disable it later after operation complete.

This patch fixes changing clock rate and switch parent while its parent
is off. The most special case is for set_parent() operation which requires
both parent, including old one and new one, to be enabled at the same time
during the operation.

Cc: Mike Turquette <[email protected]>
Cc: Stephen Boyd <[email protected]>
Signed-off-by: Dong Aisheng <[email protected]>
---
drivers/clk/clk.c | 46 +++++++++++++++++++++++++++++-----------------
1 file changed, 29 insertions(+), 17 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index cf31dc4..93eb9e3 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1159,7 +1159,7 @@ static struct clk_core *__clk_set_parent_before(struct clk_core *core,
struct clk_core *old_parent = core->parent;

/*
- * Migrate prepare state between parents and prevent race with
+ * 1. Migrate prepare state between parents and prevent race with
* clk_enable().
*
* If the clock is not prepared, then a race with
@@ -1174,13 +1174,17 @@ static struct clk_core *__clk_set_parent_before(struct clk_core *core,
* hardware and software states.
*
* See also: Comment for clk_set_parent() below.
+ *
+ * 2. enable two parents clock for .set_parent() operation if finding
+ * flag CLK_OPS_PARENT_ON
*/
- if (core->prepare_count) {
- clk_core_prepare(parent);
- flags = clk_enable_lock();
- clk_core_enable(parent);
- clk_core_enable(core);
- clk_enable_unlock(flags);
+ if (core->prepare_count || core->flags & CLK_OPS_PARENT_ON) {
+ clk_core_prepare_enable(parent);
+ if (core->prepare_count)
+ clk_core_enable_lock(core);
+ else
+ clk_core_prepare_enable(old_parent);
+
}

/* update the clk tree topology */
@@ -1195,18 +1199,16 @@ static void __clk_set_parent_after(struct clk_core *core,
struct clk_core *parent,
struct clk_core *old_parent)
{
- unsigned long flags;
-
/*
* Finish the migration of prepare state and undo the changes done
* for preventing a race with clk_enable().
*/
- if (core->prepare_count) {
- flags = clk_enable_lock();
- clk_core_disable(core);
- clk_core_disable(old_parent);
- clk_enable_unlock(flags);
- clk_core_unprepare(old_parent);
+ if (core->prepare_count || core->flags & CLK_OPS_PARENT_ON) {
+ clk_core_disable_unprepare(old_parent);
+ if (core->prepare_count)
+ clk_core_disable_lock(core);
+ else
+ clk_core_disable_unprepare(parent);
}
}

@@ -1453,13 +1455,17 @@ static void clk_change_rate(struct clk_core *core)
unsigned long best_parent_rate = 0;
bool skip_set_rate = false;
struct clk_core *old_parent;
+ struct clk_core *parent = NULL;

old_rate = core->rate;

- if (core->new_parent)
+ if (core->new_parent) {
+ parent = core->new_parent;
best_parent_rate = core->new_parent->rate;
- else if (core->parent)
+ } else if (core->parent) {
+ parent = core->parent;
best_parent_rate = core->parent->rate;
+ }

if (core->new_parent && core->new_parent != core->parent) {
old_parent = __clk_set_parent_before(core, core->new_parent);
@@ -1480,6 +1486,9 @@ static void clk_change_rate(struct clk_core *core)

trace_clk_set_rate(core, core->new_rate);

+ if (core->flags & CLK_OPS_PARENT_ON)
+ clk_core_prepare_enable(parent);
+
if (!skip_set_rate && core->ops->set_rate)
core->ops->set_rate(core->hw, core->new_rate, best_parent_rate);

@@ -1487,6 +1496,9 @@ static void clk_change_rate(struct clk_core *core)

core->rate = clk_recalc(core, best_parent_rate);

+ if (core->flags & CLK_OPS_PARENT_ON)
+ clk_core_disable_unprepare(parent);
+
if (core->notifier_count && old_rate != core->rate)
__clk_notify(core, POST_RATE_CHANGE, old_rate, core->rate);

--
1.9.1

2015-07-28 15:02:11

by Dong Aisheng

[permalink] [raw]
Subject: Re: [PATCH V3 0/5] clk: support clocks which requires parent clock on during operation

On Tue, Jul 28, 2015 at 09:19:40PM +0800, Dong Aisheng wrote:
> This patch series adds support in clock framework for clocks which operations
> requires its parent clock is on.
>
> Such clock type is initially met on Freescale i.MX7D platform that all clocks
> operations, including enable/disable, rate change and re-parent, requires its
> parent clock on. No sure if any other SoC has the similar clock type.
>
> Current clock core can not support such type of clock well.
>
> This patch introduce a new flag CLK_SET_PARENT_ON to handle this special case
> in clock core that enable its parent clock firstly for each operation and disable
> it later after operation complete.
>
> The most special case is for set_parent() operation which requires both parent,
> old one and new one, to be enabled at the same time during the operation.
>
> The patch series is based on for-next branch of Michael's git:
> git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
>
> Change Log:
> v2->v3:
> * rebased version, no other changes.
>
> v1->v2:
> Mainly addressed Stephen Boyd's comments
> * remove dupliciated code with __clk_set_parent_after
> * introduce more clk_core_x APIs for core easily use
> * move clk_disable_unused code position
> * use clk_core_x API to make code more clean and easily read
>
> Dong Aisheng (5):
> clk: remove duplicated code with __clk_set_parent_after
> clk: introduce clk_core_enable_lock and clk_core_disable_lock
> functions
> clk: move clk_disable_unused after clk_core_disable_unprepare function
> clk: core: add CLK_OPS_PARENT_ON flags to support clocks require
> parent on
> clk: core: add CLK_OPS_PARENT_ON flags to support clocks require
> parent on
>
> drivers/clk/clk.c | 338 +++++++++++++++++++++++++------------------
> include/linux/clk-provider.h | 5 +
> 2 files changed, 200 insertions(+), 143 deletions(-)
>

Sorry, forgot to update Mike's new email address.
Updated.

Regards
Dong Aisheng

> --
> 1.9.1
>

2015-08-04 09:55:15

by Dong Aisheng

[permalink] [raw]
Subject: Re: [PATCH V3 0/5] clk: support clocks which requires parent clock on during operation

On Tue, Jul 28, 2015 at 10:38:25PM +0800, Dong Aisheng wrote:
> On Tue, Jul 28, 2015 at 09:19:40PM +0800, Dong Aisheng wrote:
> > This patch series adds support in clock framework for clocks which operations
> > requires its parent clock is on.
> >
> > Such clock type is initially met on Freescale i.MX7D platform that all clocks
> > operations, including enable/disable, rate change and re-parent, requires its
> > parent clock on. No sure if any other SoC has the similar clock type.
> >
> > Current clock core can not support such type of clock well.
> >
> > This patch introduce a new flag CLK_SET_PARENT_ON to handle this special case
> > in clock core that enable its parent clock firstly for each operation and disable
> > it later after operation complete.
> >
> > The most special case is for set_parent() operation which requires both parent,
> > old one and new one, to be enabled at the same time during the operation.
> >
> > The patch series is based on for-next branch of Michael's git:
> > git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
> >
> > Change Log:
> > v2->v3:
> > * rebased version, no other changes.
> >
> > v1->v2:
> > Mainly addressed Stephen Boyd's comments
> > * remove dupliciated code with __clk_set_parent_after
> > * introduce more clk_core_x APIs for core easily use
> > * move clk_disable_unused code position
> > * use clk_core_x API to make code more clean and easily read
> >
> > Dong Aisheng (5):
> > clk: remove duplicated code with __clk_set_parent_after
> > clk: introduce clk_core_enable_lock and clk_core_disable_lock
> > functions
> > clk: move clk_disable_unused after clk_core_disable_unprepare function
> > clk: core: add CLK_OPS_PARENT_ON flags to support clocks require
> > parent on
> > clk: core: add CLK_OPS_PARENT_ON flags to support clocks require
> > parent on
> >
> > drivers/clk/clk.c | 338 +++++++++++++++++++++++++------------------
> > include/linux/clk-provider.h | 5 +
> > 2 files changed, 200 insertions(+), 143 deletions(-)
> >
>
> Sorry, forgot to update Mike's new email address.
> Updated.
>

Ping...

Regards
Dong Aisheng

> Regards
> Dong Aisheng
>
> > --
> > 1.9.1
> >

2015-08-13 10:27:23

by Dong Aisheng

[permalink] [raw]
Subject: Re: [PATCH V3 0/5] clk: support clocks which requires parent clock on during operation

On Tue, Aug 04, 2015 at 05:45:57PM +0800, Dong Aisheng wrote:
> On Tue, Jul 28, 2015 at 10:38:25PM +0800, Dong Aisheng wrote:
> > On Tue, Jul 28, 2015 at 09:19:40PM +0800, Dong Aisheng wrote:
> > > This patch series adds support in clock framework for clocks which operations
> > > requires its parent clock is on.
> > >
> > > Such clock type is initially met on Freescale i.MX7D platform that all clocks
> > > operations, including enable/disable, rate change and re-parent, requires its
> > > parent clock on. No sure if any other SoC has the similar clock type.
> > >
> > > Current clock core can not support such type of clock well.
> > >
> > > This patch introduce a new flag CLK_SET_PARENT_ON to handle this special case
> > > in clock core that enable its parent clock firstly for each operation and disable
> > > it later after operation complete.
> > >
> > > The most special case is for set_parent() operation which requires both parent,
> > > old one and new one, to be enabled at the same time during the operation.
> > >
> > > The patch series is based on for-next branch of Michael's git:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
> > >
> > > Change Log:
> > > v2->v3:
> > > * rebased version, no other changes.
> > >
> > > v1->v2:
> > > Mainly addressed Stephen Boyd's comments
> > > * remove dupliciated code with __clk_set_parent_after
> > > * introduce more clk_core_x APIs for core easily use
> > > * move clk_disable_unused code position
> > > * use clk_core_x API to make code more clean and easily read
> > >
> > > Dong Aisheng (5):
> > > clk: remove duplicated code with __clk_set_parent_after
> > > clk: introduce clk_core_enable_lock and clk_core_disable_lock
> > > functions
> > > clk: move clk_disable_unused after clk_core_disable_unprepare function
> > > clk: core: add CLK_OPS_PARENT_ON flags to support clocks require
> > > parent on
> > > clk: core: add CLK_OPS_PARENT_ON flags to support clocks require
> > > parent on
> > >
> > > drivers/clk/clk.c | 338 +++++++++++++++++++++++++------------------
> > > include/linux/clk-provider.h | 5 +
> > > 2 files changed, 200 insertions(+), 143 deletions(-)
> > >
> >
> > Sorry, forgot to update Mike's new email address.
> > Updated.
> >
>
> Ping...
>

Hi Mike,

It's been quite a long time.
Can you help pick this?

Regards
Dong Aisheng

> Regards
> Dong Aisheng
>
> > Regards
> > Dong Aisheng
> >
> > > --
> > > 1.9.1
> > >

2015-08-13 18:25:14

by Stephen Boyd

[permalink] [raw]
Subject: Re: [PATCH V3 1/5] clk: remove duplicated code with __clk_set_parent_after

On 07/28, Dong Aisheng wrote:
> __clk_set_parent_after() actually used the second argument then we
> could put this duplicate logic in there and call it with a different
> order of arguments in the success vs. error paths in this function.
>
> Cc: Mike Turquette <[email protected]>
> Cc: Stephen Boyd <[email protected]>
> Suggested-by: Stephen Boyd <[email protected]>
> Signed-off-by: Dong Aisheng <[email protected]>
> ---

Applied to clk-next

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

2015-08-13 20:55:51

by Joachim Eastwood

[permalink] [raw]
Subject: Re: [PATCH V3 0/5] clk: support clocks which requires parent clock on during operation

Hi Dong,

On 28 July 2015 at 15:19, Dong Aisheng <[email protected]> wrote:
> This patch series adds support in clock framework for clocks which operations
> requires its parent clock is on.
>
> Such clock type is initially met on Freescale i.MX7D platform that all clocks
> operations, including enable/disable, rate change and re-parent, requires its
> parent clock on. No sure if any other SoC has the similar clock type.

Just noticed this patch set.

One of clock-controller blocks (CCU) on lpc18xx has a similar
requirement. The CCU is clock fanout block with gates and the gate
registers can not be accessed if the base (parent) clock for the gate
is not running. Doing so causes the cpu to wedge.

The workaround I have locally is to check in the is_enabled gate op if
the parent is running or not. This works fine, but I am all for a more
generic solution in the clk framework.

I'll see if I can find the time to test your patch set. Thanks for
working on this.


regards,
Joachim Eastwood

2015-08-14 01:01:13

by Stephen Boyd

[permalink] [raw]
Subject: Re: [PATCH V3 4/5] clk: core: add CLK_OPS_PARENT_ON flags to support clocks require parent on

On 07/28, Dong Aisheng wrote:
> On Freescale i.MX7D platform, all clocks operations, including
> enable/disable, rate change and re-parent, requires its parent
> clock on. Current clock core can not support it well.
> This patch introduce a new flag CLK_OPS_PARENT_ON to handle this
> special case in clock core that enable its parent clock firstly for
> each operation and disable it later after operation complete.
>
> This patch fixes disaling clocks while its parent is off.
> This is a special case that is caused by a state mis-align between
> HW and SW in clock tree during booting.
> Usually in uboot, we may enable all clocks in HW by default.
> And during kernel booting time, the parent clock could be disabled in its
> driver probe due to calling clk_prepare_enable and clk_disable_unprepare.
> Because it's child clock is only enabled in HW while its SW usecount
> in clock tree is still 0, so clk_disable of parent clock will gate
> the parent clock in both HW and SW usecount ultimately.
> Then there will be a clock is on in HW while its parent is disabled.
>
> Later when clock core does clk_disable_unused, this clock disable
> will cause system hang due to the limitation of operation requiring
> its parent clock on.
>
> Cc: Mike Turquette <[email protected]>
> Cc: Stephen Boyd <[email protected]>
> Signed-off-by: Dong Aisheng <[email protected]>
> ---

Sorry, I still don't agree with this patch. There's no reason we
should be turning on clocks during late init so that we can turn
off clocks. If there's some sort of problem in doing that we
should figure it out and make it so that during late init we turn
off clocks from the leaves of the tree to the root.

I agree that there's a problem here where we don't properly
handle keeping children clocks on if a driver comes in and turns
off a clock in the middle of the tree before late init. That's a
real bug, and we should fix it. Mike Turquette has been doing
some work to have a way to indicate that certain clocks should be
kept on until client drivers grab them. I think it will also make
sure to up refcounts on parent clocks in the middle of the tree
when it figures out that a child clock is enabled. Would that be
all that we need to do to fix this problem?

Also, the subject of this patch and patch 5 are the same. Why?

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

2015-08-17 12:56:16

by Dong Aisheng

[permalink] [raw]
Subject: Re: [PATCH V3 4/5] clk: core: add CLK_OPS_PARENT_ON flags to support clocks require parent on

On Thu, Aug 13, 2015 at 06:01:09PM -0700, Stephen Boyd wrote:
> On 07/28, Dong Aisheng wrote:
> > On Freescale i.MX7D platform, all clocks operations, including
> > enable/disable, rate change and re-parent, requires its parent
> > clock on. Current clock core can not support it well.
> > This patch introduce a new flag CLK_OPS_PARENT_ON to handle this
> > special case in clock core that enable its parent clock firstly for
> > each operation and disable it later after operation complete.
> >
> > This patch fixes disaling clocks while its parent is off.
> > This is a special case that is caused by a state mis-align between
> > HW and SW in clock tree during booting.
> > Usually in uboot, we may enable all clocks in HW by default.
> > And during kernel booting time, the parent clock could be disabled in its
> > driver probe due to calling clk_prepare_enable and clk_disable_unprepare.
> > Because it's child clock is only enabled in HW while its SW usecount
> > in clock tree is still 0, so clk_disable of parent clock will gate
> > the parent clock in both HW and SW usecount ultimately.
> > Then there will be a clock is on in HW while its parent is disabled.
> >
> > Later when clock core does clk_disable_unused, this clock disable
> > will cause system hang due to the limitation of operation requiring
> > its parent clock on.
> >
> > Cc: Mike Turquette <[email protected]>
> > Cc: Stephen Boyd <[email protected]>
> > Signed-off-by: Dong Aisheng <[email protected]>
> > ---
>
> Sorry, I still don't agree with this patch. There's no reason we
> should be turning on clocks during late init so that we can turn
> off clocks.

Can't the reason be that it's fairly possible one clock is enabled
in HW while it's parent is disabled in initial clock tree state
and to enable parent clocks to disable itself is required by its special
HW characteristic?

Dosen't it quite clear from HW point of view?

> If there's some sort of problem in doing that we
> should figure it out and make it so that during late init we turn
> off clocks from the leaves of the tree to the root.
>

Turning off clocks from the leaves to root probably may require clock core
to provide a way to keep the parent clock enabled once finding its child
is still on in HW (clk_core_is_enabled() returns true) but enable_count
is zero before late init.

One possible solution may be leaving parent clocks on in HW during disable
once finding its child is on in HW and only decrease the parent's refcount,
and then replying on the later clk_disable_unused() to disable both child
and parent from leave to root.
e.g. clock A: parent, clock B: child of A
Initial state: clock B is enabled in HW while refcount is zero
Step1: Driver A enable clock A during probe
A: refcount becomes 1 HW state: enabled
Step2: Driver A disable clock A after probe
A: refcount becomes 0 HW state: enabled (only decrease refcount)

Then Clock A will be the same state as B, HW enabled while refcount is zero(
means no users), the later clk_disable_unusersd() will disable them all
from leave to root.

This is a workable solution but seems much more complicated than the exist
one in this patch which is only 5 lines of code changes.

And the question is:
since we already have the support of CLK_OPS_PARENT_ON (required by
clock set_rate/re-parent), why we still need invent another complicated
mechanism to support avoiding enable parent clock only for clk_disable_unused()?
Is that really worthy?
And it's also less power efficiency than the one in the patch.

> I agree that there's a problem here where we don't properly
> handle keeping children clocks on if a driver comes in and turns
> off a clock in the middle of the tree before late init. That's a
> real bug, and we should fix it.

Sorry, i still can't understand it's a bug.
Can you help explain more?

It looks to me like reasonable.
Enable/disable clock in driver is just one case, the initial clock tree may
also have such cases.
(Here i took the 'children clocks' you said as the one who's child clock is on
in HW while refcount is zero, fix me if wrong)

And it seems not so quite make sense to not physically disable the clock
when there's already no child users(refcount becomes zero) and i don't
think the child clock's default enablement state in HW means a valid user
since it's just caused by misalignment between HW and SW clock tree during
kernel booting phase which is meaningless.
And that seems is why the clk_disable_unused() function exist for fixing
this state misalignment issue.

> Mike Turquette has been doing
> some work to have a way to indicate that certain clocks should be
> kept on until client drivers grab them.

Sorry i can't see how this help on my issue.

> I think it will also make
> sure to up refcounts on parent clocks in the middle of the tree
> when it figures out that a child clock is enabled. Would that be
> all that we need to do to fix this problem?
>

Then when will we down the refcounts on parent clocks and when to disable it?
The current clk_disable_unused() only handle HW clk enable/disable, no
refcount operations.
Not sure how this is going to fix my issues.

And again, as i said above, i don't think it makes much sense to not disable
parent only if child is enabled in HW, unless there's more strong reasons.

> Also, the subject of this patch and patch 5 are the same. Why?
>

Sorry, mainly because the full feature of CLK_OPS_PARENT_ON is divided into
two patches for better review, their commit message is different.
patch 4 is adding support for clk_disable_unused() while patch 5 is for
clk_setrate/clk_reparent.
I could reform the subject if needed.

Regards
Dong Aisheng

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

2015-08-19 11:18:07

by Dong Aisheng

[permalink] [raw]
Subject: Re: [PATCH V3 4/5] clk: core: add CLK_OPS_PARENT_ON flags to support clocks require parent on

On Mon, Aug 17, 2015 at 08:45:18PM +0800, Dong Aisheng wrote:
> On Thu, Aug 13, 2015 at 06:01:09PM -0700, Stephen Boyd wrote:
> > On 07/28, Dong Aisheng wrote:
> > > On Freescale i.MX7D platform, all clocks operations, including
> > > enable/disable, rate change and re-parent, requires its parent
> > > clock on. Current clock core can not support it well.
> > > This patch introduce a new flag CLK_OPS_PARENT_ON to handle this
> > > special case in clock core that enable its parent clock firstly for
> > > each operation and disable it later after operation complete.
> > >
> > > This patch fixes disaling clocks while its parent is off.
> > > This is a special case that is caused by a state mis-align between
> > > HW and SW in clock tree during booting.
> > > Usually in uboot, we may enable all clocks in HW by default.
> > > And during kernel booting time, the parent clock could be disabled in its
> > > driver probe due to calling clk_prepare_enable and clk_disable_unprepare.
> > > Because it's child clock is only enabled in HW while its SW usecount
> > > in clock tree is still 0, so clk_disable of parent clock will gate
> > > the parent clock in both HW and SW usecount ultimately.
> > > Then there will be a clock is on in HW while its parent is disabled.
> > >
> > > Later when clock core does clk_disable_unused, this clock disable
> > > will cause system hang due to the limitation of operation requiring
> > > its parent clock on.
> > >
> > > Cc: Mike Turquette <[email protected]>
> > > Cc: Stephen Boyd <[email protected]>
> > > Signed-off-by: Dong Aisheng <[email protected]>
> > > ---
> >
> > Sorry, I still don't agree with this patch. There's no reason we
> > should be turning on clocks during late init so that we can turn
> > off clocks.
>
> Can't the reason be that it's fairly possible one clock is enabled
> in HW while it's parent is disabled in initial clock tree state
> and to enable parent clocks to disable itself is required by its special
> HW characteristic?
>
> Dosen't it quite clear from HW point of view?
>
> > If there's some sort of problem in doing that we
> > should figure it out and make it so that during late init we turn
> > off clocks from the leaves of the tree to the root.
> >
>
> Turning off clocks from the leaves to root probably may require clock core
> to provide a way to keep the parent clock enabled once finding its child
> is still on in HW (clk_core_is_enabled() returns true) but enable_count
> is zero before late init.
>
> One possible solution may be leaving parent clocks on in HW during disable
> once finding its child is on in HW and only decrease the parent's refcount,
> and then replying on the later clk_disable_unused() to disable both child
> and parent from leave to root.
> e.g. clock A: parent, clock B: child of A
> Initial state: clock B is enabled in HW while refcount is zero
> Step1: Driver A enable clock A during probe
> A: refcount becomes 1 HW state: enabled
> Step2: Driver A disable clock A after probe
> A: refcount becomes 0 HW state: enabled (only decrease refcount)
>
> Then Clock A will be the same state as B, HW enabled while refcount is zero(
> means no users), the later clk_disable_unusersd() will disable them all
> from leave to root.
>
> This is a workable solution but seems much more complicated than the exist
> one in this patch which is only 5 lines of code changes.
>
> And the question is:
> since we already have the support of CLK_OPS_PARENT_ON (required by
> clock set_rate/re-parent), why we still need invent another complicated
> mechanism to support avoiding enable parent clock only for clk_disable_unused()?
> Is that really worthy?
> And it's also less power efficiency than the one in the patch.
>
> > I agree that there's a problem here where we don't properly
> > handle keeping children clocks on if a driver comes in and turns
> > off a clock in the middle of the tree before late init. That's a
> > real bug, and we should fix it.
>
> Sorry, i still can't understand it's a bug.
> Can you help explain more?
>
> It looks to me like reasonable.
> Enable/disable clock in driver is just one case, the initial clock tree may
> also have such cases.
> (Here i took the 'children clocks' you said as the one who's child clock is on
> in HW while refcount is zero, fix me if wrong)
>
> And it seems not so quite make sense to not physically disable the clock
> when there's already no child users(refcount becomes zero) and i don't
> think the child clock's default enablement state in HW means a valid user
> since it's just caused by misalignment between HW and SW clock tree during
> kernel booting phase which is meaningless.
> And that seems is why the clk_disable_unused() function exist for fixing
> this state misalignment issue.
>
> > Mike Turquette has been doing
> > some work to have a way to indicate that certain clocks should be
> > kept on until client drivers grab them.
>
> Sorry i can't see how this help on my issue.
>
> > I think it will also make
> > sure to up refcounts on parent clocks in the middle of the tree
> > when it figures out that a child clock is enabled. Would that be
> > all that we need to do to fix this problem?
> >
>
> Then when will we down the refcounts on parent clocks and when to disable it?
> The current clk_disable_unused() only handle HW clk enable/disable, no
> refcount operations.
> Not sure how this is going to fix my issues.
>
> And again, as i said above, i don't think it makes much sense to not disable
> parent only if child is enabled in HW, unless there's more strong reasons.
>
> > Also, the subject of this patch and patch 5 are the same. Why?
> >
>
> Sorry, mainly because the full feature of CLK_OPS_PARENT_ON is divided into
> two patches for better review, their commit message is different.
> patch 4 is adding support for clk_disable_unused() while patch 5 is for
> clk_setrate/clk_reparent.
> I could reform the subject if needed.
>
> Regards
> Dong Aisheng
>

Hi Mike & Stephen,

Any comments about this?

Regards
Dong Aisheng

> > --
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project

2016-03-30 16:00:21

by Fabio Estevam

[permalink] [raw]
Subject: Re: [PATCH V3 0/5] clk: support clocks which requires parent clock on during operation

Hi Dong,

On Tue, Jul 28, 2015 at 10:19 AM, Dong Aisheng
<[email protected]> wrote:
> This patch series adds support in clock framework for clocks which operations
> requires its parent clock is on.
>
> Such clock type is initially met on Freescale i.MX7D platform that all clocks
> operations, including enable/disable, rate change and re-parent, requires its
> parent clock on. No sure if any other SoC has the similar clock type.
>
> Current clock core can not support such type of clock well.
>
> This patch introduce a new flag CLK_SET_PARENT_ON to handle this special case
> in clock core that enable its parent clock firstly for each operation and disable
> it later after operation complete.
>
> The most special case is for set_parent() operation which requires both parent,
> old one and new one, to be enabled at the same time during the operation.
>
> The patch series is based on for-next branch of Michael's git:
> git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git

Do you plan to resend this series?

2016-03-31 13:51:40

by Dong Aisheng

[permalink] [raw]
Subject: Re: [PATCH V3 0/5] clk: support clocks which requires parent clock on during operation

Hi Fabio,

On Thu, Mar 31, 2016 at 12:00 AM, Fabio Estevam <[email protected]> wrote:
> Hi Dong,
>
> On Tue, Jul 28, 2015 at 10:19 AM, Dong Aisheng
> <[email protected]> wrote:
>> This patch series adds support in clock framework for clocks which operations
>> requires its parent clock is on.
>>
>> Such clock type is initially met on Freescale i.MX7D platform that all clocks
>> operations, including enable/disable, rate change and re-parent, requires its
>> parent clock on. No sure if any other SoC has the similar clock type.
>>
>> Current clock core can not support such type of clock well.
>>
>> This patch introduce a new flag CLK_SET_PARENT_ON to handle this special case
>> in clock core that enable its parent clock firstly for each operation and disable
>> it later after operation complete.
>>
>> The most special case is for set_parent() operation which requires both parent,
>> old one and new one, to be enabled at the same time during the operation.
>>
>> The patch series is based on for-next branch of Michael's git:
>> git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
>
> Do you plan to resend this series?

It is in my TODO list.
I'm currently busy with some other items.
Will be able to do it in a few days.

Regards
Dong Aisheng

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