Quoting Ulf Hansson (2013-03-20 14:06:14) > On 20 March 2013 15:47, Mike Turquette <mturque...@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 <bilhu...@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@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/linaro-dev _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
