From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/3] clk: add support for clock reparent on set_rate
Date: Thu, 09 May 2013 13:01:27 -0700 [thread overview]
Message-ID: <518C0097.50300@codeaurora.org> (raw)
In-Reply-To: <1366388904-13903-3-git-send-email-james.hogan@imgtec.com>
On 04/19/13 09:28, James Hogan wrote:
> Add core support to allow clock implementations to select the best
> parent clock when rounding a rate, e.g. the one which can provide the
> closest clock rate to that requested. This is by way of adding a new
> clock op, determine_rate(), which is like round_rate() but has an extra
> parameter to allow the clock implementation to optionally select a
> different parent clock. The core then takes care of reparenting the
> clock when setting the rate.
>
> The parent change takes place with the help of two new private data
> members. struct clk::new_parent specifies a clock's new parent (NULL
> indicates no change), and struct clk::new_child specifies a clock's new
> child (whose new_parent member points back to it). The purpose of these
> are to allow correct walking of the future tree for notifications prior
> to actually reparenting any clocks, specifically to skip child clocks
> who are being reparented to another clock (they will be notified via the
> new parent), and to include any new child clock. These pointers are set
> by clk_calc_subtree(), and the new_child pointer gets cleared when a
> child is actually reparented to avoid duplicate POST_RATE_CHANGE
> notifications.
>
> Each place where round_rate() is called, determine_rate is checked first
> and called in preference, passing NULL to the new parent argument if not
> needed (e.g. in __clk_round_rate). This restructures a few of the call
> sites to simplify the logic into if/else blocks.
>
> A new __clk_set_parent_no_recalc() is created similar to
> clk_set_parent() but without calling __clk_recalc_rates(). This is for
> clk_change_rate() to use, where rate recalculation and notifications are
> already handled.
>
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
I believe we'll need to update the check in __clk_init() to allow you to
have either a .round_rate or a .determine_rate op if you have a
.recalc_rate op. Right now it fails to register the clock and then
oopses later on while setting up clock debugfs.
Here's a (probably whitespace damaged) patch for the first one.
----8<-----
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index e6e759e..d56291c 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1668,8 +1668,8 @@ int __clk_init(struct device *dev, struct clk *clk)
/* check that clk_ops are sane. See Documentation/clk.txt */
if (clk->ops->set_rate &&
- !(clk->ops->round_rate && clk->ops->recalc_rate)) {
- pr_warning("%s: %s must implement .round_rate & .recalc_rate\n",
+ !((clk->ops->round_rate || clk->ops->determine_rate) && clk->ops->recalc_rate)) {
+ pr_warning("%s: %s must implement .round_rate or .determine_rate in addition to .recalc_rate\n",
__func__, clk->name);
ret = -EINVAL;
goto out;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@codeaurora.org>
To: James Hogan <james.hogan@imgtec.com>
Cc: Mike Turquette <mturquette@linaro.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] clk: add support for clock reparent on set_rate
Date: Thu, 09 May 2013 13:01:27 -0700 [thread overview]
Message-ID: <518C0097.50300@codeaurora.org> (raw)
In-Reply-To: <1366388904-13903-3-git-send-email-james.hogan@imgtec.com>
On 04/19/13 09:28, James Hogan wrote:
> Add core support to allow clock implementations to select the best
> parent clock when rounding a rate, e.g. the one which can provide the
> closest clock rate to that requested. This is by way of adding a new
> clock op, determine_rate(), which is like round_rate() but has an extra
> parameter to allow the clock implementation to optionally select a
> different parent clock. The core then takes care of reparenting the
> clock when setting the rate.
>
> The parent change takes place with the help of two new private data
> members. struct clk::new_parent specifies a clock's new parent (NULL
> indicates no change), and struct clk::new_child specifies a clock's new
> child (whose new_parent member points back to it). The purpose of these
> are to allow correct walking of the future tree for notifications prior
> to actually reparenting any clocks, specifically to skip child clocks
> who are being reparented to another clock (they will be notified via the
> new parent), and to include any new child clock. These pointers are set
> by clk_calc_subtree(), and the new_child pointer gets cleared when a
> child is actually reparented to avoid duplicate POST_RATE_CHANGE
> notifications.
>
> Each place where round_rate() is called, determine_rate is checked first
> and called in preference, passing NULL to the new parent argument if not
> needed (e.g. in __clk_round_rate). This restructures a few of the call
> sites to simplify the logic into if/else blocks.
>
> A new __clk_set_parent_no_recalc() is created similar to
> clk_set_parent() but without calling __clk_recalc_rates(). This is for
> clk_change_rate() to use, where rate recalculation and notifications are
> already handled.
>
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
I believe we'll need to update the check in __clk_init() to allow you to
have either a .round_rate or a .determine_rate op if you have a
.recalc_rate op. Right now it fails to register the clock and then
oopses later on while setting up clock debugfs.
Here's a (probably whitespace damaged) patch for the first one.
----8<-----
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index e6e759e..d56291c 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1668,8 +1668,8 @@ int __clk_init(struct device *dev, struct clk *clk)
/* check that clk_ops are sane. See Documentation/clk.txt */
if (clk->ops->set_rate &&
- !(clk->ops->round_rate && clk->ops->recalc_rate)) {
- pr_warning("%s: %s must implement .round_rate & .recalc_rate\n",
+ !((clk->ops->round_rate || clk->ops->determine_rate) && clk->ops->recalc_rate)) {
+ pr_warning("%s: %s must implement .round_rate or .determine_rate in addition to .recalc_rate\n",
__func__, clk->name);
ret = -EINVAL;
goto out;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2013-05-09 20:01 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-19 16:28 [PATCH v2 0/3] clk: implement remuxing during set_rate James Hogan
2013-04-19 16:28 ` James Hogan
2013-04-19 16:28 ` [PATCH v2 1/3] clk: abstract parent cache James Hogan
2013-04-19 16:28 ` James Hogan
2013-05-13 20:01 ` Mike Turquette
2013-05-13 20:01 ` Mike Turquette
2013-04-19 16:28 ` [PATCH v2 2/3] clk: add support for clock reparent on set_rate James Hogan
2013-04-19 16:28 ` James Hogan
2013-05-09 20:01 ` Stephen Boyd [this message]
2013-05-09 20:01 ` Stephen Boyd
2013-05-10 10:41 ` James Hogan
2013-05-10 10:41 ` James Hogan
2013-05-14 18:13 ` Mike Turquette
2013-05-14 18:13 ` Mike Turquette
2013-05-14 20:35 ` James Hogan
2013-05-14 20:35 ` James Hogan
2013-04-19 16:28 ` [PATCH v2 3/3] clk: clk-mux: implement remuxing " James Hogan
2013-04-19 16:28 ` James Hogan
2013-05-08 23:36 ` [PATCH v2 0/3] clk: implement remuxing during set_rate Stephen Boyd
2013-05-08 23:36 ` Stephen Boyd
2013-05-09 3:50 ` Saravana Kannan
2013-05-09 3:50 ` Saravana Kannan
2013-05-09 9:02 ` James Hogan
2013-05-09 9:02 ` James Hogan
2013-05-09 19:48 ` Stephen Boyd
2013-05-09 19:48 ` Stephen Boyd
2013-05-10 10:43 ` James Hogan
2013-05-10 10:43 ` James Hogan
2013-05-13 19:57 ` Mike Turquette
2013-05-13 19:57 ` Mike Turquette
2013-05-13 21:30 ` James Hogan
2013-05-13 21:30 ` James Hogan
2013-05-14 16:59 ` Mike Turquette
2013-05-14 21:01 ` James Hogan
2013-05-14 21:01 ` James Hogan
2013-05-14 22:15 ` Mike Turquette
2013-05-16 4:11 ` Saravana Kannan
2013-05-16 4:11 ` Saravana Kannan
2013-05-16 9:25 ` James Hogan
2013-05-16 9:25 ` James Hogan
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=518C0097.50300@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.