linux-stable.git/drivers/powercap, branch v6.6.53

powercap/intel_rapl: Add support for AMD family 1Ah

2024-09-30T14:25:13+00:00

[ Upstream commit 166df51097a258a14fe9e946e2157f3b75eeb3c2 ]

AMD Family 1Ah's RAPL MSRs are identical to Family 19h's,
extend Family 19h's support to Family 1Ah.

Signed-off-by: Dhananjay Ugwekar 
Reviewed-by: Gautham R. Shenoy 
Link: https://patch.msgid.link/20240719101234.50827-1-Dhananjay.Ugwekar@amd.com
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

powercap: intel_rapl_tpmi: Fix System Domain probing

2024-04-03T13:28:19+00:00

[ Upstream commit 903eb9fb85e32810f376a2858aad77c9298f9488 ]

Only domain root packages can enumerate System (Psys) domain.
Whether a package is domain root or not is described in the Bit 0 of the
Domain Info register.

Add support for Domain Info register and fix the System domain probing
accordingly.

Fixes: 9eef7f9da928 ("powercap: intel_rapl: Introduce RAPL TPMI interface driver")
Signed-off-by: Zhang Rui 
Cc: 6.5+  # 6.5+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

powercap: intel_rapl_tpmi: Fix a register bug

2024-04-03T13:28:19+00:00

[ Upstream commit faa9130ce716b286d786d59032bacfd9052c2094 ]

Add the missing Domain Info register. This also fixes the bogus
definition of the Interrupt register.

Neither of these two registers was used previously.

Fixes: 9eef7f9da928 ("powercap: intel_rapl: Introduce RAPL TPMI interface driver")
Signed-off-by: Zhang Rui 
Cc: 6.5+  # 6.5+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

powercap: intel_rapl: Fix locking in TPMI RAPL

2024-04-03T13:28:19+00:00

[ Upstream commit 1aa09b9379a7a644cd2f75ae0bac82b8783df600 ]

The RAPL framework uses CPU hotplug locking to protect the rapl_packages
list and rp->lead_cpu to guarantee that

 1. the RAPL package device is not unprobed and freed
 2. the cached rp->lead_cpu is always valid

for operations like powercap sysfs accesses.

Current RAPL APIs assume being called from CPU hotplug callbacks which
hold the CPU hotplug lock, but TPMI RAPL driver invokes the APIs in the
driver's .probe() function without acquiring the CPU hotplug lock.

Fix the problem by providing both locked and lockless versions of RAPL
APIs.

Fixes: 9eef7f9da928 ("powercap: intel_rapl: Introduce RAPL TPMI interface driver")
Signed-off-by: Zhang Rui 
Cc: 6.5+  # 6.5+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

powercap: intel_rapl: Fix a NULL pointer dereference

2024-04-03T13:28:18+00:00

[ Upstream commit 2d1f5006ff95770da502f8cee2a224a1ff83866e ]

A NULL pointer dereference is triggered when probing the MMIO RAPL
driver on platforms with CPU ID not listed in intel_rapl_common CPU
model list.

This is because the intel_rapl_common module still probes on such
platforms even if 'defaults_msr' is not set after commit 1488ac990ac8
("powercap: intel_rapl: Allow probing without CPUID match"). Thus the
MMIO RAPL rp->priv->defaults is NULL when registering to RAPL framework.

Fix the problem by adding sanity check to ensure rp->priv->rapl_defaults
is always valid.

Fixes: 1488ac990ac8 ("powercap: intel_rapl: Allow probing without CPUID match")
Signed-off-by: Zhang Rui 
Cc: 6.5+  # 6.5+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

powercap: dtpm_cpu: Fix error check against freq_qos_add_request()

2024-03-26T22:19:31+00:00

[ Upstream commit b50155cb0d609437236c88201206267835c6f965 ]

The caller of the function freq_qos_add_request() checks again a non
zero value but freq_qos_add_request() can return '1' if the request
already exists. Therefore, the setup function fails while the QoS
request actually did not failed.

Fix that by changing the check against a negative value like all the
other callers of the function.

Fixes: 0e8f68d7f0485 ("Add CPU energy model based support")
Signed-off-by: Daniel Lezcano 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

powercap: DTPM: Fix missing cpufreq_cpu_put() calls

2023-12-13T17:45:25+00:00

commit bdefd9913bdd453991ef756b6f7176e8ad80d786 upstream.

The policy returned by cpufreq_cpu_get() has to be released with
the help of cpufreq_cpu_put() to balance its kobject reference counter
properly.

Add the missing calls to cpufreq_cpu_put() in the code.

Fixes: 0aea2e4ec2a2 ("powercap/dtpm_cpu: Reset per_cpu variable in the release function")
Fixes: 0e8f68d7f048 ("powercap/drivers/dtpm: Add CPU energy model based support")
Cc: v5.16+  # v5.16+
Signed-off-by: Lukasz Luba 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

powercap: DTPM: Fix unneeded conversions to micro-Watts

2023-12-08T07:52:18+00:00

commit b817f1488fca548fe50e2654d84a1956a16a1a8a upstream.

The power values coming from the Energy Model are already in uW.

The PowerCap and DTPM frameworks operate on uW, so all places should
just use the values from the EM.

Fix the code by removing all of the conversion to uW still present in it.

Fixes: ae6ccaa65038 (PM: EM: convert power field to micro-Watts precision and align drivers)
Cc: 5.19+  # v5.19+
Signed-off-by: Lukasz Luba 
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

powercap: intel_rapl: Downgrade BIOS locked limits pr_warn() to pr_debug()

2023-11-28T17:20:00+00:00

commit a60ec4485f1c72dfece365cf95e6de82bdd74300 upstream.

Before the refactoring the pr_warn() only triggered when
someone explicitly tried to write to a BIOS locked limit.
After the refactoring the warning is also triggering during
system resume. The user can't do anything about this so
printing scary warnings doesn't make sense

Keep the printk but make it pr_debug() instead of pr_warn()
to make it clear it's not a serious issue.

Fixes: 9050a9cd5e4c ("powercap: intel_rapl: Cleanup Power Limits support")
Signed-off-by: Ville Syrjälä 
Cc: 6.5+  # 6.5+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

powercap: intel_rapl: Fix invalid setting of Power Limit 4

2023-09-06T20:21:22+00:00

System runs at minimum performance, once powercap RAPL package domain
enabled flag is changed from 1 to 0 to 1.

Setting RAPL package domain enabled flag to 0, results in setting of
power limit 4 (PL4) MSR 0x601 to 0. This implies disabling PL4 limit.
The PL4 limit controls the peak power. So setting 0, results in some
undesirable performance, which depends on hardware implementation.

Even worse, when the enabled flag is set to 1 again. This will set PL4
MSR value to 0x01, which means reduce peak power to 0.125W. This will
force system to run at the lowest possible performance on every PL4
supported system.

Setting enabled flag should only affect the "enable" bit, not other
bits. Here it is changing power limit.

This is caused by a change which assumes that there is an enable bit in
the PL4 MSR like other power limits. Although PL4 enable/disable bit is
present with TPMI RAPL interface, it is not present with the MSR
interface.

There is a rapl_primitive_info defined for non existent PL4 enable bit
and then it is used with the commit 9050a9cd5e4c ("powercap: intel_rapl:
Cleanup Power Limits support") to enable PL4. This is wrong, hence remove
this rapl primitive for PL4. Also in the function
rapl_detect_powerlimit(), PL_ENABLE is used to check for the presence of
power limits. Replace PL_ENABLE with PL_LIMIT, as PL_LIMIT must be
present. Without this change, PL4 controls will not be available in the
sysfs once rapl primitive for PL4 is removed.

Fixes: 9050a9cd5e4c ("powercap: intel_rapl: Cleanup Power Limits support")
Suggested-by: Zhang Rui 
Signed-off-by: Srinivas Pandruvada 
Tested-by: Sumeet Pawnikar 
Cc: 6.5+  # 6.5+
Signed-off-by: Rafael J. Wysocki