linux-dev/drivers/cpufreq/tegra-cpufreq.c, branch linus/master

cpufreq: tegra: Rename tegra-cpufreq to tegra20-cpufreq

2015-07-16T07:34:08Z

The Tegra124 will use a different driver for frequency scaling, so rename the old driver (which handles only Tegra20) appropriately. Signed-off-by: Tuomas Tynkkynen Signed-off-by: Mikko Perttunen Acked-by: Viresh Kumar Signed-off-by: Thierry Reding

cpufreq: tegra: update comment for clarity

2014-06-10T20:50:50Z

Tegra's driver got updated a bit (00917dd cpufreq: Tegra: implement intermediate frequency callbacks) and implements new 'intermediate freq' infrastructure of core. Above commit updated comments about when to call clk_prepare_enable(pll_x_clk) and Doug wasn't satisfied with those comments and said this: > The "Though when target-freq is intermediate freq, we don't need to > take this reference." makes me think that this function is actually > called when target-freq is intermediate freq. I don't think it is, > right? For better clarity just make that comment more explicit about when we call tegra_target_intermediate(). Reviewed-by: Stephen Warren Reported-and-reviewed-by: Doug Anderson Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Tegra: implement intermediate frequency callbacks

2014-06-05T21:34:07Z

Tegra has been switching to intermediate frequency (pll_p_clk) forever. CPUFreq core has better support for handling notifications for these frequencies and so we can adapt Tegra's driver to it. Also do a WARN() if clk_set_parent() fails while moving back to pll_x as we should have atleast restored to earlier frequency on error. Tested-by: Stephen Warren Signed-off-by: Viresh Kumar Reviewed-by: Doug Anderson Signed-off-by: Rafael J. Wysocki

cpufreq: Tegra: drop wrapper around tegra_update_cpu_speed()

2014-05-16T23:38:31Z

Tegra has implemented an unnecessary wrapper over tegra_update_cpu_speed(), i.e. tegra_target(), which wasn't doing anything apart of calling tegra_update_cpu_speed(). Get rid of that and use tegra_target() directly. Signed-off-by: Viresh Kumar Acked-by: Stephen Warren Signed-off-by: Rafael J. Wysocki

cpufreq: add 'freq_table' in struct cpufreq_policy

2014-03-12T00:06:00Z

freq table is not per CPU but per policy, so it makes more sense to keep it within struct cpufreq_policy instead of a per-cpu variable. This patch does it. Over that, there is no need to set policy->freq_table to NULL in ->exit(), as policy structure is going to be freed soon. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Tegra: Use cpufreq_generic_suspend()

2014-03-06T14:04:12Z

The cpufreq core now supports suspending and resuming of cpufreq drivers and governors during systems suspend and resume, so use the common infrastructure instead of defining special PM notifiers for the same thing. Signed-off-by: Viresh Kumar Tested-by: Stephen Warren [rjw: Changelog] Signed-off-by: Rafael J. Wysocki

cpufreq: introduce cpufreq_generic_get() routine

2014-01-17T01:00:44Z

CPUFreq drivers that use clock frameworks interface,i.e. clk_get_rate(), to get CPUs clk rate, have similar sort of code used in most of them. This patch adds a generic ->get() which will do the same thing for them. All those drivers are required to now is to set .get to cpufreq_generic_get() and set their clk pointer in policy->clk during ->init(). Acked-by: Hans-Christian Egtvedt Acked-by: Shawn Guo Acked-by: Linus Walleij Acked-by: Shawn Guo Acked-by: Stephen Warren Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Mark ARM drivers with CPUFREQ_NEED_INITIAL_FREQ_CHECK flag

2014-01-06T13:17:25Z

Sometimes boot loaders set CPU frequency to a value outside of frequency table present with cpufreq core. In such cases CPU might be unstable if it has to run on that frequency for long duration of time and so its better to set it to a frequency which is specified in frequency table. On some systems we can't really say what frequency we're running at the moment and so for these we shouldn't check if we are running at a frequency present in frequency table. And so we really can't force this for all the cpufreq drivers. Hence we are created another flag here: CPUFREQ_NEED_INITIAL_FREQ_CHECK that will be marked by platforms which want to go for this check at boot time. Initially this is done for all ARM platforms but others may follow if required. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: tegra: don't error target() when suspended

2013-11-20T22:28:32Z

d4019f0a92ab "cpufreq: move freq change notifications to cpufreq core" added code to the cpufreq core to print an error if a cpufreq driver's .target() function returned an error. This exposed the fact that Tegra's cpufreq driver returns an error when it is ignoring requests due to the system being suspended. Modify Tegra's .target() function not to return an error in this case; this prevents the error prints. The argument is that since the suspend hook can't and doesn't inform the cpufreq core when its requests will be ignored, there's no way for the cpufreq core to squelch them, so it's not an error for the requests to keep coming. This change make the Tegra driver consistent with how the Exynos handles the same situation. Note that s5pv210-cpufreq.c probably suffers from this same issue though. Fixes: d4019f0a92ab (cpufreq: move freq change notifications to cpufreq core) Signed-off-by: Stephen Warren Signed-off-by: Rafael J. Wysocki

cpufreq: move freq change notifications to cpufreq core

2013-10-30T23:11:08Z

Most of the drivers do following in their ->target_index() routines: struct cpufreq_freqs freqs; freqs.old = old freq... freqs.new = new freq... cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE); /* Change rate here */ cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE); This is replicated over all cpufreq drivers today and there doesn't exists a good enough reason why this shouldn't be moved to cpufreq core instead. There are few special cases though, like exynos5440, which doesn't do everything on the call to ->target_index() routine and call some kind of bottom halves for doing this work, work/tasklet/etc.. They may continue doing notification from their own code as flag: CPUFREQ_ASYNC_NOTIFICATION is already set for them. All drivers are also modified in this patch to avoid breaking 'git bisect', as double notification would happen otherwise. Acked-by: Hans-Christian Egtvedt Acked-by: Jesper Nilsson Acked-by: Linus Walleij Acked-by: Russell King Acked-by: Stephen Warren Tested-by: Andrew Lunn Tested-by: Nicolas Pitre Reviewed-by: Lan Tianyu Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki