linux-toradex.git/drivers/cpufreq/elanfreq.c, branch v6.4-rc3

cpufreq: Convert to new X86 CPU match macros

2020-03-24T20:31:27+00:00

The new macro set has a consistent namespace and uses C99 initializers
instead of the grufty C89 ones.

Get rid the of most local macro wrappers for consistency. The ones which
make sense for readability are renamed to X86_MATCH*.

In the centrino driver this also removes the two extra duplicates of family
6 model 13 which have no value at all.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov 
Reviewed-by: Greg Kroah-Hartman 
Acked-by: Rafael J. Wysocki 
Link: https://lkml.kernel.org/r/87eetheu88.fsf@nanos.tec.linutronix.de

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152

2019-05-30T18:26:32+00:00

Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 3029 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Allison Randal 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman

cpufreq: elanfreq: Don't validate the frequency table twice

2018-03-20T11:07:52+00:00

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 elanfreq driver.

Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: Add CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING cpufreq driver flag

2017-07-25T22:15:46+00:00

The policy->transition_latency field is used for multiple purposes
today and its not straight forward at all. This is how it is used:

A. Set the correct transition_latency value.

B. Set it to CPUFREQ_ETERNAL because:
   1. We don't want automatic dynamic switching (with
      ondemand/conservative) to happen at all.
   2. We don't know the transition latency.

This patch handles the B.1. case in a more readable way. A new flag for
the cpufreq drivers is added to disallow use of cpufreq governors which
have dynamic_switching flag set.

All the current cpufreq drivers which are setting transition_latency
unconditionally to CPUFREQ_ETERNAL are updated to use it. They don't
need to set transition_latency anymore.

There shouldn't be any functional change after this patch.

Signed-off-by: Viresh Kumar 
Reviewed-by: Dominik Brodowski 
Signed-off-by: Rafael J. Wysocki

cpufreq: Use consistent prefixing via pr_fmt

2016-04-08T23:35:18+00:00

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:18+00:00

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

cpufreq: Use cpufreq_for_each_* macros for frequency table iteration

2014-04-29T22:06:21+00:00

The cpufreq core now supports the cpufreq_for_each_entry and
cpufreq_for_each_valid_entry macros helpers for iteration over the
cpufreq_frequency_table, so use them.

It should have no functional changes.

Signed-off-by: Stratos Karafotis 
Acked-by: Lad, Prabhakar 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: create another field .flags in cpufreq_frequency_table

2014-04-07T12:43:50+00:00

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:00+00:00

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:08+00:00

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