Upload
linaro
View
381
Download
2
Tags:
Embed Size (px)
DESCRIPTION
Resource: LCA13 Name: Common Clk Framework DVFS Roadmap Date: 06-03-2013 Speaker: Mike Turquette
Citation preview
Common Clk Framework DVFS RoadmapMike TurquetteLinaro, Inc.
Not a how-to
Not a how-toNot a tutorial
Not a how-toNot a tutorialQ&A at the end
"But I want to know how to use the framework!"
● 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
A quick recap
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
Open issues
● clk_round_rate 2GHz issue
● clk.c is too big
● clk-private.h
● __clk_get_name(...)
● clk_unregister and clk_put unimplemented
Various core design issues
● registration functions are ugly
● string name lookups for parent clocks
● initializing clocks in early init before slab is up
The future
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
Why reentrancy?
Boring code
static bool clk_is_reentrant(void){ if (mutex_is_locked(&prepare_lock)) if ((void *) atomic_read(&context) == get_current()) return true;
return false;}
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);}
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);
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
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
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
● remove __clk_foo() functions in clk-provider.h
● update users of __clk_foo() functions to use the first class versions reentrantly
Todo
DVFS
DVFSA proposal
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
More boring code
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;
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
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?
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
● 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
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
Questions?