This document discusses the Common Clock Framework (CCF) and plans for Dynamic Voltage and Frequency Scaling (DVFS) support. It notes that CCF has been adopted by many platforms and has DT bindings for common clocks. It outlines open issues with the framework. The document proposes allowing CCF APIs to re-enter themselves, enabling DVFS via rate change notifiers. It provides code examples and discusses using notifiers and regulators to handle voltage scaling during rate changes. Finally, it asks for feedback on topics like how to represent operating points and how to group related rate changes for DVFS transitions.

1. Common Clk Framework
DVFS Roadmap
Mike Turquette
Linaro, Inc.

2. Not a how-to

3. Not a how-to
Not a tutorial

4. Not a how-to
Not a tutorial
Q&A at the end

5. "But I want to know how
to use the framework!"

6. ● Gregory Clement (Free Electrons) did a
great overview presentation at ELC 2013
○ covers the CCF from the perspective of the
framework consumer
○ details construction of some DT bindings
○ http://events.linuxfoundation.
org/images/stories/slides/elc2013_clement.pdf
You are in luck

7. A quick recap

8. Where we are today
● Lots of ARM platforms converted to CCF
○ MIPS support merged and x86 patches on the list
● Many DT bindings
○ Some basic clock types have DT bindings
○ Many platform-specific clock types have bindings
● No new users of clk-private.h
○ Tegra migrated over to dynamic registration
○ OMAP is the only remaining user
■ Discussion on the list is promising
● http://article.gmane.org/gmane.linux.ports.arm.omap/94429

9. Open issues
● clk_round_rate 2GHz issue
● clk.c is too big
● clk-private.h
● __clk_get_name(...)
● clk_unregister and clk_put unimplemented

10. Various core design issues
● registration functions are ugly
● string name lookups for parent clocks
● initializing clocks in early init before slab is
up

11. The future

12. Last week's RFC
● Allows the clk api to re-enter itself
○ Rajagopal Venkat (ST-E/Linaro) had the idea to use
get_current() for establishing context
● Opens the door for dynamic voltage &
frequency scaling (dvfs)
○ accomplished via rate-change notifiers
● Series includes dvfs helper functions
○ convenient for existing users of the OPP library
○ platforms not using OPP library can register their
own callbacks

13. Why reentrancy?

15. Boring code

16. static bool clk_is_reentrant(void)
{
if (mutex_is_locked(&prepare_lock))
if ((void *) atomic_read(&context) == get_current())
return true;
return false;
}

17. static void clk_fwk_lock(void)
{
/* hold the framework-wide lock, context == NULL */
mutex_lock(&prepare_lock);
/* set context for any reentrant calls */
atomic_set(&context, (int) get_current());
}
static void clk_fwk_unlock(void)
{
/* clear the context */
atomic_set(&context, 0);
/* release the framework-wide lock, context == NULL */
mutex_unlock(&prepare_lock);
}

18. int clk_prepare(struct clk *clk)
{
int ret;
/* re-enter if call is from the same context */
if (clk_is_reentrant()) {
ret = __clk_prepare(clk);
goto out;
}
clk_fwk_lock();
ret = __clk_prepare(clk);
clk_fwk_unlock();
out:
return ret;
}
EXPORT_SYMBOL_GPL(clk_prepare);

20. Re-entering the clk api, slow parts
● clk_ops callbacks may now call top-level clk.
h apis
● clk_{un}prepare, clk_set_rate &
clk_set_parent may all call each other
○ above calls can also call clk_{en|dis}able

21. Re-entering the clk api, fast parts
● clk_{en|dis}able may call clk_{en|dis}able
● may not call other clk api functions
○ clk_{un}prepare, clk_set_rate & clk_set_parent may
sleep

22. Useful combinations
● clk_set_rate may now call clk_set_parent
○ does away with __clk_reparent(...)
● clk_set_parent may now call clk_{un}prepare
and clk_{en|dis}able
● clk_{un}prepare may call clk_{un}prepare
and clk_{en|dis}able
○ as shown in the amazing reentrancy diagram

23. ● remove __clk_foo() functions in clk-provider.
h
● update users of __clk_foo() functions to use
the first class versions reentrantly
Todo

24. DVFS

25. DVFS
A proposal

26. Voltage scaling in notifiers
● clk_set_rate and clk_set_parent fire pre
rate-change notifiers and post rate-change
notifiers
○ call regulator_set_voltage()
● devices can register their own notifier
handlers
● clk_{en|dis}able and clk_{un}prepare do not
have notifiers
○ use run-time pm

27. More boring code

28. drivers/clk/dvfs.c
...
/* scaling up? scale voltage before frequency */
if (new_rate > old_rate) {
ret = regulator_set_voltage_tol(di->reg, volt_new, di->tol);
if (ret)
return notifier_from_errno(ret);
}
/* scaling down? scale voltage after frequency */
if (new_rate < old_rate) {
ret = regulator_set_voltage_tol(di->reg, volt_new, di->tol);
if (ret)
return notifier_from_errno(ret);
}
return NOTIFY_OK;

30. Key concepts
● dvfs is device-centric
○ regulator voltage is a function of a device operating
at a given rate
○ distinct from a clock operating at a given rate
● multiple devices may register voltage scaling
callbacks for the same clock
○ integrators do not have to consider all cases ahead
of time
○ driver authors use the voltages from their data sheet

31. Devfreq & cpufreq
● Frameworks implementing dvfs policy
○ policy should be built upon a common method of
implementing dvfs
● devfreq and cpufreq drivers can stop
managing regulators directly
○ removes another barrier from consolidating custom
ARM SoC cpufreq driver into something generic
■ cpufreq-cpu0.c?

32. Where does the data go?
● DT bindings for operating points
○ tie devices, clocks, frequencies, regulators and
voltages together in one place
● Need to gather requirements from you on
the needs of your platform
○ Ideally a single binding can work for all

33. ● group clock rate changes as part of dvfs
transition
○ e.g. scaling CPU frequency requires async bridge
divider updates as well as changing DDR clock
speed
● centralized approach versus distributed
approach
○ must be easy for driver authors
DVFS unresolved topics

34. Alternative approach
● Create a new api
○ dvfs_set_rate() or dvfs_set_opp()
● Does away with relying on clock rate-change
notifiers
● Extra burden on driver authors to learn about
a new api/framework
○ Driver authors must choose whether to use
clk_set_rate or dvfs_set_rate

35. Questions?