linux-toradex.git/drivers/cpufreq/speedstep-smi.c, branch v6.8

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 166

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

Based on 1 normalized pattern(s):

  licensed under the terms of the gnu gpl license version 2

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

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

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

cpufreq: speedstep: 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 speedstep 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

Annotate hardware config module parameters in drivers/cpufreq/

2017-04-20T11:02:32+00:00

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/cpufreq/.

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
Acked-by: "Rafael J. Wysocki" 
Acked-by: Viresh Kumar 
cc: linux-pm@vger.kernel.org

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: speedstep-smi: enable interrupts when waiting

2015-02-12T01:02:52+00:00

On Dell Latitude C600 laptop with Pentium 3 850MHz processor, the
speedstep-smi driver sometimes loads and sometimes doesn't load with
"change to state X failed" message.

The hardware sometimes refuses to change frequency and in this case, we
need to retry later. I found out that we need to enable interrupts while
waiting. When we enable interrupts, the hardware blockage that prevents
frequency transition resolves and the transition is possible. With
disabled interrupts, the blockage doesn't resolve (no matter how long do
we wait). The exact reasons for this hardware behavior are unknown.

This patch enables interrupts in the function speedstep_set_state that can
be called with disabled interrupts. However, this function is called with
disabled interrupts only from speedstep_get_freqs, so it shouldn't cause
any problem.

Signed-off-by: Mikulas Patocka 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: speedstep-smi: fix decimal printf specifiers

2014-08-07T19:21:52+00:00

The prefix suggests the number should be printed in hex, so use
the %x specifier to do that. Also, these are 32-bit values,
so drop the l characters.

Signed-off-by: Hans Wennborg 
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