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

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