If intel_pstate starts in the passive mode by default (that happens
when the processor in the system doesn't support HWP), passing
intel_pstate=active in the kernel command line doesn't work, so
fix that.

Fixes: 33aa46f2 ("cpufreq: intel_pstate: Use passive mode by default without HWP")
Reported-by: NDoug Smythies <dsmythies@telus.net>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NDoug Smythies <dsmythies@telus.net>

Add one more bit for OOB (Out Of Band) enabling of P-states.

If OOB handling of P-states is enabled, intel_pstate shouldn't load.
Currently, only "BIT(8) == 1" of the MSR MSR_MISC_PWR_MGMT is
considered as OOB, but "BIT(18) == 1" needs to be taken into
consideration as OOB condition too.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[ rjw: Add an empty code line, edit subject and changelog ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since commit 84af7a61 ("checkpatch: kconfig: prefer 'help' over
'---help---'"), the number of '---help---' has been gradually
decreasing, but there are still more than 2400 instances.

This commit finishes the conversion. While I touched the lines,
I also fixed the indentation.

There are a variety of indentation styles found.

  a) 4 spaces + '---help---'
  b) 7 spaces + '---help---'
  c) 8 spaces + '---help---'
  d) 1 space + 1 tab + '---help---'
  e) 1 tab + '---help---'    (correct indentation)
  f) 1 tab + 1 space + '---help---'
  g) 1 tab + 2 spaces + '---help---'

In order to convert all of them to 1 tab + 'help', I ran the
following commend:

  $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

To add SW BOOST support for CPPC, we need to get the max frequency of
boost mode and non-boost mode. ACPI spec 6.2 section 8.4.7.1 describes
the following two CPC registers.

"Highest performance is the absolute maximum performance an individual
processor may reach, assuming ideal conditions. This performance level
may not be sustainable for long durations, and may only be achievable if
other platform components are in a specific state; for example, it may
require other processors be in an idle state.

Nominal Performance is the maximum sustained performance level of the
processor, assuming ideal operating conditions. In absence of an
external constraint (power, thermal, etc.) this is the performance level
the platform is expected to be able to maintain continuously. All
processors are expected to be able to sustain their nominal performance
state simultaneously."

To add SW BOOST support for CPPC, we can use Highest Performance as the
max performance in boost mode and Nominal Performance as the max
performance in non-boost mode. If the Highest Performance is greater
than the Nominal Performance, we assume SW BOOST is supported.

The current CPPC driver does not support SW BOOST and use 'Highest
Performance' as the max performance the CPU can achieve. 'Nominal
Performance' is used to convert 'performance' to 'frequency'. That
means, if firmware enable boost and provide a value for Highest
Performance which is greater than Nominal Performance, boost feature is
enabled by default.

Because SW BOOST is disabled by default, so, after this patch, boost
feature is disabled by default even if boost is enabled by firmware.
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Suggested-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
[ rjw: Subject ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Macro 'for_each_active_policy()' is defined internally. To avoid some
cpufreq driver needing this macro to iterate over all the policies in
'.set_boost' callback, we redefine '.set_boost' to act on only one
policy and pass the policy as an argument.

'cpufreq_boost_trigger_state()' iterates over all the policies to set
boost for the system.

This is preparation for adding SW BOOST support for CPPC.

To protect Boost enable/disable by sysfs from CPU online/offline,
add 'cpu_hotplug_lock' before calling '.set_boost' for each CPU.

Also move the lock from 'set_boost()' to 'store_cpb()' in
acpi_cpufreq.
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Suggested-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
[ rjw: Subject & changelog ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In addition to clocks and regulators, some devices can scale the bandwidth
of their on-chip interconnect - for example between CPU and DDR memory. Add
support for that, so that platforms which support it can make use of it.
Signed-off-by: NGeorgi Djakov <georgi.djakov@linaro.org>
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
[ Viresh: Reused dev_pm_opp_of_find_icc_paths(). Also drop the depends
	  on from Kconfig. ]
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

fixup! cpufreq: dt: Add support for interconnect bandwidth scaling

After commit 18c49926 ("cpufreq: Add QoS requests for userspace
constraints") the return value of freq_qos_update_request(), that can
be 1, passed by cpufreq_boost_set_sw() to its caller sometimes
confuses the latter, which only expects to see 0 or negative error
codes, so notice that cpufreq_boost_set_sw() can return an error code
(which should not be -EINVAL for that matter) as soon as the first
policy without a frequency table is found (because either all policies
have a frequency table or none of them have it) and rework it to meet
its caller's expectations.

Fixes: 18c49926 ("cpufreq: Add QoS requests for userspace constraints")
Reported-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Reported-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: 5.3+ <stable@vger.kernel.org> # 5.3+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The driver doesn't provide ->get() method to read current frequency and
the frequency is set to 0 at initialization which makes the driver fail
at initialization time.

Set the CPUFREQ_NEED_INITIAL_FREQ_CHECK flag for the driver, so the
cpufreq core checks for the unlisted frequency and sets the CPU to a
valid frequency from the frequency table.
Signed-off-by: NMian Yousaf Kaukab <ykaukab@suse.de>
[ Viresh: Massaged change log ]
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

The Freescale QorIQ clock controller is only present on Freescale E500MC
and Layerscape SoCs.  Add platform dependencies to the QORIQ_CPUFREQ
config symbol, to avoid asking the user about it when configuring a
kernel without E500MC or Layerscape support.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NLi Yang <leoyang.li@nxp.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

The driver has to be manually loaded if it is built as a module. It
is neither exporting MODULE_DEVICE_TABLE nor MODULE_ALIAS. Moreover,
no platform-device is created (and thus no uevent is sent) for the
clockgen nodes it depends on.

Convert the module to a platform driver with its own alias. Moreover,
drop whitelisted SOCs. Platform device will be created only for the
compatible platforms.
Reviewed-by: NYuantian Tang <andy.tang@nxp.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NMian Yousaf Kaukab <ykaukab@suse.de>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

Re-parenting to intermediate clock is supported now by the clock driver
and thus there is no need in a customized CPUFreq driver, all that code
is common for both Tegra20 and Tegra30. The available CPU freqs are now
specified in device-tree in a form of OPPs, all users should update their
device-trees.
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NPeter De Schrijver <pdeschrijver@nvidia.com>
Tested-by: NPeter Geis <pgwipeout@gmail.com>
Tested-by: NMarcel Ziswiler <marcel@ziswiler.com>
Tested-by: NJasper Korten <jja2000@gmail.com>
Tested-by: NDavid Heidelberg <david@ixit.cz>
Tested-by: NNicolas Chauvet <kwizart@gmail.com>
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Binding in Documentation is still "operating-points-v2-kryo-cpu".
Restore the old binding to fix the compatibility problem.

Fixes: a8811ec7 ("cpufreq: qcom: Add support for krait based socs")
Signed-off-by: NAnsuel Smith <ansuelsmth@gmail.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

i.MX7ULP's ARM core clock design is totally different compared
with i.MX7D/8M SoCs which supported by imx-cpufreq-dt. It needs
get_intermediate and target_intermedate to configure clk MUX ready,
before let OPP configure ARM core clk.
                                          |---FIRC
     |------RUN---...---SCS(MUX2) --------|
ARM --(MUX1)                              |---SPLL_PFD0(CLK_SET_RATE_GATE)
     |------HSRUN--...--HSRUN_SCS(MUX3)---|
                                          |---SRIC

FIRC is step clk, SPLL_PFD0 is the normal clk driving ARM core.
MUX2 and MUX3 share same inputs. So if MUX2/MUX3 both sources from
SPLL_PFD0, both MUXes will lose input when configure SPLL_PFD0.
So the target_intermediate will configure MUX2/MUX3 to FIRC, to avoid
ARM core lose clk when configure SPLL_PFD0.
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

Add the compatible strings for supporting the generic cpufreq driver on
the Renesas RZ/G1H (R8A7742) SoC.
Signed-off-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: NMarian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

Add i.MX7ULP to cpufreq-dt-platdev blacklist.
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

When building the mult_v7_defconfig, ARM_TI_CPUFREQ doesn't get enabled
evenwhen ARCH_OMAP(3|4) is selected. Build ARM_TI_CPUFREQ by default for
ARCH_OMAP2PLUS.
Signed-off-by: NAnders Roxell <anders.roxell@linaro.org>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

Make a note of the first time we discover the turbo mode has been
disabled by the BIOS, as otherwise we complain every time we try to
update the mode.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

After recent changes allowing scale-invariant utilization to be
used on x86, the schedutil governor on top of intel_pstate in the
passive mode should be on par with (or better than) the active mode
"powersave" algorithm of intel_pstate on systems in which
hardware-managed P-states (HWP) are not used, so it should not be
necessary to use the internal scaling algorithm in those cases.

Accordingly, modify intel_pstate to start in the passive mode by
default if the processor at hand does not support HWP of if the driver
is requested to avoid using HWP through the kernel command line.

Among other things, that will allow utilization clamps and the
support for RT/DL tasks in the schedutil governor to be utilized on
systems in which intel_pstate is used.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

As platforms are moving to COMMON_CLK in general, loongson2ef
stuck out as something that has a private implementation but
does not actually use it except for setting the frequency of
the CPU itself from the loongson2_cpufreq driver.

Change that driver to call the register setting function directly
and remove the rest of the stub implementation.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>

When we are using a system with big.LITTLE HMP
configuration, we need to use EAS to schedule the
system.

As can be seen from kernel/sched/topology.c:

 "EAS can be used on a root domain if it meets all the following conditions:
  1. an Energy Model (EM) is available;
  2. the SD_ASYM_CPUCAPACITY flag is set in the sched_domain hierarchy.
  3. no SMT is detected.
  4. the EM complexity is low enough to keep scheduling overheads low;
  5. schedutil is driving the frequency of all CPUs of the rd;"

This means that at the very least, schedutil needs to be
available as a scheduling policy for EAS to work on these
systems. Make this explicit by defaulting to the schedutil
governor if BIG_LITTLE is selected.

Currently users of the TC2 board (like me) has to figure these
dependencies out themselves and it is not helpful.
Suggested-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NSudeep Holla <sudeep.holla@arm.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Modify cpufreq Kconfig to select schedutil as the default governor
if the intel_pstate driver has been selected and SMP support is
enabled (because schedutil depends on SMP).

Also select schedutil as well as the performance governor from the
intel_pstate Kconfig section to ensure the equivalence of the passive
and active mode governor configuration options.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The initial policy value set by intel_pstate_cpu_init() depends on
whether or not CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is set, but
that is not necessary, because the core will set the policy to
"performance" in cpufreq_init_policy() if the default governor is
"performance" anyway.

Accordingly, change intel_pstate_cpu_init() to always set policy
to CPUFREQ_POLICY_POWERSAVE initially to provide a valid fallback
value to cpufreq_init_policy() in case the default cpufreq governor
is neither "powersave" nor "performance".
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The feature flag hwp_support_ids are supposed to match on is
X86_FEATURE_HWP, not X86_FEATURE_APERFMPERF. Fix it.

 [ bp: Write commit message. ]

Fixes: b11d77fa ("cpufreq: Convert to new X86 CPU match macros")
Reported-by: Nkernel test robot <rong.a.chen@intel.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20200324060124.GC11705@shao2-debian

The patch avoids allocating cpufreq_policy on stack hence fixing frame
size overflow in 'powernv_cpufreq_work_fn'

Fixes: 22794280 ("cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling")
Signed-off-by: NPratik Rajesh Sampat <psampat@linux.ibm.com>
Reviewed-by: NDaniel Axtens <dja@axtens.net>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200316135743.57735-1-psampat@linux.ibm.com

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: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lkml.kernel.org/r/87eetheu88.fsf@nanos.tec.linutronix.de

There is no reason that this gunk is in a generic header file. The wildcard
defines need to stay as they are required by file2alias.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lkml.kernel.org/r/20200320131508.736205164@linutronix.de

In Certain QCOM SoCs like ipq8064, apq8064, msm8960, msm8974
that has KRAIT processors the voltage/current value of each OPP
varies based on the silicon variant in use.

The required OPP related data is determined based on
the efuse value. This is similar to the existing code for
kryo cores. So adding support for krait cores here.
Signed-off-by: NSricharan R <sricharan@codeaurora.org>
Signed-off-by: NAnsuel Smith <ansuelsmth@gmail.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

Improve the -EPROBE_DEFER handling logic to simplify the code.
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit.  Fix it by replacing with scnprintf().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is still some code duplication between intel_pstate_verify_policy()
and intel_cpufreq_verify_policy(), so avoid it by moving the common
code into a separate function and calling it from both these places.

No intentional functional impact.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The PowerNV cpufreq driver registers two notifiers: one to catch
throttle messages from the OCC and one to bump the CPU frequency back
to normal before a reboot. Both require the cpufreq driver to be
registered in order to function since the notifier callbacks use
various cpufreq_*() functions.

Right now we register both notifiers before we've initialised the
driver. This seems to work, but we should head off any protential
problems by registering the notifiers after the driver is initialised.
Signed-off-by: NOliver O'Halloran <oohall@gmail.com>
Reviewed-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200206062622.28235-2-oohall@gmail.com

The cpufreq driver has a use-after-free that we can hit if:

a) There's an OCC message pending when the notifier is registered, and
b) The cpufreq driver fails to register with the core.

When a) occurs the notifier schedules a workqueue item to handle the
message. The backing work_struct is located on chips[].throttle and
when b) happens we clean up by freeing the array. Once we get to
the (now free) queued item and the kernel crashes.

Fixes: c5e29ea7 ("cpufreq: powernv: Fix bugs in powernv_cpufreq_{init/exit}")
Cc: stable@vger.kernel.org # v4.6+
Signed-off-by: NOliver O'Halloran <oohall@gmail.com>
Reviewed-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200206062622.28235-1-oohall@gmail.com

Platforms may need to implement platform specific get_intermediate and
target_intermediate hooks.

Update cpufreq-dt driver's platform data to contain those for such
platforms.
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

i.MX8MP's market segment fuse field is bit[6:5], correct it.

Fixes: 83fe39ad ("cpufreq: imx-cpufreq-dt: Add i.MX8MP support")
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

Add weak function to return the hardware maximum frequency of a CPU,
with the default implementation returning cpuinfo.max_freq, which is
the best information we can generically get from the cpufreq framework.

The default can be overwritten by a strong function in platforms
that want to provide an alternative implementation, with more accurate
information, obtained either from hardware or firmware.
Signed-off-by: NIonela Voinescu <ionela.voinescu@arm.com>
Reviewed-by: NValentin Schneider <valentin.schneider@arm.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

The old cpufreq docs got moved. Let's also update its
pointer inside Kconfig.x86.

Fixes: 03b22496 ("Documentation: cpufreq: Move legacy driver documentation")
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Directly accessing OCOTP registers should be avoided, because
it could not handle OCOTP clks and could not handle defer
proper. With nvmem API, it is safe to access OCOTP registers.

To make sure old dtb could work, the original code still kept.
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

When speed checking failed, direclty jumping to put_node label
is not correct. Need jump to out_free_opp to avoid resources leak.

Fixes: 2733fb0d ("cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull")
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

Before commit 1e4f63ae ("cpufreq: Avoid creating excessively
large stack frames") the initial value of the policy field in struct
cpufreq_policy set by the driver's ->init() callback was implicitly
passed from cpufreq_init_policy() to cpufreq_set_policy() if the
default governor was neither "performance" nor "powersave".  After
that commit, however, cpufreq_init_policy() must take that case into
consideration explicitly and handle it as appropriate, so make that
happen.

Fixes: 1e4f63ae ("cpufreq: Avoid creating excessively large stack frames")
Link: https://lore.kernel.org/linux-pm/39fb762880c27da110086741315ca8b111d781cd.camel@gmail.com/Reported-by: NArtem Bityutskiy <dedekind1@gmail.com>
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>

The cpufreq-dt driver allows cpufreq driver enabled without valid
regulator assigned, however, all i.MX platforms using cpufreq-dt
driver now require valid regulator, add "cpu-supply" property check
to avoid i.MX platforms' cpufreq enabled without valid regulator
and lead to system unstable.
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>