Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare

From: Ulf Hansson
Date: Mon Mar 18 2013 - 06:36:40 EST

On 15 March 2013 20:38, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
> On 03/15/2013 06:33 AM, Ulf Hansson wrote:
>> On 15 March 2013 13:06, Bill Huang <bilhuang@xxxxxxxxxx> wrote:
>>> On Fri, 2013-03-15 at 18:08 +0800, Ulf Hansson wrote:
> ...
>>>> Some prerequisites; I think am in favor of using the clk API to
>>>> trigger DVFS changes and then I agree on that clk_prepare|unprepare
>>>> needs to be possible to track from a DVFS perspective. clk_set_rate is
>>>> not enough.
>>>> So if we decide to do the above (using the clk API to trigger DVFS
>>>> changes), I believe we should discuss two possible solutions;
>>>> - clk notifiers or..
>>>> - dvfs clock type.
>>>> I am trying to make up my mind of what I think is the best solution.
>>>> Have you considered "dvfs clock type"?
>>>> I put some comments about this for "[PATCH 2/5] clk: notifier handler
>>>> for dynamic voltage scaling" recently as well.
>>>> What could the advantages/disadvantages be between the two options?
>>> I personally prefer clk notifiers since that's easy and all the existing
>>> device drivers don't need to be modified, a new clock or API might be
>>> more thoroughly considered (and hence maybe more graceful) but that
>>> means we need more time to cook and many drivers need to plug into that
>>> API when it comes out, a lot of test/verification or maybe chaos
>>> follows, I'm not sure will that be a little overkill.
>> I guess you did not fully got what I meant with "dvfs clock type". It
>> will not affect the clock API. But instead the dvfs is handled by
>> implementing a specific clk hw type. So the same thing is accomplished
>> as with clk notifiers, no changes should be needed to device drivers.
>> The difference is only that no notifiers will be needed, and all the
>> dvfs stuff will be handled in the clk hw instead. It will mean that we
>> will bundle dvfs stuff into the clock drivers, instead of separating
>> the code outside the clock drivers. But, on the other hand no
>> notifiers will be needed.
> The advantage here is that I assume that a notifier would continually
> have to check whether the clock being modified was one that the DVFS
> notifier cared about. By integrating the CVFS logic into the clk_hw
> itself, it'll only ever get executed for clocks that really care about
> DVFS. Presumably, the code that implements the clk_hw could also use
> some common DVFS library as part of the implementation, and still share
> code. Or perhaps, what about putting DVFS "ops" into a clk_hw alongside
> any other existing ops, and having the clock core call them whenever
> appropriate?

Thanks for your comment Stephen.

I agree to your reflections as well. It will probably be a more
optimized solution going this direction and we don't have to add more
"clk notifier code" to the clk API, which I guess is good.
It would be interesting to get some input from some of the maintainers
to this discussion as well, let's see.

Kind regards
Ulf Hansson
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at