Discussion:
[PATCH v2 1/8] MIPS: Alchemy: Remove direct access to prepare_count field of struct clk
Tomeu Vizoso
2014-10-07 15:21:46 UTC
Permalink
Replacing it with a call to __clk_is_prepared(), which isn't entirely
equivalent but in practice shouldn't matter.

Signed-off-by: Tomeu Vizoso <***@collabora.com>
---
arch/mips/alchemy/common/clock.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/mips/alchemy/common/clock.c b/arch/mips/alchemy/common/clock.c
index d7557cd..203e440 100644
--- a/arch/mips/alchemy/common/clock.c
+++ b/arch/mips/alchemy/common/clock.c
@@ -37,7 +37,6 @@
#include <linux/io.h>
#include <linux/clk-provider.h>
#include <linux/clkdev.h>
-#include <linux/clk-private.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
#include <linux/types.h>
@@ -397,10 +396,10 @@ static long alchemy_clk_fgcs_detr(struct clk_hw *hw, unsigned long rate,
break;

/* if this parent is currently unused, remember it.
- * XXX: I know it's a layering violation, but it works
- * so well.. (if (!clk_has_active_children(pc)) )
+ * XXX: we would actually want clk_has_active_children()
+ * but this is a good-enough approximation for now.
*/
- if (pc->prepare_count == 0) {
+ if (!__clk_is_prepared(pc)) {
if (!free)
free = pc;
}
--
1.9.3
Stephen Boyd
2014-10-09 01:32:32 UTC
Permalink
Hello,
this second version of the series adds several cleanups that were suggested by
Stephen Boyd and contains several improvements to the seventh patch (clk: Make
clk API return per-user struct clk instances) that were suggested by him during
the review of v1.
The first six patches are just cleanups that should be desirable on their own,
and that should make easier to review the actual per-user clock patch.
The seventh patch actually moves the per-clock data that was stored in struct
clk to a new struct clk_core and adds references to it from both struct clk and
struct clk_hw. struct clk is now ready to contain information that is specific
to a given clk consumer.
The eighth patch adds API for setting floor and ceiling constraints and stores
that information on the per-user struct clk, which is iterable from struct
clk_core.
As said in the patches, can you please indicate which baseline this is
on? Also can you rebase onto clk-next if you send again before that is
merged into 3.18-rc1? There are some changes in the debugfs part that
will conflict. I'll review the more complicated parts in detail soon.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomeu Vizoso
2014-10-09 07:21:01 UTC
Permalink
Hello,
this second version of the series adds several cleanups that were suggested by
Stephen Boyd and contains several improvements to the seventh patch (clk: Make
clk API return per-user struct clk instances) that were suggested by him during
the review of v1.
The first six patches are just cleanups that should be desirable on their own,
and that should make easier to review the actual per-user clock patch.
The seventh patch actually moves the per-clock data that was stored in struct
clk to a new struct clk_core and adds references to it from both struct clk and
struct clk_hw. struct clk is now ready to contain information that is specific
to a given clk consumer.
The eighth patch adds API for setting floor and ceiling constraints and stores
that information on the per-user struct clk, which is iterable from struct
clk_core.
As said in the patches, can you please indicate which baseline this is on?
Sure, this was based on v3.17. Also available at:

http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=per-user-clk-constraints-v2
Also can you rebase onto clk-next if you send again before that is merged
into 3.18-rc1? There are some changes in the debugfs part that will
conflict. I'll review the more complicated parts in detail soon.
Ack.

Thanks,

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