cpufreq: Move endif to the end of Kconfig file

It is possible to enable few cpufreq drivers, without the framework
being enabled. This happened due to a bug while moving the entries
earlier. Fix it.

cpufreq: Move endif to the end of Kconfig file

It is possible to enable few cpufreq drivers, without the framework
being enabled. This happened due to a bug while moving the entries
earlier. Fix it.

Fixes: 7ee1378736f0 ("cpufreq: Move CPPC configs to common Kconfig and add RISC-V")
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Pierre Gondois <[email protected]>
Reviewed-by: Sunil V L <[email protected]>
Reviewed-by: Sudeep Holla <[email protected]>
Link: https://patch.msgid.link/84ac7a8fa72a8fe20487bb0a350a758bce060965.1736488384.git.viresh.kumar@linaro.org
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

cpufreq: fix using cpufreq-dt as module

This driver can be built as a module since commit 3b062a086984 ("cpufreq:
dt-platdev: Support building as module"), but unfortunately this caused
a regression

cpufreq: fix using cpufreq-dt as module

This driver can be built as a module since commit 3b062a086984 ("cpufreq:
dt-platdev: Support building as module"), but unfortunately this caused
a regression because the cputfreq-dt-platdev.ko module does not autoload.

Usually, this is solved by just using the MODULE_DEVICE_TABLE() macro to
export all the device IDs as module aliases. But this driver is special
due how matches with devices and decides what platform supports.

There are two of_device_id lists, an allow list that are for CPU devices
that always match and a deny list that's for devices that must not match.

The driver registers a cpufreq-dt platform device for all the CPU device
nodes that either are in the allow list or contain an operating-points-v2
property and are not in the deny list.

Enforce builtin compile of cpufreq-dt-platdev to make autoload work.

Fixes: 3b062a086984 ("cpufreq: dt-platdev: Support building as module")
Link: https://lore.kernel.org/all/20241104201424.2a42efdd@akair/
Link: https://lore.kernel.org/all/[email protected]/
Cc: [email protected]
Signed-off-by: Andreas Kemnade <[email protected]>
Reported-by: Radu Rendec <[email protected]>
Reported-by: Javier Martinez Canillas <[email protected]>
[ Viresh: Picked commit log from Javier, updated tags ]
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

cpufreq: add virtual-cpufreq driver

Introduce a virtualized cpufreq driver for guest kernels to improve
performance and power of workloads within VMs.

This driver does two main things:

1. Sends th

cpufreq: add virtual-cpufreq driver

Introduce a virtualized cpufreq driver for guest kernels to improve
performance and power of workloads within VMs.

This driver does two main things:

1. Sends the frequency of vCPUs as a hint to the host. The host uses the
hint to schedule the vCPU threads and decide physical CPU frequency.

2. If a VM does not support a virtualized FIE(like AMUs), it queries the
host CPU frequency by reading a MMIO region of a virtual cpufreq device
to update the guest's frequency scaling factor periodically. This enables
accurate Per-Entity Load Tracking for tasks running in the guest.

Co-developed-by: Saravana Kannan <[email protected]>
Signed-off-by: Saravana Kannan <[email protected]>
Signed-off-by: David Dai <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

cpufreq: Drop CONFIG_ARM and CONFIG_ARM64 dependency on Arm drivers

The CONFIG_ARM and CONFIG_ARM64 dependency is redundant as all the
drivers have necessary sub-arch dependency and don't depend on

cpufreq: Drop CONFIG_ARM and CONFIG_ARM64 dependency on Arm drivers

The CONFIG_ARM and CONFIG_ARM64 dependency is redundant as all the
drivers have necessary sub-arch dependency and don't depend on the
architecture support.

Signed-off-by: Rob Herring (Arm) <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

cpufreq: Add Loongson-3 CPUFreq driver support

Some of LoongArch processors (Loongson-3 series) support DVFS, their
IOCSR.FEATURES has IOCSRF_FREQSCALE set. And they has a micro-core in
the package

cpufreq: Add Loongson-3 CPUFreq driver support

Some of LoongArch processors (Loongson-3 series) support DVFS, their
IOCSR.FEATURES has IOCSRF_FREQSCALE set. And they has a micro-core in
the package called SMC (System Management Controller), which can be
used to detect temperature, control fans, scale frequency and voltage,
etc.

The Loongson-3 CPUFreq driver is very simple now, it communicate with
SMC, get DVFS info, set target frequency from CPUFreq core, and so on.

There is a command list to interact with SMC, widely-used commands in
the CPUFreq driver include:

CMD_GET_VERSION: Get SMC firmware version.

CMD_GET_FEATURE: Get enabled SMC features.

CMD_SET_FEATURE: Enable SMC features, such as basic DVFS, BOOST.

CMD_GET_FREQ_LEVEL_NUM: Get the number of all frequency levels.

CMD_GET_FREQ_BOOST_LEVEL: Get the first boost frequency level.

CMD_GET_FREQ_LEVEL_INFO: Get the detail info of a frequency level.

CMD_GET_FREQ_INFO: Get the current frequency.

CMD_SET_FREQ_INFO: Set the target frequency.

In future we will add automatic frequency scaling, which is similar to
Intel's HWP (HardWare P-State).

Signed-off-by: Binbin Zhou <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
[ Viresh: Minor formatting cleanups, change return type of exit() to
void and use devm_mutex_init() ]
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

cpufreq: Move CPPC configs to common Kconfig and add RISC-V

CPPC related config options are currently defined only in ARM specific
file. However, they are required for RISC-V as well. Instead of cre

cpufreq: Move CPPC configs to common Kconfig and add RISC-V

CPPC related config options are currently defined only in ARM specific
file. However, they are required for RISC-V as well. Instead of creating
a new Kconfig.riscv file and duplicating them, move them to the common
Kconfig file and enable RISC-V too.

Signed-off-by: Sunil V L <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Reviewed-by: Pierre Gondois <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Acked-by: Sudeep Holla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Palmer Dabbelt <[email protected]>

show more ...

arch: Remove Itanium (IA-64) architecture

The Itanium architecture is obsolete, and an informal survey [0] reveals
that any residual use of Itanium hardware in production is mostly HP-UX
or OpenVMS

arch: Remove Itanium (IA-64) architecture

The Itanium architecture is obsolete, and an informal survey [0] reveals
that any residual use of Itanium hardware in production is mostly HP-UX
or OpenVMS based. The use of Linux on Itanium appears to be limited to
enthusiasts that occasionally boot a fresh Linux kernel to see whether
things are still working as intended, and perhaps to churn out some
distro packages that are rarely used in practice.

None of the original companies behind Itanium still produce or support
any hardware or software for the architecture, and it is listed as
'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers
that contributed on behalf of those companies (nor anyone else, for that
matter) have been willing to support or maintain the architecture
upstream or even be responsible for applying the odd fix. The Intel
firmware team removed all IA-64 support from the Tianocore/EDK2
reference implementation of EFI in 2018. (Itanium is the original
architecture for which EFI was developed, and the way Linux supports it
deviates significantly from other architectures.) Some distros, such as
Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have
dropped support years ago.

While the argument is being made [1] that there is a 'for the common
good' angle to being able to build and run existing projects such as the
Grid Community Toolkit [2] on Itanium for interoperability testing, the
fact remains that none of those projects are known to be deployed on
Linux/ia64, and very few people actually have access to such a system in
the first place. Even if there were ways imaginable in which Linux/ia64
could be put to good use today, what matters is whether anyone is
actually doing that, and this does not appear to be the case.

There are no emulators widely available, and so boot testing Itanium is
generally infeasible for ordinary contributors. GCC still supports IA-64
but its compile farm [3] no longer has any IA-64 machines. GLIBC would
like to get rid of IA-64 [4] too because it would permit some overdue
code cleanups. In summary, the benefits to the ecosystem of having IA-64
be part of it are mostly theoretical, whereas the maintenance overhead
of keeping it supported is real.

So let's rip off the band aid, and remove the IA-64 arch code entirely.
This follows the timeline proposed by the Debian/ia64 maintainer [5],
which removes support in a controlled manner, leaving IA-64 in a known
good state in the most recent LTS release. Other projects will follow
once the kernel support is removed.

[0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/
[1] https://lore.kernel.org/all/[email protected]/
[2] https://gridcf.org/gct-docs/latest/index.html
[3] https://cfarm.tetaneutral.net/machines/list/
[4] https://lore.kernel.org/all/[email protected]/
[5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/

Acked-by: Tony Luck <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>

show more ...

cpufreq: Make CONFIG_CPUFREQ_DT_PLATDEV depend on OF

The cpufreq-dt-platform.c driver requires CONFIG_OF to be selected. Mark
it as a dependency.

Reported-by: kernel test robot <[email protected]>
Clos

cpufreq: Make CONFIG_CPUFREQ_DT_PLATDEV depend on OF

The cpufreq-dt-platform.c driver requires CONFIG_OF to be selected. Mark
it as a dependency.

Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

cpufreq: amd-pstate: Set default governor to schedutil

The Kconfig currently defaults the governor to schedutil on x86_64
only when intel-pstate and SMP have been selected.

If the kernel is built o

cpufreq: amd-pstate: Set default governor to schedutil

The Kconfig currently defaults the governor to schedutil on x86_64
only when intel-pstate and SMP have been selected.

If the kernel is built only with amd-pstate, the default governor
should also be schedutil.

Signed-off-by: Mario Limonciello <[email protected]>
Reviewed-by: Leo Li <[email protected]>
Acked-by: Huang Rui <[email protected]>
Tested-by: Perry Yuan <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

cpufreq: dt-platdev: Support building as module

Make the cpufreq platdev driver as tristate so that it can be built
as loadable module.

Also add MODULE_LICENSE to support building as module.

Signe

cpufreq: dt-platdev: Support building as module

Make the cpufreq platdev driver as tristate so that it can be built
as loadable module.

Also add MODULE_LICENSE to support building as module.

Signed-off-by: Zhipeng Wang <[email protected]>
[ Viresh: Merged two commits, included module.h ]
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

drivers/cpufreq: Remove "select SRCU"

Now that the SRCU Kconfig option is unconditionally selected, there is
no longer any point in selecting it. Therefore, remove the "select SRCU"
Kconfig stateme

drivers/cpufreq: Remove "select SRCU"

Now that the SRCU Kconfig option is unconditionally selected, there is
no longer any point in selecting it. Therefore, remove the "select SRCU"
Kconfig statements.

Signed-off-by: Paul E. McKenney <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Reviewed-by: John Ogness <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

cpufreq: loongson1: Delete obsolete driver

The generic DT based cpufreq driver works for Loongson-1,
so delete the old custom driver.

Signed-off-by: Keguang Zhang <[email protected]>
Signed-o

cpufreq: loongson1: Delete obsolete driver

The generic DT based cpufreq driver works for Loongson-1,
so delete the old custom driver.

Signed-off-by: Keguang Zhang <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

cpufreq: remove sa1100 driver

The sa11xx platform has two cpufreq drivers, one for the older
StrongARM1100 SoC, and a second one for StrongARM1110. After
the removal of most SA1100 based machines, t

cpufreq: remove sa1100 driver

The sa11xx platform has two cpufreq drivers, one for the older
StrongARM1100 SoC, and a second one for StrongARM1110. After
the removal of most SA1100 based machines, this driver is unused,
and only the sa1110-cpufreq driver remains.

Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

cpufreq: loongson2: fix Kconfig "its" grammar

Use the possessive "its" instead of the contraction "it's"
where appropriate.

Signed-off-by: Randy Dunlap <[email protected]>
Signed-off-by: Rafael

cpufreq: loongson2: fix Kconfig "its" grammar

Use the possessive "its" instead of the contraction "it's"
where appropriate.

Signed-off-by: Randy Dunlap <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

cpufreq: Kconfig: fix documentation links

User documentation for cpufreq governors and drivers has been moved to
admin-guide; adjust references from Kconfig entries accordingly.

Remove references f

cpufreq: Kconfig: fix documentation links

User documentation for cpufreq governors and drivers has been moved to
admin-guide; adjust references from Kconfig entries accordingly.

Remove references from undocumented cpufreq drivers, as well as the
'userspace' cpufreq governor, for which no additional details are
provided in the admin-guide text.

Fixes: 2a0e49279850 ("cpufreq: User/admin documentation update and consolidation")
Signed-off-by: Alexander Monakov <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

cpufreq: Avoid configuring old governors as default with intel_pstate

Commit 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by
default without HWP") was meant to cause intel_pstate to be use

cpufreq: Avoid configuring old governors as default with intel_pstate

Commit 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by
default without HWP") was meant to cause intel_pstate to be used
in the passive mode with the schedutil governor on top of it, but
it missed the case in which either "ondemand" or "conservative"
was selected as the default governor in the existing kernel config,
in which case the previous old governor configuration would be used,
causing the default legacy governor to be used on top of intel_pstate
instead of schedutil.

Address this by preventing "ondemand" and "conservative" from being
configured as the default cpufreq governor in the case when schedutil
is the default choice for the default governor setting.

[Note that the default cpufreq governor can still be set via the
kernel command line if need be and that choice is not limited,
so if anyone really wants to use one of the legacy governors by
default, it can be achieved this way.]

Fixes: 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default without HWP")
Reported-by: Julia Lawall <[email protected]>
Cc: 5.8+ <[email protected]> # 5.8+
Signed-off-by: Rafael J. Wysocki <[email protected]>
Acked-by: Viresh Kumar <[email protected]>

show more ...

cpufreq: make schedutil the default for arm and arm64

schedutil is already a hard-requirement for EAS, which has lead to making
it default on arm (when CONFIG_BIG_LITTLE), see:

commit 8fdcca8e254

cpufreq: make schedutil the default for arm and arm64

schedutil is already a hard-requirement for EAS, which has lead to making
it default on arm (when CONFIG_BIG_LITTLE), see:

commit 8fdcca8e254a ("cpufreq: Select schedutil when using big.LITTLE")

One thing worth pointing out is that schedutil isn't only relevant for
asymmetric CPU capacity systems; for instance, schedutil is the only
governor that honours util-clamp performance requests. Another good example
of this is x86 switching to using it by default in:

commit a00ec3874e7d ("cpufreq: intel_pstate: Select schedutil as the default governor")

Arguably it should be made the default for all architectures, but it seems
better to wait for them to also gain frequency invariance powers. Make it
the default for arm && arm64 for now.

Signed-off-by: Valentin Schneider <[email protected]>
Signed-off-by: Ionela Voinescu <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Russell King <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Viresh Kumar <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

cpufreq: qoriq: Add platform dependencies

The Freescale QorIQ clock controller is only present on Freescale E500MC
and Layerscape SoCs. Add platform dependencies to the QORIQ_CPUFREQ
config symbol,

cpufreq: qoriq: Add platform dependencies

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: Geert Uytterhoeven <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Li Yang <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

cpufreq: Select schedutil when using big.LITTLE

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:

cpufreq: Select schedutil when using big.LITTLE

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: Arnd Bergmann <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Acked-by: Sudeep Holla <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

cpufreq: intel_pstate: Select schedutil as the default governor

Modify cpufreq Kconfig to select schedutil as the default governor
if the intel_pstate driver has been selected and SMP support is
ena

cpufreq: intel_pstate: Select schedutil as the default governor

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: Rafael J. Wysocki <[email protected]>

show more ...

treewide: Add SPDX license identifier - Makefile/Kconfig

Add SPDX license identifiers to all Make/Kconfig files which:

- Have no license information of any form

These files fall under the project

treewide: Add SPDX license identifier - Makefile/Kconfig

Add SPDX license identifiers to all Make/Kconfig files which:

- Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

GPL-2.0-only

Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

cpufreq: boost: Remove CONFIG_CPU_FREQ_BOOST_SW Kconfig option

Commit 2fb4719b2560 ("cpufreq / boost: Kconfig: Support for
software-managed BOOST") added the CONFIG_CPU_FREQ_BOOST_SW config.
However

cpufreq: boost: Remove CONFIG_CPU_FREQ_BOOST_SW Kconfig option

Commit 2fb4719b2560 ("cpufreq / boost: Kconfig: Support for
software-managed BOOST") added the CONFIG_CPU_FREQ_BOOST_SW config.
However EXYNOS based cpufreq drivers have been removed because of
switching to cpufreq-dt driver which will set boost-attr if required.

So, let's remove this option and update cpufreq_generic_attr[].

Signed-off-by: Yue Hu <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

thermal: cpu_cooling: Require thermal core to be compiled in

The CPU cooling driver (cpu_cooling.c) allows the platform's cpufreq
driver to register as a cooling device and cool down the platform by

thermal: cpu_cooling: Require thermal core to be compiled in

The CPU cooling driver (cpu_cooling.c) allows the platform's cpufreq
driver to register as a cooling device and cool down the platform by
throttling the CPU frequency. In order to be able to auto-register a
cpufreq driver as a cooling device from the cpufreq core, we need access
to code inside cpu_cooling.c which, in turn, accesses code inside
thermal core.

CPU_FREQ is a bool while THERMAL is tristate. In some configurations
(e.g. allmodconfig), CONFIG_THERMAL ends up as a module while
CONFIG_CPU_FREQ is compiled in. This leads to following error:

drivers/cpufreq/cpufreq.o: In function `cpufreq_offline':
cpufreq.c:(.text+0x407c): undefined reference to `cpufreq_cooling_unregister'
drivers/cpufreq/cpufreq.o: In function `cpufreq_online':
cpufreq.c:(.text+0x70c0): undefined reference to `of_cpufreq_cooling_register'

Given that platforms using CPU_THERMAL usually want it compiled-in so it
is available early in boot, make CPU_THERMAL depend on THERMAL being
compiled-in instead of allowing it to be a module.

As a result of this change, get rid of the ugly (!CPU_THERMAL ||
THERMAL) dependency in all cpufreq drivers using CPU_THERMAL.

Suggested-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Amit Kucheria <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

cpufreq: remove at32ap-cpufreq

Since AVR32 arch was removed, at32ap-cpufreq is useless.
Remove this driver.

Signed-off-by: Corentin Labbe <[email protected]>
Acked-by: Viresh Kumar <viresh.

cpufreq: remove at32ap-cpufreq

Since AVR32 arch was removed, at32ap-cpufreq is useless.
Remove this driver.

Signed-off-by: Corentin Labbe <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

cpufreq: Add Loongson machine dependencies

The MIPS loongson cpufreq drivers don't build unless configured for the
correct machine type, due to dependency on machine specific architecture
headers an

cpufreq: Add Loongson machine dependencies

The MIPS loongson cpufreq drivers don't build unless configured for the
correct machine type, due to dependency on machine specific architecture
headers and symbols in machine specific platform code.

More specifically loongson1-cpufreq.c uses RST_CPU_EN and RST_CPU,
neither of which is defined in asm/mach-loongson32/regs-clk.h unless
CONFIG_LOONGSON1_LS1B=y, and loongson2_cpufreq.c references
loongson2_clockmod_table[], which is only defined in
arch/mips/loongson64/lemote-2f/clock.c, i.e. when
CONFIG_LEMOTE_MACH2F=y.

Add these dependencies to Kconfig to avoid randconfig / allyesconfig
build failures (e.g. when based on BMIPS which also has a cpufreq
driver).

Signed-off-by: James Hogan <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...