[PATCH 1/1] clk: Add notifier support in clk_prepare/clk_unprepare

[mturquette@linaro.org (Mike Turquette)]

Quoting Ulf Hansson (2013-03-20 14:06:14)
> On 20 March 2013 15:47, Mike Turquette <mturquette@linaro.org> wrote:
> > Quoting Bill Huang (2013-03-19 21:39:44)
> >> On Wed, 2013-03-20 at 11:31 +0800, Mike Turquette wrote:
> >> > Quoting Bill Huang (2013-03-19 19:55:49)
> >> > > On Wed, 2013-03-20 at 01:01 +0800, Mike Turquette wrote:
> >> > > > Quoting Bill Huang (2013-03-19 06:28:32)
> >> > > > > Add notifier calls in clk_prepare and clk_unprepare so drivers which are
> >> > > > > interested in knowing that clk_prepare/unprepare call can act accordingly.
> >> > > > >
> >> > > > > The existing "clk_set_rate" notifier is not enough for normal DVFS
> >> > > > > inplementation since clock might be enabled/disabled at runtime. Adding
> >> > > > > these notifiers is useful on DVFS core which take clk_prepare as a hint
> >> > > > > on that the notified clock might be enabled later so it can raise voltage
> >> > > > > to a safe level before enabling the clock, and take clk_unprepare as a
> >> > > > > hint that the clock has been disabled and is safe to lower the voltage.
> >> > > > >
> >> > > > > The added notifier events are:
> >> > > > >
> >> > > > > PRE_CLK_PREPARE
> >> > > > > POST_CLK_PREPARE
> >> > > > > ABORT_CLK_PREPARE
> >> > > > > PRE_CLK_UNPREPARE
> >> > > > > POST_CLK_UNPREPARE
> >> > > > >
> >> > > > > Signed-off-by: Bill Huang <bilhuang@nvidia.com>
> >> > > >
> >> > > > I'm still not sure about this approach.  Based on feedback I got from
> >> > > > Linaro Connect I am not convinced that scaling voltage through clk
> >> > > > rate-change notifiers is the right way to go.  As I understand it this
> >> > > > patch only exists for that single purpose, so if the voltage-notifier
> >> > > > idea gets dropped then I will not take this patch in.
> >> > > >
> >> > > Thanks Mike, actually we won't use your "clk: notifier handler for
> >> > > dynamic voltage scaling" patch instead we are trying to port our DVFS
> >> > > into Non-CPU DVFS framework "devfreq" which will need to hook those
> >> > > notifiers, without the clock notifiers been extended the framework is
> >> > > useless for us since we cannot do polling due to the fact that polling
> >> > > is not in real time. If it ended up extending the notifiers cannot
> >> > > happen then the only choice for us I think would be giving up "devfreq"
> >> > > and implement them in Tegra's "clk_hw".
> >> >
> >> > I'm familiar with the devfreq framework.  Can you explain further how
> >> > you plan to use devfreq with the clock notifiers?  What does the call
> >> > graph look like?
> >> >
> >> The call graph will look like this, when any DVFS interested clock rate
> >> changes (including enable and disable) happen -> Tegra devfreq clock
> >> notifier is called -> call into update_devfreq if needed -> in
> >> update_devfreq it will call into .get_target_freq in Tegra
> >> "devfreq_governor" -> and then call into .target of tegra
> >> devfreq_dev_profile to set voltage and done. More details are as below.
> >>
> >> We'll create devfreq driver for Tegra VDD_CORE rail, and the safe
> >> voltage level of the rail is determined by tens of clocks (2d, 3d,
> >> mpe,...), all the frequency ladders of those clocks are defined in DT
> >> also the operating points for VDD_CORE is declared in DT where its
> >> frequency will be more of a virtual clock or index.
> >>
> >>         operating-points = <
> >>         /* virtual-kHz  uV */
> >>         0       950000
> >>         1       1000000
> >>         2       1050000
> >>         3       1100000
> >>         4       1150000
> >>         5       1200000
> >>         6       1250000
> >>         7       1300000
> >>         8       1350000
> >>
> >> Register a Tegra governor where the callback .get_target_freq is the
> >> function to determine the overall frequency it can go to, and
> >> the .target callback in "devfreq_dev_profile" will be the function
> >> really do the voltage scaling.
> >>
> >> Tegra devfreq driver will register clock notifiers on all its interested
> >> clock and hence when any of those clock rate changes, disabled, enabled,
> >> we'll specifically call update_devfreq in the notifier.
> >
> > Thank you for the explanation.  Do you plan to use actual devfreq
> > governors (like simple-ondemand, or something custom) for changing OPPs,
> > or do you just plan to use the clock framework as a trigger for DVFS?
> >
> > Regards,
> > Mike
> 
> At a recent discussion regarding a previous version of this patch
> "[RFC 1/1] clk: Add notifier support in
> clk_prepare_enable/clk_disable_unprepare", we also discussed
> whether to use clk notifiers or to use a clk hw to implement DVFS.
> 
> Stephen Warren an myself, kind of pointed out that there could be
> benefits of not using notifers. I would just like to add that to this
> discussion as well.
> 
> The idea in principle, could be as an option to Bill's idea, using
> devfreq with notifiers, to implement a clk hw which possibly makes use
> of the opp libary and do implements the DVFS functionallity that is
> needed for each SoC.
> 

To my knowledge, devfreq performs one task: implements an algorithm
(typically one that loops/polls) and applies this heuristic towards a
dvfs transition.

It is a policy layer, a high level layer.  It should not be used as a
lower-level mechanism.  Please correct me if my understanding is wrong.

I think the very idea of the clk framework calling into devfreq is
backwards.  Ideally a devfreq driver would call clk_set_rate as part of
it's target callback.  This is analogous to a cpufreq .target callback
which calls clk_set_rate and regulator_set_voltage.  Can you imagine the
clock framework cross-calling into cpufreq when clk_set_rate is called?
I think that would be strange.

I think that all of this discussion highlights the fact that there is a
missing piece of infrastructure.  It isn't devfreq or clock rate-change
notifiers.  It is that there is not a dvfs mechanism which neatly builds
on top of these lower-level frameworks (clocks & regulators).  Clearly
some higher-level abstraction layer is needed.

As I mentioned in the v1 thread I'm hacking on something now and I'll
try to get it on the list soon.

Regards,
Mike

> Kind regards
> Ulf Hansson
> 
> >
> > _______________________________________________
> > linaro-dev mailing list
> > linaro-dev at lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/linaro-dev