[PATCH v2 0/8] Per-user clock constraints

[PATCH v2 0/8] Per-user clock constraints

[Tomeu Vizoso]

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.

Thanks,

Tomeu

Tomeu Vizoso (8):
  MIPS: Alchemy: Remove direct access to prepare_count field of struct
    clk
  clk: Remove unused function __clk_get_prepare_count
  clk: Don't try to use a struct clk* after it could have been freed
  clk: Don't expose __clk_get_accuracy
  clk: change clk_debugfs_add_file to take a struct clk_hw
  clk: Change clk_ops->determine_rate to return a clk_hw as the best
    parent
  clk: Make clk API return per-user struct clk instances
  clk: Add floor and ceiling constraints to clock rates

 arch/arm/mach-omap2/cclock3xxx_data.c   | 108 +++--
 arch/arm/mach-omap2/clock.h             |  11 +-
 arch/arm/mach-omap2/clock_common_data.c |   5 +-
 arch/mips/alchemy/common/clock.c        |   7 +-
 drivers/clk/at91/clk-programmable.c     |   4 +-
 drivers/clk/bcm/clk-kona.c              |   4 +-
 drivers/clk/clk-composite.c             |   9 +-
 drivers/clk/clk.c                       | 723 +++++++++++++++++++++-----------
 drivers/clk/clk.h                       |   7 +
 drivers/clk/clkdev.c                    |  23 +-
 drivers/clk/hisilicon/clk-hi3620.c      |   2 +-
 drivers/clk/qcom/clk-rcg.c              |  20 +-
 drivers/clk/qcom/clk-rcg2.c             |  28 +-
 drivers/clk/sunxi/clk-factors.c         |   4 +-
 drivers/clk/sunxi/clk-sun6i-ar100.c     |   4 +-
 include/linux/clk-private.h             |  40 +-
 include/linux/clk-provider.h            |  30 +-
 include/linux/clk.h                     |  18 +
 18 files changed, 697 insertions(+), 350 deletions(-)

-- 
1.9.3

[PATCH v2 1/8] MIPS: Alchemy: Remove direct access to prepare_count field of struct clk

[Tomeu Vizoso]

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

Re: [PATCH v2 0/8] Per-user clock constraints

[Stephen Boyd]

On 10/07/2014 08:21 AM, Tomeu Vizoso wrote:
> 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

Re: [PATCH v2 0/8] Per-user clock constraints

[Tomeu Vizoso]

On 9 October 2014 03:32, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 10/07/2014 08:21 AM, Tomeu Vizoso wrote:
>>
>> 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

Re: [PATCH v2 0/8] Per-user clock constraints

[Tomeu Vizoso]

On 9 October 2014 03:32, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 10/07/2014 08:21 AM, Tomeu Vizoso wrote:
>>
>> 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