linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 3/8] clk: add support for clocks provided by SCP(System Control Processor)
Date: Thu, 16 Jul 2015 12:31:14 -0700	[thread overview]
Message-ID: <20150716193114.GA17952@codeaurora.org> (raw)
In-Reply-To: <55A7D79B.3080305@arm.com>

On 07/16, Sudeep Holla wrote:
> On 08/07/15 02:46, Stephen Boyd wrote:
> >
> >Yes struct clk would have min/max, and struct clk_core would have
> >min/max. Then some sort of provider API (or possibly even
> >clk_init_data) would take the min/max fields and copy them over
> >to struct clk_core. Then during set_rate operations we would
> >aggregate the constraints from struct clk like we already do and
> >add in the constrains in struct clk_core.
> >
> >One downside to adding new fields to clk_init_data is that there
> >are drivers out there that aren't initializing that structure to
> >0, and they're putting it on the stack, so stack junk can come
> >through. Furthermore, min/max would mean that every driver needs
> >to specify some large number for max or we have to special case
> >min == max == 0 and ignore it. Somehow it needs to be opt-in. If
> >we want to go down the clk_init_data route then perhaps we need
> >some sort of rate_constraint struct pointer in there that drivers
> >can optionally setup.
> >
> >	struct clk_rate_constraint {
> >		unsigned long min;
> >		unsigned long max;
> >	};
> >
> >	struct clk_init_data {
> >		...
> >		struct clk_rate_constraint *rate_constraint;
> >	};
> >
> >I haven't thought it through completely, but I can probably write
> >up some patch tomorrow after I sleep on it.
> >
> 
> I am hoping to get this series for v4.3. In order to avoid using
> consumer API, I can revert back to the min,max check I had in the
> round_rate earlier if that's fine with you ? Let me know so that I can
> post the next version based on that. All the other comments are already
> addressed.

Ok. I'm fine with the consumer API being used, but it would be
nice if we didn't have to do so. Try out the patch below,
hopefully it's good enough for your purposes. It may need to be
more robust, and we may still want to use the init_data structure
to avoid races with providers and consumers, but we can leave
that for later after sweeping all the structure users.

> 
> Also since this series depends on SCPI, I was thinking to get it merged
> via ARM-SoC, but that might conflict with the round_rate prototype
> change. Do do plan to share a stable base with arm-soc guys or you
> expect all the changes to be contained in clk tree ?
> 

We can share a stable branch for the determine_rate change with
arm-soc. We already have it on a separate branch but haven't
published it so far because nobody has asked.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

-----8<------
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index a1d34a2ed9c6..8760b743bb70 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -58,6 +58,8 @@ struct clk_core {
 	unsigned long		flags;
 	unsigned int		enable_count;
 	unsigned int		prepare_count;
+	unsigned long		min_rate;
+	unsigned long		max_rate;
 	unsigned long		accuracy;
 	int			phase;
 	struct hlist_head	children;
@@ -512,8 +514,8 @@ static void clk_core_get_boundaries(struct clk_core *core,
 {
 	struct clk *clk_user;
 
-	*min_rate = 0;
-	*max_rate = ULONG_MAX;
+	*min_rate = core->min_rate;
+	*max_rate = core->max_rate;
 
 	hlist_for_each_entry(clk_user, &core->clks, clks_node)
 		*min_rate = max(*min_rate, clk_user->min_rate);
@@ -522,6 +524,13 @@ static void clk_core_get_boundaries(struct clk_core *core,
 		*max_rate = min(*max_rate, clk_user->max_rate);
 }
 
+void clk_hw_set_rate_range(struct clk_hw *hw, unsigned long min_rate,
+			   unsigned long max_rate)
+{
+	hw->core->min_rate = min_rate;
+	hw->core->max_rate = max_rate;
+}
+
 /*
  * Helper for finding best parent to provide a given frequency. This can be used
  * directly as a determine_rate callback (e.g. for a mux), or from a more
@@ -2496,6 +2505,8 @@ struct clk *clk_register(struct device *dev, struct clk_hw *hw)
 	core->hw = hw;
 	core->flags = hw->init->flags;
 	core->num_parents = hw->init->num_parents;
+	core->min_rate = 0;
+	core->max_rate = ULONG_MAX;
 	hw->core = core;
 
 	/* allocate local copy in case parent_names is __initdata */
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 2116e2b8a5f2..d62e7eab1dbe 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -619,6 +619,8 @@ int __clk_determine_rate(struct clk_hw *core, struct clk_rate_request *req);
 int __clk_mux_determine_rate_closest(struct clk_hw *hw,
 				     struct clk_rate_request *req);
 void clk_hw_reparent(struct clk_hw *hw, struct clk_hw *new_parent);
+void clk_hw_set_rate_range(struct clk_hw *hw, unsigned long min_rate,
+			   unsigned long max_rate);
 
 static inline void __clk_hw_set_clk(struct clk_hw *dst, struct clk_hw *src)
 {

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

  reply	other threads:[~2015-07-16 19:31 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-08 10:39 [PATCH v4 0/8] ARM64: juno: add SCPI mailbox protocol, clock and CPUFreq support Sudeep Holla
2015-06-08 10:39 ` [PATCH v4 1/8] Documentation: add DT binding for ARM System Control and Power Interface(SCPI) protocol Sudeep Holla
2015-07-08 13:59   ` Sudeep Holla
2015-07-22  8:43   ` Liviu Dudau
2015-07-22  9:25     ` Sudeep Holla
2015-07-22  9:55   ` Mark Rutland
2015-07-22 15:56     ` Sudeep Holla
2015-07-22 16:23       ` Mark Rutland
2015-06-08 10:39 ` [PATCH v4 2/8] firmware: add support " Sudeep Holla
2015-06-11 11:54   ` Jassi Brar
2015-06-11 13:23     ` Sudeep Holla
2015-06-08 10:39 ` [PATCH v4 3/8] clk: add support for clocks provided by SCP(System Control Processor) Sudeep Holla
2015-07-02 17:23   ` Stephen Boyd
2015-07-03 14:52     ` Sudeep Holla
2015-07-03 16:12       ` Sudeep Holla
2015-07-06 19:52       ` Stephen Boyd
2015-07-07 16:03         ` Sudeep Holla
2015-07-08  1:46           ` Stephen Boyd
2015-07-16 16:11             ` Sudeep Holla
2015-07-16 19:31               ` Stephen Boyd [this message]
2015-07-17 11:17                 ` Sudeep Holla
2015-07-17 18:13                   ` Stephen Boyd
2015-07-20  8:54                     ` Sudeep Holla
2015-07-21 18:05                       ` Stephen Boyd
2015-07-22 14:19                         ` Sudeep Holla
2015-06-08 10:39 ` [PATCH v4 4/8] clk: scpi: add support for cpufreq virtual device Sudeep Holla
2015-06-08 10:39 ` [PATCH v4 5/8] cpufreq: arm_big_little: add SCPI interface driver Sudeep Holla
2015-06-08 10:40 ` [PATCH v4 6/8] arm64: dts: add SRAM, MHU mailbox and SCPI support on Juno Sudeep Holla
2015-06-08 13:51   ` Jon Medhurst (Tixy)
2015-06-08 14:32     ` Sudeep Holla
2015-06-08 14:35     ` Liviu Dudau
2015-07-22 13:28   ` Liviu Dudau
2015-07-22 15:40     ` Sudeep Holla
2015-07-22 16:06       ` Liviu Dudau
2015-07-22 16:16         ` Sudeep Holla
2015-06-08 10:40 ` [PATCH v4 7/8] arm64: dts: add CPU topology " Sudeep Holla
2015-07-22 13:31   ` Liviu Dudau
2015-06-08 10:40 ` [PATCH v4 8/8] arm64: dts: add clock support for all the cpus Sudeep Holla
2015-07-22 13:32   ` Liviu Dudau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150716193114.GA17952@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).