From: tomeu.vizoso@collabora•com (Tomeu Vizoso)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v9 5/6] clk: Add floor and ceiling constraints to clock rates
Date: Thu, 04 Sep 2014 15:34:57 +0200 [thread overview]
Message-ID: <54086A81.1060606@collabora.com> (raw)
In-Reply-To: <5407A6B9.1080606@codeaurora.org>
On 09/04/2014 01:39 AM, Stephen Boyd wrote:
> On 09/03/14 08:33, Tomeu Vizoso wrote:
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index 61a3492..3a961c6 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -560,6 +560,8 @@ struct clk *__clk_create_clk(struct clk_core *clk_core, const char *dev,
>> clk->dev_id = dev;
>> clk->con_id = con;
>>
>> + hlist_add_head(&clk->child_node, &clk_core->per_user_clks);
>> +
>
> How is this safe with another thread that may be traversing the list? Or
> even two threads calling clk_get_parent() at the same time?
Good point, will take the prepare lock.
>> +int clk_set_floor_rate(struct clk *clk_user, unsigned long rate)
>> +{
>> + struct clk_core *clk = clk_to_clk_core(clk_user);
>> +
>> + clk_user->floor_constraint = rate;
>> + return clk_provider_set_rate(clk, clk_provider_get_rate(clk));
>
> It would be nice if this was also locked around so that the
> floor_constraint or ceiling_constraint doesn't change while another
> thread is iterating the list. I guess we'll get by though because
> eventually things will settle and either this thread here will set the
> "final" rate, or the other thread in clk_provider_set_rate() will have
> already set the final rate. It just seems wrong to not hold the lock
> while updating what is supposed to be protected by the prepare lock.
Yeah, I also lean towards having an explicit lock, as having a more
deterministic behaviour can be quite helpful when debugging.
Thanks,
Tomeu
next prev parent reply other threads:[~2014-09-04 13:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-03 15:29 [PATCH v9 0/6] Per-user clock constraints Tomeu Vizoso
2014-09-03 15:29 ` [PATCH v9 1/6] clk: Add temporary mapping to the existing API Tomeu Vizoso
[not found] ` <1409758317-20564-1-git-send-email-tomeu.vizoso@collabora.com>
[not found] ` <20140908061355.19023.47997@quantum>
2014-09-09 6:15 ` [PATCH v9 2/6] clk: Move all drivers to use internal API Mike Turquette
2014-09-03 15:33 ` [PATCH v9 3/6] clk: use struct clk only for external API Tomeu Vizoso
2014-09-03 15:33 ` [PATCH v9 4/6] clk: per-user clock accounting for debug Tomeu Vizoso
2014-09-03 15:33 ` [PATCH v9 5/6] clk: Add floor and ceiling constraints to clock rates Tomeu Vizoso
2014-09-03 23:39 ` Stephen Boyd
2014-09-04 0:53 ` Mike Turquette
2014-09-04 8:53 ` Tomeu Vizoso
2014-09-04 13:34 ` Tomeu Vizoso [this message]
2014-09-03 15:33 ` [PATCH v9 6/6] clk: Warn of unbalanced clk_prepare() calls Tomeu Vizoso
2014-09-03 17:26 ` [PATCH v9 0/6] Per-user clock constraints Mike Turquette
2014-09-04 8:30 ` 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=54086A81.1060606@collabora.com \
--to=tomeu.vizoso@collabora$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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