From: tomeu.vizoso@collabora•com (Tomeu Vizoso)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v13 0/9] Per-user clock constraints
Date: Wed, 24 Sep 2014 10:27:19 +0200 [thread overview]
Message-ID: <54228067.3090600@collabora.com> (raw)
In-Reply-To: <5421DF46.2010107@codeaurora.org>
On 09/23/2014 10:59 PM, Stephen Boyd wrote:
> On 09/23/14 11:40, Tomeu Vizoso wrote:
>> Hello,
>>
>> this version of the patchset addresses some issues that Russell pointed out
>> yesterday:
>>
>> * Refactor the changes to clkdev.c to reduce the amount of ifdefs.
>>
>> * Properly release clocks when there isn't enough memory to create the per-user
>> wrapper.
>>
>> * Add clk_provider_put(struct clk_core*) for clock implementations to call
>> instead of clk_put(struct clk*) (instead of exposing __clk_put).
>>
>> As the previous versions, this is based on top of 3.17-rc4 and Mike's patch at
>> [0].
>
> Any thoughts on my comments on patch set #10[1]? It seems like we can
> avoid having a flag day to support this.
I cannot say that I fully understand your proposal, but IMO the most
valuable thing in this patchset is precisely the API split (and thus,
the flag day is inherent to it).
I see a lot of value in clk consumers to use a defined set of functions
that all take and/or return struct clk, and for providers to use the
functions that take and/or return struct clk_core. Makes the API clearer
and allows it to have a more scalable growth in the future.
A less important feature of the patchset are per-user clocks, which (if
I understand correctly) your proposal would address without requiring a
flag day.
And then we have clock constraints, which is probably the least
important feature in the grand scheme of things, but it's actually what
I personally care about.
If we wanted to add a way for clk users to specify clock constraints
without any refactoring, we could easily do so by reusing the request
pattern that pm_qos uses:
void clk_add_constraint(struct clk_request *req,
int constraint_type,
unsigned long value);
void clk_update_constraint(struct clk_request *req,
unsigned long new_value);
void clk_remove_constraint(struct clk_request *req);
It wouldn't be that bad IMO, but the API refactoring was something that
was long desired and this was seen as a good opportunity to tackle it
before it gets worst.
Cheers,
Tomeu
> [1] https://lkml.org/lkml/2014/9/9/960
>
next prev parent reply other threads:[~2014-09-24 8:27 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 [this message]
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
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=54228067.3090600@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