All of lore.kernel.org
 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

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@codeaurora.org>
To: Mike Turquette <mturquette@linaro.org>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Russell King <linux@arm.linux.org.uk>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Peter De Schrijver <pdeschrijver@nvidia.com>,
	linux-kernel@vger.kernel.org, tomasz.figa@gmail.com,
	rabin@rab.in, Thierry Reding <thierry.reding@gmail.com>,
	Javier Martinez Canillas <javier.martinez@collabora.co.uk>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [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: 42+ 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 ` 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:40   ` Tomeu Vizoso
2014-09-23 18:42 ` [PATCH v13 2/9] clk: Move all drivers to use internal API Tomeu Vizoso
2014-09-23 18:42   ` 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   ` 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     ` 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     ` 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     ` 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     ` 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     ` 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 18:44     ` Tomeu Vizoso
2014-09-23 20:59 ` [PATCH v13 0/9] Per-user clock constraints Stephen Boyd
2014-09-23 20:59   ` Stephen Boyd
2014-09-24  8:27   ` Tomeu Vizoso
2014-09-24  8:27     ` Tomeu Vizoso
2014-09-26  1:29     ` Stephen Boyd
2014-09-26  1:29       ` Stephen Boyd
2014-09-26  8:09       ` Tomeu Vizoso
2014-09-26  8:09         ` Tomeu Vizoso
2014-09-26 23:20         ` Mike Turquette
2014-09-26 23:20           ` Mike Turquette
2014-09-27  0:15           ` Stephen Boyd [this message]
2014-09-27  0:15             ` Stephen Boyd
2014-09-29 18:17           ` [RFC] clk: Make clk API return per-user struct clk instances Tomeu Vizoso
2014-09-30  1:40             ` Stephen Boyd
2014-09-30  6:54               ` Mike Turquette
2014-09-30  7:41                 ` Tero Kristo
2014-09-30 18:16                   ` Tony Lindgren
2014-10-03 14:13                     ` Tero Kristo
2014-09-30  9:14             ` Russell King - ARM Linux
2014-09-30 14:28           ` [RFC v2] " Tomeu Vizoso
2014-09-24  9:14 ` [PATCH v13 0/9] Per-user clock constraints Tomeu Vizoso
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 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.