kernel/drivers/cpufreq/p4-clockmod.c, branch linux-5.1.y

cpufreq: p4-clockmod: Don't validate the frequency table twice

2018-03-20T11:07:52Z

The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from p4-clockmod driver. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping

2018-02-15T00:15:52Z

x86_mask is a confusing name which is hard to associate with the processor's stepping. Additionally, correct an indent issue in lib/cpu.c. Signed-off-by: Jia Zhang [ Updated it to more recent kernels. ] Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: bp@alien8.de Cc: tony.luck@intel.com Link: http://lkml.kernel.org/r/1514771530-70829-1-git-send-email-qianyue.zj@alibaba-inc.com Signed-off-by: Ingo Molnar

cpufreq: Use consistent prefixing via pr_fmt

2016-04-08T23:35:18Z

Use the more common kernel style adding a define for pr_fmt. Miscellanea: o Remove now unused PFX defines Signed-off-by: Joe Perches Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Convert printk(KERN_ to pr_

2016-04-08T23:35:18Z

Use the more common logging style. Miscellanea: o Coalesce formats o Realign arguments o Add a missing space between a coalesced format Signed-off-by: Joe Perches Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

p4-clockmod: Replace cpu_sibling_mask() with topology_sibling_cpumask()

2015-05-27T13:22:16Z

The former duplicates the functionality of the latter but is neither documented nor arch-independent. Signed-off-by: Bartosz Golaszewski Acked-by: Viresh Kumar Acked-by: Rafael J. Wysocki Cc: Benoit Cousson Cc: Catalin Marinas Cc: Fenghua Yu Cc: Guenter Roeck Cc: Jean Delvare Cc: Jonathan Corbet Cc: Linus Torvalds Cc: Oleg Drokin Cc: Peter Zijlstra Cc: Russell King Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1432645896-12588-6-git-send-email-bgolaszewski@baylibre.com Signed-off-by: Ingo Molnar

cpufreq: create another field .flags in cpufreq_frequency_table

2014-04-07T12:43:50Z

Currently cpufreq frequency table has two fields: frequency and driver_data. driver_data is only for drivers' internal use and cpufreq core shouldn't use it at all. But with the introduction of BOOST frequencies, this assumption was broken and we started using it as a flag instead. There are two problems due to this: - It is against the description of this field, as driver's data is used by the core now. - if drivers fill it with -3 for any frequency, then those frequencies are never considered by cpufreq core as it is exactly same as value of CPUFREQ_BOOST_FREQ, i.e. ~2. The best way to get this fixed is by creating another field flags which will be used for such flags. This patch does that. Along with that various drivers need modifications due to the change of struct cpufreq_frequency_table. Reviewed-by: Gautham R Shenoy Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Remove cpufreq_generic_exit()

2014-03-12T00:06:00Z

cpufreq_generic_exit() is empty now and can be deleted. Signed-off-by: Viresh Kumar 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

cpufreq: Implement light weight ->target_index() routine

2013-10-25T20:42:24Z

Currently, the prototype of cpufreq_drivers target routines is: int target(struct cpufreq_policy *policy, unsigned int target_freq, unsigned int relation); And most of the drivers call cpufreq_frequency_table_target() to get a valid index of their frequency table which is closest to the target_freq. And they don't use target_freq and relation after that. So, it makes sense to just do this work in cpufreq core before calling cpufreq_frequency_table_target() and simply pass index instead. But this can be done only with drivers which expose their frequency table with cpufreq core. For others we need to stick with the old prototype of target() until those drivers are converted to expose frequency tables. This patch implements the new light weight prototype for target_index() routine. It looks like this: int target_index(struct cpufreq_policy *policy, unsigned int index); CPUFreq core will call cpufreq_frequency_table_target() before calling this routine and pass index to it. Because CPUFreq core now requires to call routines present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time. This also marks target() interface as deprecated. So, that new drivers avoid using it. And Documentation is updated accordingly. It also converts existing .target() to newly defined light weight .target_index() routine for many driver. Acked-by: Hans-Christian Egtvedt Acked-by: Jesper Nilsson Acked-by: Linus Walleij Acked-by: Russell King Acked-by: David S. Miller Tested-by: Andrew Lunn Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: p4: don't initialize part of policy set by core

2013-10-15T22:50:31Z

Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Cc: David S. Miller Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki