From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v13 0/9] Per-user clock constraints
Date: Fri, 26 Sep 2014 17:15:00 -0700 [thread overview]
Message-ID: <54260184.2040704@codeaurora.org> (raw)
In-Reply-To: <20140926232009.19023.15825@quantum>
On 09/26/14 16:20, Mike Turquette wrote:
> Quoting Tomeu Vizoso (2014-09-26 01:09:20)
>> On 09/26/2014 03:29 AM, Stephen Boyd wrote:
>>
>>> We already have the consumer/provider split in the struct clk_hw and
>>> struct clk separation. Why don't we just use struct clk_hw throughout
>>> the provider APIs? The only op that isn't doing this is determine_rate()
>>> which might be able to accept a flag day. Otherwise we rename it to
>>> something else and migrate everyone over to a different named function
>>> that doesn't take a struct clk **. Then we introduce new APIs for the
>>> providers to use that are struct clk_hw focused instead of struct clk
>>> focused and migrate them too. The benefit being that we get proper
>>> review of this stuff because the patches are small. We can let
>>> coccinelle do it too.
> I have been opposed to mucking with clk_hw before, but that was because
> the goal was never clear. Now that we know that we're trying to split
> the API then it might be reasonable to use it.
>
> Stephen, does your above proposal still allow for unique struct clk
> cookies for each user of a clock?
>
>
Yes. The clkdev code would know that it's getting clk_hw pointers back
from the provider instead of struct clk pointers because it uses a
different callback:
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index bacc06ff939b..76c356b779d1 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2337,6 +2337,7 @@ struct of_clk_provider {
struct device_node *node;
struct clk *(*get)(struct of_phandle_args *clkspec, void *data);
+ struct clk_hw *(*get_hw)(struct of_phandle_args *clkspec, void *data);
void *data;
};
It would test for the presence of the get_hw callback and then fall back
to the get callback. Similarly we would have a clk_hw pointer in the
clkdev lookup structure. Once clkdev has the hw pointer it can ask the
ccf to generate a struct clk cookie. This would happen either in
__of_clk_get_from_provider() or clk_get_sys() depending on if we're
using DT or not.
The clk_hw structure will need to be updated to have a pointer to
clk_core. During the transition we would have struct clk and struct
clk_core next to each other in struct clk_hw. Eventually once we convert
all drivers we can remove struct clk from clk_hw. This would require
getting rid of the DEFINE_CLK macro in clk-private.h though.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2014-09-27 0:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-23 18:40 [PATCH v13 0/9] Per-user clock constraints Tomeu Vizoso
2014-09-23 18:40 ` [PATCH v13 1/9] clk: Add temporary mapping to the existing API Tomeu Vizoso
2014-09-23 18:44 ` [PATCH v13 3/9] clk: use struct clk only for external API Tomeu Vizoso
2014-09-23 18:44 ` [PATCH v13 4/9] clk: per-user clock accounting for debug Tomeu Vizoso
2014-09-23 18:44 ` [PATCH v13 5/9] clk: Add floor and ceiling constraints to clock rates Tomeu Vizoso
2014-09-23 18:44 ` [PATCH v13 6/9] clk: Warn of unbalanced clk_prepare() calls Tomeu Vizoso
2014-09-23 18:44 ` [PATCH v13 7/9] clk: Take the prepare lock when updating the list of per-user clks Tomeu Vizoso
2014-09-23 18:44 ` [PATCH v13 8/9] clk: Take the prepare lock when updating the per-user constraints Tomeu Vizoso
2014-09-23 18:44 ` [PATCH v13 9/9] clk: Add docs about calling clk_put after clk_get_parent Tomeu Vizoso
2014-09-23 20:59 ` [PATCH v13 0/9] Per-user clock constraints Stephen Boyd
2014-09-24 8:27 ` Tomeu Vizoso
2014-09-26 1:29 ` Stephen Boyd
2014-09-26 8:09 ` Tomeu Vizoso
2014-09-26 23:20 ` Mike Turquette
2014-09-27 0:15 ` Stephen Boyd [this message]
2014-09-24 9:14 ` Tomeu Vizoso
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=54260184.2040704@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).