2019-05-29 23:57:24 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/*
|
2019-07-10 13:44:30 +00:00
|
|
|
* Common code for Intel Running Average Power Limit (RAPL) support.
|
|
|
|
* Copyright (c) 2019, Intel Corporation.
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
*/
|
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2024-04-08 03:51:39 +00:00
|
|
|
#include <linux/bitmap.h>
|
2024-01-31 11:37:09 +00:00
|
|
|
#include <linux/cleanup.h>
|
2024-04-08 03:51:39 +00:00
|
|
|
#include <linux/cpu.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/device.h>
|
|
|
|
#include <linux/intel_rapl.h>
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/log2.h>
|
2024-04-08 03:51:39 +00:00
|
|
|
#include <linux/module.h>
|
powercap: intel_rapl: Introduce APIs for PMU support
Introduce two new APIs rapl_package_add_pmu()/rapl_package_remove_pmu().
RAPL driver can invoke these APIs to expose its supported energy
counters via perf PMU. The new RAPL PMU is fully compatible with current
MSR RAPL PMU, including using the same PMU name and events
name/id/unit/scale, etc.
For example, use below command
perf stat -e power/energy-pkg/ -e power/energy-ram/ FOO
to get the energy consumption if power/energy-pkg/ and power/energy-ram/
events are available in the "perf list" output.
This does not introduce any conflict because TPMI RAPL is the only user
of these APIs currently, and it never co-exists with MSR RAPL.
Note that RAPL Packages can be probed/removed dynamically, and the
events supported by each TPMI RAPL device can be different. Thus the
RAPL PMU support is done on demand, which means
1. PMU is registered only if it is needed by a RAPL Package. PMU events
for unsupported counters are not exposed.
2. PMU is unregistered and registered when a new RAPL Package is probed
and supports new counters that are not supported by current PMU.
For example, on a dual-package system using TPMI RAPL, it is possible
that Package 1 behaves as TPMI domain root and supports Psys domain.
In this case, register PMU without Psys event when probing Package 0,
and re-register the PMU with Psys event when probing Package 1.
3. PMU is unregistered when all registered RAPL Packages don't need PMU.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-04-28 09:24:26 +00:00
|
|
|
#include <linux/nospec.h>
|
|
|
|
#include <linux/perf_event.h>
|
2024-04-08 03:51:39 +00:00
|
|
|
#include <linux/platform_device.h>
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
#include <linux/powercap.h>
|
2019-07-10 13:44:30 +00:00
|
|
|
#include <linux/processor.h>
|
2024-04-08 03:51:39 +00:00
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/suspend.h>
|
|
|
|
#include <linux/sysfs.h>
|
|
|
|
#include <linux/types.h>
|
2019-07-10 13:44:34 +00:00
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
#include <asm/cpu_device_id.h>
|
2016-06-03 00:19:36 +00:00
|
|
|
#include <asm/intel-family.h>
|
2024-04-08 03:51:39 +00:00
|
|
|
#include <asm/iosf_mbi.h>
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
/* bitmasks for RAPL MSRs, used by primitive access functions */
|
|
|
|
#define ENERGY_STATUS_MASK 0xffffffff
|
|
|
|
|
|
|
|
#define POWER_LIMIT1_MASK 0x7FFF
|
|
|
|
#define POWER_LIMIT1_ENABLE BIT(15)
|
|
|
|
#define POWER_LIMIT1_CLAMP BIT(16)
|
|
|
|
|
|
|
|
#define POWER_LIMIT2_MASK (0x7FFFULL<<32)
|
|
|
|
#define POWER_LIMIT2_ENABLE BIT_ULL(47)
|
|
|
|
#define POWER_LIMIT2_CLAMP BIT_ULL(48)
|
2019-07-10 13:44:32 +00:00
|
|
|
#define POWER_HIGH_LOCK BIT_ULL(63)
|
|
|
|
#define POWER_LOW_LOCK BIT(31)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2020-07-16 17:44:55 +00:00
|
|
|
#define POWER_LIMIT4_MASK 0x1FFF
|
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
#define TIME_WINDOW1_MASK (0x7FULL<<17)
|
|
|
|
#define TIME_WINDOW2_MASK (0x7FULL<<49)
|
|
|
|
|
|
|
|
#define POWER_UNIT_OFFSET 0
|
|
|
|
#define POWER_UNIT_MASK 0x0F
|
|
|
|
|
|
|
|
#define ENERGY_UNIT_OFFSET 0x08
|
|
|
|
#define ENERGY_UNIT_MASK 0x1F00
|
|
|
|
|
|
|
|
#define TIME_UNIT_OFFSET 0x10
|
|
|
|
#define TIME_UNIT_MASK 0xF0000
|
|
|
|
|
|
|
|
#define POWER_INFO_MAX_MASK (0x7fffULL<<32)
|
|
|
|
#define POWER_INFO_MIN_MASK (0x7fffULL<<16)
|
|
|
|
#define POWER_INFO_MAX_TIME_WIN_MASK (0x3fULL<<48)
|
|
|
|
#define POWER_INFO_THERMAL_SPEC_MASK 0x7fff
|
|
|
|
|
|
|
|
#define PERF_STATUS_THROTTLE_TIME_MASK 0xffffffff
|
|
|
|
#define PP_POLICY_MASK 0x1F
|
|
|
|
|
2021-12-07 13:17:34 +00:00
|
|
|
/*
|
|
|
|
* SPR has different layout for Psys Domain PowerLimit registers.
|
|
|
|
* There are 17 bits of PL1 and PL2 instead of 15 bits.
|
|
|
|
* The Enable bits and TimeWindow bits are also shifted as a result.
|
|
|
|
*/
|
|
|
|
#define PSYS_POWER_LIMIT1_MASK 0x1FFFF
|
|
|
|
#define PSYS_POWER_LIMIT1_ENABLE BIT(17)
|
|
|
|
|
|
|
|
#define PSYS_POWER_LIMIT2_MASK (0x1FFFFULL<<32)
|
|
|
|
#define PSYS_POWER_LIMIT2_ENABLE BIT_ULL(49)
|
|
|
|
|
|
|
|
#define PSYS_TIME_WINDOW1_MASK (0x7FULL<<19)
|
|
|
|
#define PSYS_TIME_WINDOW2_MASK (0x7FULL<<51)
|
|
|
|
|
2023-04-19 02:44:18 +00:00
|
|
|
/* bitmasks for RAPL TPMI, used by primitive access functions */
|
|
|
|
#define TPMI_POWER_LIMIT_MASK 0x3FFFF
|
|
|
|
#define TPMI_POWER_LIMIT_ENABLE BIT_ULL(62)
|
|
|
|
#define TPMI_TIME_WINDOW_MASK (0x7FULL<<18)
|
|
|
|
#define TPMI_INFO_SPEC_MASK 0x3FFFF
|
|
|
|
#define TPMI_INFO_MIN_MASK (0x3FFFFULL << 18)
|
|
|
|
#define TPMI_INFO_MAX_MASK (0x3FFFFULL << 36)
|
|
|
|
#define TPMI_INFO_MAX_TIME_WIN_MASK (0x7FULL << 54)
|
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* Non HW constants */
|
2019-07-10 13:44:30 +00:00
|
|
|
#define RAPL_PRIMITIVE_DERIVED BIT(1) /* not from raw data */
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
#define RAPL_PRIMITIVE_DUMMY BIT(2)
|
|
|
|
|
|
|
|
#define TIME_WINDOW_MAX_MSEC 40000
|
|
|
|
#define TIME_WINDOW_MIN_MSEC 250
|
2019-07-10 13:44:30 +00:00
|
|
|
#define ENERGY_UNIT_SCALE 1000 /* scale from driver unit to powercap unit */
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
enum unit_type {
|
2019-07-10 13:44:30 +00:00
|
|
|
ARBITRARY_UNIT, /* no translation */
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
POWER_UNIT,
|
|
|
|
ENERGY_UNIT,
|
|
|
|
TIME_UNIT,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* per domain data, some are optional */
|
|
|
|
#define NR_RAW_PRIMITIVES (NR_RAPL_PRIMITIVES - 2)
|
|
|
|
|
|
|
|
#define DOMAIN_STATE_INACTIVE BIT(0)
|
|
|
|
#define DOMAIN_STATE_POWER_LIMIT_SET BIT(1)
|
|
|
|
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
static const char *pl_names[NR_POWER_LIMITS] = {
|
|
|
|
[POWER_LIMIT1] = "long_term",
|
|
|
|
[POWER_LIMIT2] = "short_term",
|
|
|
|
[POWER_LIMIT4] = "peak_power",
|
|
|
|
};
|
|
|
|
|
|
|
|
enum pl_prims {
|
|
|
|
PL_ENABLE,
|
|
|
|
PL_CLAMP,
|
|
|
|
PL_LIMIT,
|
|
|
|
PL_TIME_WINDOW,
|
|
|
|
PL_MAX_POWER,
|
2023-04-19 02:44:14 +00:00
|
|
|
PL_LOCK,
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static bool is_pl_valid(struct rapl_domain *rd, int pl)
|
|
|
|
{
|
|
|
|
if (pl < POWER_LIMIT1 || pl > POWER_LIMIT4)
|
|
|
|
return false;
|
|
|
|
return rd->rpl[pl].name ? true : false;
|
|
|
|
}
|
|
|
|
|
2023-04-19 02:44:14 +00:00
|
|
|
static int get_pl_lock_prim(struct rapl_domain *rd, int pl)
|
|
|
|
{
|
2023-04-19 02:44:18 +00:00
|
|
|
if (rd->rp->priv->type == RAPL_IF_TPMI) {
|
|
|
|
if (pl == POWER_LIMIT1)
|
|
|
|
return PL1_LOCK;
|
|
|
|
if (pl == POWER_LIMIT2)
|
|
|
|
return PL2_LOCK;
|
|
|
|
if (pl == POWER_LIMIT4)
|
|
|
|
return PL4_LOCK;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* MSR/MMIO Interface doesn't have Lock bit for PL4 */
|
|
|
|
if (pl == POWER_LIMIT4)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2023-04-19 02:44:14 +00:00
|
|
|
/*
|
|
|
|
* Power Limit register that supports two power limits has a different
|
|
|
|
* bit position for the Lock bit.
|
|
|
|
*/
|
|
|
|
if (rd->rp->priv->limits[rd->id] & BIT(POWER_LIMIT2))
|
|
|
|
return FW_HIGH_LOCK;
|
|
|
|
return FW_LOCK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int get_pl_prim(struct rapl_domain *rd, int pl, enum pl_prims prim)
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
{
|
|
|
|
switch (pl) {
|
|
|
|
case POWER_LIMIT1:
|
|
|
|
if (prim == PL_ENABLE)
|
|
|
|
return PL1_ENABLE;
|
2023-04-19 02:44:18 +00:00
|
|
|
if (prim == PL_CLAMP && rd->rp->priv->type != RAPL_IF_TPMI)
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
return PL1_CLAMP;
|
|
|
|
if (prim == PL_LIMIT)
|
|
|
|
return POWER_LIMIT1;
|
|
|
|
if (prim == PL_TIME_WINDOW)
|
|
|
|
return TIME_WINDOW1;
|
|
|
|
if (prim == PL_MAX_POWER)
|
|
|
|
return THERMAL_SPEC_POWER;
|
2023-04-19 02:44:14 +00:00
|
|
|
if (prim == PL_LOCK)
|
|
|
|
return get_pl_lock_prim(rd, pl);
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
return -EINVAL;
|
|
|
|
case POWER_LIMIT2:
|
|
|
|
if (prim == PL_ENABLE)
|
|
|
|
return PL2_ENABLE;
|
2023-04-19 02:44:18 +00:00
|
|
|
if (prim == PL_CLAMP && rd->rp->priv->type != RAPL_IF_TPMI)
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
return PL2_CLAMP;
|
|
|
|
if (prim == PL_LIMIT)
|
|
|
|
return POWER_LIMIT2;
|
|
|
|
if (prim == PL_TIME_WINDOW)
|
|
|
|
return TIME_WINDOW2;
|
|
|
|
if (prim == PL_MAX_POWER)
|
|
|
|
return MAX_POWER;
|
2023-04-19 02:44:14 +00:00
|
|
|
if (prim == PL_LOCK)
|
|
|
|
return get_pl_lock_prim(rd, pl);
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
return -EINVAL;
|
|
|
|
case POWER_LIMIT4:
|
|
|
|
if (prim == PL_LIMIT)
|
|
|
|
return POWER_LIMIT4;
|
|
|
|
if (prim == PL_ENABLE)
|
|
|
|
return PL4_ENABLE;
|
|
|
|
/* PL4 would be around two times PL2, use same prim as PL2. */
|
|
|
|
if (prim == PL_MAX_POWER)
|
|
|
|
return MAX_POWER;
|
2023-04-19 02:44:18 +00:00
|
|
|
if (prim == PL_LOCK)
|
|
|
|
return get_pl_lock_prim(rd, pl);
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
return -EINVAL;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
#define power_zone_to_rapl_domain(_zone) \
|
|
|
|
container_of(_zone, struct rapl_domain, power_zone)
|
|
|
|
|
2014-11-07 17:29:25 +00:00
|
|
|
struct rapl_defaults {
|
2015-04-29 20:13:23 +00:00
|
|
|
u8 floor_freq_reg_addr;
|
2023-04-19 02:44:15 +00:00
|
|
|
int (*check_unit)(struct rapl_domain *rd);
|
2014-11-07 17:29:25 +00:00
|
|
|
void (*set_floor_freq)(struct rapl_domain *rd, bool mode);
|
2023-04-19 02:44:09 +00:00
|
|
|
u64 (*compute_time_window)(struct rapl_domain *rd, u64 val,
|
2019-07-10 13:44:30 +00:00
|
|
|
bool to_raw);
|
2015-03-13 10:48:56 +00:00
|
|
|
unsigned int dram_domain_energy_unit;
|
2020-06-29 05:34:50 +00:00
|
|
|
unsigned int psys_domain_energy_unit;
|
2021-12-07 13:17:34 +00:00
|
|
|
bool spr_psys_bits;
|
2014-11-07 17:29:25 +00:00
|
|
|
};
|
2023-04-19 02:44:17 +00:00
|
|
|
static struct rapl_defaults *defaults_msr;
|
2023-04-19 02:44:18 +00:00
|
|
|
static const struct rapl_defaults defaults_tpmi;
|
2014-11-07 17:29:25 +00:00
|
|
|
|
2023-04-19 02:44:07 +00:00
|
|
|
static struct rapl_defaults *get_defaults(struct rapl_package *rp)
|
|
|
|
{
|
|
|
|
return rp->priv->defaults;
|
|
|
|
}
|
|
|
|
|
2014-11-07 17:29:26 +00:00
|
|
|
/* Sideband MBI registers */
|
2015-04-29 20:13:23 +00:00
|
|
|
#define IOSF_CPU_POWER_BUDGET_CTL_BYT (0x2)
|
|
|
|
#define IOSF_CPU_POWER_BUDGET_CTL_TNG (0xdf)
|
2014-11-07 17:29:26 +00:00
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
#define PACKAGE_PLN_INT_SAVED BIT(0)
|
|
|
|
#define MAX_PRIM_NAME (32)
|
|
|
|
|
|
|
|
/* per domain data. used to describe individual knobs such that access function
|
|
|
|
* can be consolidated into one instead of many inline functions.
|
|
|
|
*/
|
|
|
|
struct rapl_primitive_info {
|
|
|
|
const char *name;
|
|
|
|
u64 mask;
|
|
|
|
int shift;
|
2019-07-10 13:44:22 +00:00
|
|
|
enum rapl_domain_reg_id id;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
enum unit_type unit;
|
|
|
|
u32 flag;
|
|
|
|
};
|
|
|
|
|
|
|
|
#define PRIMITIVE_INFO_INIT(p, m, s, i, u, f) { \
|
|
|
|
.name = #p, \
|
|
|
|
.mask = m, \
|
|
|
|
.shift = s, \
|
|
|
|
.id = i, \
|
|
|
|
.unit = u, \
|
|
|
|
.flag = f \
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rapl_init_domains(struct rapl_package *rp);
|
|
|
|
static int rapl_read_data_raw(struct rapl_domain *rd,
|
2019-07-10 13:44:30 +00:00
|
|
|
enum rapl_primitives prim,
|
|
|
|
bool xlate, u64 *data);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
static int rapl_write_data_raw(struct rapl_domain *rd,
|
2019-07-10 13:44:30 +00:00
|
|
|
enum rapl_primitives prim,
|
|
|
|
unsigned long long value);
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
static int rapl_read_pl_data(struct rapl_domain *rd, int pl,
|
|
|
|
enum pl_prims pl_prim,
|
|
|
|
bool xlate, u64 *data);
|
|
|
|
static int rapl_write_pl_data(struct rapl_domain *rd, int pl,
|
|
|
|
enum pl_prims pl_prim,
|
|
|
|
unsigned long long value);
|
2016-02-24 21:31:37 +00:00
|
|
|
static u64 rapl_unit_xlate(struct rapl_domain *rd,
|
2019-07-10 13:44:30 +00:00
|
|
|
enum unit_type type, u64 value, int to_raw);
|
2016-02-24 21:31:37 +00:00
|
|
|
static void package_power_limit_irq_save(struct rapl_package *rp);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2019-07-10 13:44:30 +00:00
|
|
|
static LIST_HEAD(rapl_packages); /* guarded by CPU hotplug lock */
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2019-07-10 13:44:30 +00:00
|
|
|
static const char *const rapl_domain_names[] = {
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
"package",
|
|
|
|
"core",
|
|
|
|
"uncore",
|
|
|
|
"dram",
|
2016-04-17 22:03:01 +00:00
|
|
|
"psys",
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
};
|
|
|
|
|
2019-07-10 13:44:30 +00:00
|
|
|
static int get_energy_counter(struct powercap_zone *power_zone,
|
|
|
|
u64 *energy_raw)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
|
|
|
struct rapl_domain *rd;
|
|
|
|
u64 energy_now;
|
|
|
|
|
|
|
|
/* prevent CPU hotplug, make sure the RAPL domain does not go
|
|
|
|
* away while reading the counter.
|
|
|
|
*/
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_lock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
rd = power_zone_to_rapl_domain(power_zone);
|
|
|
|
|
|
|
|
if (!rapl_read_data_raw(rd, ENERGY_COUNTER, true, &energy_now)) {
|
|
|
|
*energy_raw = energy_now;
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_unlock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_unlock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int get_max_energy_counter(struct powercap_zone *pcd_dev, u64 *energy)
|
|
|
|
{
|
2015-03-13 10:48:56 +00:00
|
|
|
struct rapl_domain *rd = power_zone_to_rapl_domain(pcd_dev);
|
|
|
|
|
2016-02-24 21:31:37 +00:00
|
|
|
*energy = rapl_unit_xlate(rd, ENERGY_UNIT, ENERGY_STATUS_MASK, 0);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int release_zone(struct powercap_zone *power_zone)
|
|
|
|
{
|
|
|
|
struct rapl_domain *rd = power_zone_to_rapl_domain(power_zone);
|
2016-02-24 21:31:37 +00:00
|
|
|
struct rapl_package *rp = rd->rp;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
/* package zone is the last zone of a package, we can free
|
|
|
|
* memory here since all children has been unregistered.
|
|
|
|
*/
|
|
|
|
if (rd->id == RAPL_DOMAIN_PACKAGE) {
|
|
|
|
kfree(rd);
|
|
|
|
rp->domains = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
static int find_nr_power_limit(struct rapl_domain *rd)
|
|
|
|
{
|
2016-05-31 20:41:29 +00:00
|
|
|
int i, nr_pl = 0;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
for (i = 0; i < NR_POWER_LIMITS; i++) {
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
if (is_pl_valid(rd, i))
|
2016-05-31 20:41:29 +00:00
|
|
|
nr_pl++;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
|
2016-05-31 20:41:29 +00:00
|
|
|
return nr_pl;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int set_domain_enable(struct powercap_zone *power_zone, bool mode)
|
|
|
|
{
|
|
|
|
struct rapl_domain *rd = power_zone_to_rapl_domain(power_zone);
|
2023-04-19 02:44:07 +00:00
|
|
|
struct rapl_defaults *defaults = get_defaults(rd->rp);
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
int ret;
|
2014-11-07 17:29:26 +00:00
|
|
|
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_lock();
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
ret = rapl_write_pl_data(rd, POWER_LIMIT1, PL_ENABLE, mode);
|
|
|
|
if (!ret && defaults->set_floor_freq)
|
2023-04-19 02:44:07 +00:00
|
|
|
defaults->set_floor_freq(rd, mode);
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_unlock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
return ret;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int get_domain_enable(struct powercap_zone *power_zone, bool *mode)
|
|
|
|
{
|
|
|
|
struct rapl_domain *rd = power_zone_to_rapl_domain(power_zone);
|
|
|
|
u64 val;
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
int ret;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2023-04-19 02:44:14 +00:00
|
|
|
if (rd->rpl[POWER_LIMIT1].locked) {
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
*mode = false;
|
|
|
|
return 0;
|
|
|
|
}
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_lock();
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
ret = rapl_read_pl_data(rd, POWER_LIMIT1, PL_ENABLE, true, &val);
|
|
|
|
if (!ret)
|
|
|
|
*mode = val;
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_unlock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
return ret;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* per RAPL domain ops, in the order of rapl_domain_type */
|
2015-12-23 21:59:55 +00:00
|
|
|
static const struct powercap_zone_ops zone_ops[] = {
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* RAPL_DOMAIN_PACKAGE */
|
|
|
|
{
|
2019-07-10 13:44:30 +00:00
|
|
|
.get_energy_uj = get_energy_counter,
|
|
|
|
.get_max_energy_range_uj = get_max_energy_counter,
|
|
|
|
.release = release_zone,
|
|
|
|
.set_enable = set_domain_enable,
|
|
|
|
.get_enable = get_domain_enable,
|
|
|
|
},
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* RAPL_DOMAIN_PP0 */
|
|
|
|
{
|
2019-07-10 13:44:30 +00:00
|
|
|
.get_energy_uj = get_energy_counter,
|
|
|
|
.get_max_energy_range_uj = get_max_energy_counter,
|
|
|
|
.release = release_zone,
|
|
|
|
.set_enable = set_domain_enable,
|
|
|
|
.get_enable = get_domain_enable,
|
|
|
|
},
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* RAPL_DOMAIN_PP1 */
|
|
|
|
{
|
2019-07-10 13:44:30 +00:00
|
|
|
.get_energy_uj = get_energy_counter,
|
|
|
|
.get_max_energy_range_uj = get_max_energy_counter,
|
|
|
|
.release = release_zone,
|
|
|
|
.set_enable = set_domain_enable,
|
|
|
|
.get_enable = get_domain_enable,
|
|
|
|
},
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* RAPL_DOMAIN_DRAM */
|
|
|
|
{
|
2019-07-10 13:44:30 +00:00
|
|
|
.get_energy_uj = get_energy_counter,
|
|
|
|
.get_max_energy_range_uj = get_max_energy_counter,
|
|
|
|
.release = release_zone,
|
|
|
|
.set_enable = set_domain_enable,
|
|
|
|
.get_enable = get_domain_enable,
|
|
|
|
},
|
2016-04-17 22:03:01 +00:00
|
|
|
/* RAPL_DOMAIN_PLATFORM */
|
|
|
|
{
|
2019-07-10 13:44:30 +00:00
|
|
|
.get_energy_uj = get_energy_counter,
|
|
|
|
.get_max_energy_range_uj = get_max_energy_counter,
|
|
|
|
.release = release_zone,
|
|
|
|
.set_enable = set_domain_enable,
|
|
|
|
.get_enable = get_domain_enable,
|
|
|
|
},
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
};
|
|
|
|
|
2016-05-31 20:41:29 +00:00
|
|
|
/*
|
|
|
|
* Constraint index used by powercap can be different than power limit (PL)
|
2019-07-10 13:44:30 +00:00
|
|
|
* index in that some PLs maybe missing due to non-existent MSRs. So we
|
2016-05-31 20:41:29 +00:00
|
|
|
* need to convert here by finding the valid PLs only (name populated).
|
|
|
|
*/
|
|
|
|
static int contraint_to_pl(struct rapl_domain *rd, int cid)
|
|
|
|
{
|
|
|
|
int i, j;
|
|
|
|
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
for (i = POWER_LIMIT1, j = 0; i < NR_POWER_LIMITS; i++) {
|
|
|
|
if (is_pl_valid(rd, i) && j++ == cid) {
|
2016-05-31 20:41:29 +00:00
|
|
|
pr_debug("%s: index %d\n", __func__, i);
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
}
|
2016-11-28 21:53:11 +00:00
|
|
|
pr_err("Cannot find matching power limit for constraint %d\n", cid);
|
2016-05-31 20:41:29 +00:00
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int set_power_limit(struct powercap_zone *power_zone, int cid,
|
2019-07-10 13:44:30 +00:00
|
|
|
u64 power_limit)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
|
|
|
struct rapl_domain *rd;
|
|
|
|
struct rapl_package *rp;
|
|
|
|
int ret = 0;
|
2016-05-31 20:41:29 +00:00
|
|
|
int id;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_lock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
rd = power_zone_to_rapl_domain(power_zone);
|
2016-05-31 20:41:29 +00:00
|
|
|
id = contraint_to_pl(rd, cid);
|
2016-02-24 21:31:37 +00:00
|
|
|
rp = rd->rp;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
ret = rapl_write_pl_data(rd, id, PL_LIMIT, power_limit);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
if (!ret)
|
2016-02-24 21:31:37 +00:00
|
|
|
package_power_limit_irq_save(rp);
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_unlock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-05-31 20:41:29 +00:00
|
|
|
static int get_current_power_limit(struct powercap_zone *power_zone, int cid,
|
2019-07-10 13:44:30 +00:00
|
|
|
u64 *data)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
|
|
|
struct rapl_domain *rd;
|
|
|
|
u64 val;
|
|
|
|
int ret = 0;
|
2016-05-31 20:41:29 +00:00
|
|
|
int id;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_lock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
rd = power_zone_to_rapl_domain(power_zone);
|
2016-05-31 20:41:29 +00:00
|
|
|
id = contraint_to_pl(rd, cid);
|
2016-11-28 21:53:11 +00:00
|
|
|
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
ret = rapl_read_pl_data(rd, id, PL_LIMIT, true, &val);
|
|
|
|
if (!ret)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
*data = val;
|
|
|
|
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_unlock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-05-31 20:41:29 +00:00
|
|
|
static int set_time_window(struct powercap_zone *power_zone, int cid,
|
2019-07-10 13:44:30 +00:00
|
|
|
u64 window)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
|
|
|
struct rapl_domain *rd;
|
|
|
|
int ret = 0;
|
2016-05-31 20:41:29 +00:00
|
|
|
int id;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_lock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
rd = power_zone_to_rapl_domain(power_zone);
|
2016-05-31 20:41:29 +00:00
|
|
|
id = contraint_to_pl(rd, cid);
|
|
|
|
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
ret = rapl_write_pl_data(rd, id, PL_TIME_WINDOW, window);
|
2016-11-28 21:53:11 +00:00
|
|
|
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_unlock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-07-10 13:44:30 +00:00
|
|
|
static int get_time_window(struct powercap_zone *power_zone, int cid,
|
|
|
|
u64 *data)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
|
|
|
struct rapl_domain *rd;
|
|
|
|
u64 val;
|
|
|
|
int ret = 0;
|
2016-05-31 20:41:29 +00:00
|
|
|
int id;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_lock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
rd = power_zone_to_rapl_domain(power_zone);
|
2016-05-31 20:41:29 +00:00
|
|
|
id = contraint_to_pl(rd, cid);
|
|
|
|
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
ret = rapl_read_pl_data(rd, id, PL_TIME_WINDOW, true, &val);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
if (!ret)
|
|
|
|
*data = val;
|
2016-11-28 21:53:11 +00:00
|
|
|
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_unlock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-07-10 13:44:30 +00:00
|
|
|
static const char *get_constraint_name(struct powercap_zone *power_zone,
|
|
|
|
int cid)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
|
|
|
struct rapl_domain *rd;
|
2016-05-31 20:41:29 +00:00
|
|
|
int id;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
rd = power_zone_to_rapl_domain(power_zone);
|
2016-05-31 20:41:29 +00:00
|
|
|
id = contraint_to_pl(rd, cid);
|
|
|
|
if (id >= 0)
|
|
|
|
return rd->rpl[id].name;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2016-05-31 20:41:29 +00:00
|
|
|
return NULL;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
static int get_max_power(struct powercap_zone *power_zone, int cid, u64 *data)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
|
|
|
struct rapl_domain *rd;
|
|
|
|
u64 val;
|
|
|
|
int ret = 0;
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
int id;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_lock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
rd = power_zone_to_rapl_domain(power_zone);
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
id = contraint_to_pl(rd, cid);
|
|
|
|
|
|
|
|
ret = rapl_read_pl_data(rd, id, PL_MAX_POWER, true, &val);
|
|
|
|
if (!ret)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
*data = val;
|
|
|
|
|
2020-07-16 17:44:55 +00:00
|
|
|
/* As a generalization rule, PL4 would be around two times PL2. */
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
if (id == POWER_LIMIT4)
|
2020-07-16 17:44:55 +00:00
|
|
|
*data = *data * 2;
|
|
|
|
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_unlock();
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2015-12-23 21:59:55 +00:00
|
|
|
static const struct powercap_zone_constraint_ops constraint_ops = {
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
.set_power_limit_uw = set_power_limit,
|
|
|
|
.get_power_limit_uw = get_current_power_limit,
|
|
|
|
.set_time_window_us = set_time_window,
|
|
|
|
.get_time_window_us = get_time_window,
|
|
|
|
.get_max_power_uw = get_max_power,
|
|
|
|
.get_name = get_constraint_name,
|
|
|
|
};
|
|
|
|
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
/* Return the id used for read_raw/write_raw callback */
|
|
|
|
static int get_rid(struct rapl_package *rp)
|
|
|
|
{
|
|
|
|
return rp->lead_cpu >= 0 ? rp->lead_cpu : rp->id;
|
|
|
|
}
|
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* called after domain detection and package level data are set */
|
|
|
|
static void rapl_init_domains(struct rapl_package *rp)
|
|
|
|
{
|
2019-07-10 13:44:32 +00:00
|
|
|
enum rapl_domain_type i;
|
|
|
|
enum rapl_domain_reg_id j;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
struct rapl_domain *rd = rp->domains;
|
|
|
|
|
|
|
|
for (i = 0; i < RAPL_DOMAIN_MAX; i++) {
|
|
|
|
unsigned int mask = rp->domain_map & (1 << i);
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
int t;
|
2019-07-10 13:44:26 +00:00
|
|
|
|
2019-07-10 13:44:32 +00:00
|
|
|
if (!mask)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
rd->rp = rp;
|
2020-10-13 07:42:41 +00:00
|
|
|
|
|
|
|
if (i == RAPL_DOMAIN_PLATFORM && rp->id > 0) {
|
|
|
|
snprintf(rd->name, RAPL_DOMAIN_NAME_LENGTH, "psys-%d",
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
rp->lead_cpu >= 0 ? topology_physical_package_id(rp->lead_cpu) :
|
|
|
|
rp->id);
|
|
|
|
} else {
|
2020-10-13 07:42:41 +00:00
|
|
|
snprintf(rd->name, RAPL_DOMAIN_NAME_LENGTH, "%s",
|
|
|
|
rapl_domain_names[i]);
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
}
|
2020-10-13 07:42:41 +00:00
|
|
|
|
2019-07-10 13:44:32 +00:00
|
|
|
rd->id = i;
|
2023-04-19 02:44:12 +00:00
|
|
|
|
|
|
|
/* PL1 is supported by default */
|
|
|
|
rp->priv->limits[i] |= BIT(POWER_LIMIT1);
|
2020-07-16 17:44:55 +00:00
|
|
|
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
for (t = POWER_LIMIT1; t < NR_POWER_LIMITS; t++) {
|
|
|
|
if (rp->priv->limits[i] & BIT(t))
|
|
|
|
rd->rpl[t].name = pl_names[t];
|
2020-07-16 17:44:55 +00:00
|
|
|
}
|
|
|
|
|
2019-07-10 13:44:32 +00:00
|
|
|
for (j = 0; j < RAPL_DOMAIN_REG_MAX; j++)
|
|
|
|
rd->regs[j] = rp->priv->regs[i][j];
|
|
|
|
|
|
|
|
rd++;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-02-24 21:31:37 +00:00
|
|
|
static u64 rapl_unit_xlate(struct rapl_domain *rd, enum unit_type type,
|
2019-07-10 13:44:30 +00:00
|
|
|
u64 value, int to_raw)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
2014-11-07 17:29:26 +00:00
|
|
|
u64 units = 1;
|
2023-04-19 02:44:09 +00:00
|
|
|
struct rapl_defaults *defaults = get_defaults(rd->rp);
|
2015-03-13 10:48:56 +00:00
|
|
|
u64 scale = 1;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
switch (type) {
|
|
|
|
case POWER_UNIT:
|
2023-04-19 02:44:09 +00:00
|
|
|
units = rd->power_unit;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
break;
|
|
|
|
case ENERGY_UNIT:
|
2015-03-13 10:48:56 +00:00
|
|
|
scale = ENERGY_UNIT_SCALE;
|
2023-04-19 02:44:09 +00:00
|
|
|
units = rd->energy_unit;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
break;
|
|
|
|
case TIME_UNIT:
|
2023-04-19 02:44:09 +00:00
|
|
|
return defaults->compute_time_window(rd, value, to_raw);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
case ARBITRARY_UNIT:
|
|
|
|
default:
|
|
|
|
return value;
|
2020-11-01 14:11:29 +00:00
|
|
|
}
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
if (to_raw)
|
2015-03-13 10:48:56 +00:00
|
|
|
return div64_u64(value, units) * scale;
|
2014-11-07 17:29:26 +00:00
|
|
|
|
|
|
|
value *= units;
|
|
|
|
|
2015-03-13 10:48:56 +00:00
|
|
|
return div64_u64(value, scale);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
|
2023-04-19 02:44:18 +00:00
|
|
|
/* RAPL primitives for MSR and MMIO I/F */
|
2023-04-19 02:44:17 +00:00
|
|
|
static struct rapl_primitive_info rpi_msr[NR_RAPL_PRIMITIVES] = {
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* name, mask, shift, msr index, unit divisor */
|
2023-04-19 02:44:10 +00:00
|
|
|
[POWER_LIMIT1] = PRIMITIVE_INFO_INIT(POWER_LIMIT1, POWER_LIMIT1_MASK, 0,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, POWER_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[POWER_LIMIT2] = PRIMITIVE_INFO_INIT(POWER_LIMIT2, POWER_LIMIT2_MASK, 32,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, POWER_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[POWER_LIMIT4] = PRIMITIVE_INFO_INIT(POWER_LIMIT4, POWER_LIMIT4_MASK, 0,
|
2020-07-16 17:44:55 +00:00
|
|
|
RAPL_DOMAIN_REG_PL4, POWER_UNIT, 0),
|
2023-04-19 02:44:11 +00:00
|
|
|
[ENERGY_COUNTER] = PRIMITIVE_INFO_INIT(ENERGY_COUNTER, ENERGY_STATUS_MASK, 0,
|
|
|
|
RAPL_DOMAIN_REG_STATUS, ENERGY_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[FW_LOCK] = PRIMITIVE_INFO_INIT(FW_LOCK, POWER_LOW_LOCK, 31,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, ARBITRARY_UNIT, 0),
|
2023-04-19 02:44:14 +00:00
|
|
|
[FW_HIGH_LOCK] = PRIMITIVE_INFO_INIT(FW_LOCK, POWER_HIGH_LOCK, 63,
|
|
|
|
RAPL_DOMAIN_REG_LIMIT, ARBITRARY_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[PL1_ENABLE] = PRIMITIVE_INFO_INIT(PL1_ENABLE, POWER_LIMIT1_ENABLE, 15,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, ARBITRARY_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[PL1_CLAMP] = PRIMITIVE_INFO_INIT(PL1_CLAMP, POWER_LIMIT1_CLAMP, 16,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, ARBITRARY_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[PL2_ENABLE] = PRIMITIVE_INFO_INIT(PL2_ENABLE, POWER_LIMIT2_ENABLE, 47,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, ARBITRARY_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[PL2_CLAMP] = PRIMITIVE_INFO_INIT(PL2_CLAMP, POWER_LIMIT2_CLAMP, 48,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, ARBITRARY_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[TIME_WINDOW1] = PRIMITIVE_INFO_INIT(TIME_WINDOW1, TIME_WINDOW1_MASK, 17,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, TIME_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[TIME_WINDOW2] = PRIMITIVE_INFO_INIT(TIME_WINDOW2, TIME_WINDOW2_MASK, 49,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, TIME_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[THERMAL_SPEC_POWER] = PRIMITIVE_INFO_INIT(THERMAL_SPEC_POWER, POWER_INFO_THERMAL_SPEC_MASK,
|
2019-07-10 13:44:30 +00:00
|
|
|
0, RAPL_DOMAIN_REG_INFO, POWER_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[MAX_POWER] = PRIMITIVE_INFO_INIT(MAX_POWER, POWER_INFO_MAX_MASK, 32,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_DOMAIN_REG_INFO, POWER_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[MIN_POWER] = PRIMITIVE_INFO_INIT(MIN_POWER, POWER_INFO_MIN_MASK, 16,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_DOMAIN_REG_INFO, POWER_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[MAX_TIME_WINDOW] = PRIMITIVE_INFO_INIT(MAX_TIME_WINDOW, POWER_INFO_MAX_TIME_WIN_MASK, 48,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_DOMAIN_REG_INFO, TIME_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[THROTTLED_TIME] = PRIMITIVE_INFO_INIT(THROTTLED_TIME, PERF_STATUS_THROTTLE_TIME_MASK, 0,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_DOMAIN_REG_PERF, TIME_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[PRIORITY_LEVEL] = PRIMITIVE_INFO_INIT(PRIORITY_LEVEL, PP_POLICY_MASK, 0,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_DOMAIN_REG_POLICY, ARBITRARY_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[PSYS_POWER_LIMIT1] = PRIMITIVE_INFO_INIT(PSYS_POWER_LIMIT1, PSYS_POWER_LIMIT1_MASK, 0,
|
2021-12-07 13:17:34 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, POWER_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[PSYS_POWER_LIMIT2] = PRIMITIVE_INFO_INIT(PSYS_POWER_LIMIT2, PSYS_POWER_LIMIT2_MASK, 32,
|
2021-12-07 13:17:34 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, POWER_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[PSYS_PL1_ENABLE] = PRIMITIVE_INFO_INIT(PSYS_PL1_ENABLE, PSYS_POWER_LIMIT1_ENABLE, 17,
|
2021-12-07 13:17:34 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, ARBITRARY_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[PSYS_PL2_ENABLE] = PRIMITIVE_INFO_INIT(PSYS_PL2_ENABLE, PSYS_POWER_LIMIT2_ENABLE, 49,
|
2021-12-07 13:17:34 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, ARBITRARY_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[PSYS_TIME_WINDOW1] = PRIMITIVE_INFO_INIT(PSYS_TIME_WINDOW1, PSYS_TIME_WINDOW1_MASK, 19,
|
2021-12-07 13:17:34 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, TIME_UNIT, 0),
|
2023-04-19 02:44:10 +00:00
|
|
|
[PSYS_TIME_WINDOW2] = PRIMITIVE_INFO_INIT(PSYS_TIME_WINDOW2, PSYS_TIME_WINDOW2_MASK, 51,
|
2021-12-07 13:17:34 +00:00
|
|
|
RAPL_DOMAIN_REG_LIMIT, TIME_UNIT, 0),
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* non-hardware */
|
2023-04-19 02:44:10 +00:00
|
|
|
[AVERAGE_POWER] = PRIMITIVE_INFO_INIT(AVERAGE_POWER, 0, 0, 0, POWER_UNIT,
|
2019-07-10 13:44:30 +00:00
|
|
|
RAPL_PRIMITIVE_DERIVED),
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
};
|
|
|
|
|
2023-04-19 02:44:18 +00:00
|
|
|
/* RAPL primitives for TPMI I/F */
|
|
|
|
static struct rapl_primitive_info rpi_tpmi[NR_RAPL_PRIMITIVES] = {
|
|
|
|
/* name, mask, shift, msr index, unit divisor */
|
|
|
|
[POWER_LIMIT1] = PRIMITIVE_INFO_INIT(POWER_LIMIT1, TPMI_POWER_LIMIT_MASK, 0,
|
|
|
|
RAPL_DOMAIN_REG_LIMIT, POWER_UNIT, 0),
|
|
|
|
[POWER_LIMIT2] = PRIMITIVE_INFO_INIT(POWER_LIMIT2, TPMI_POWER_LIMIT_MASK, 0,
|
|
|
|
RAPL_DOMAIN_REG_PL2, POWER_UNIT, 0),
|
|
|
|
[POWER_LIMIT4] = PRIMITIVE_INFO_INIT(POWER_LIMIT4, TPMI_POWER_LIMIT_MASK, 0,
|
|
|
|
RAPL_DOMAIN_REG_PL4, POWER_UNIT, 0),
|
|
|
|
[ENERGY_COUNTER] = PRIMITIVE_INFO_INIT(ENERGY_COUNTER, ENERGY_STATUS_MASK, 0,
|
|
|
|
RAPL_DOMAIN_REG_STATUS, ENERGY_UNIT, 0),
|
|
|
|
[PL1_LOCK] = PRIMITIVE_INFO_INIT(PL1_LOCK, POWER_HIGH_LOCK, 63,
|
|
|
|
RAPL_DOMAIN_REG_LIMIT, ARBITRARY_UNIT, 0),
|
|
|
|
[PL2_LOCK] = PRIMITIVE_INFO_INIT(PL2_LOCK, POWER_HIGH_LOCK, 63,
|
|
|
|
RAPL_DOMAIN_REG_PL2, ARBITRARY_UNIT, 0),
|
|
|
|
[PL4_LOCK] = PRIMITIVE_INFO_INIT(PL4_LOCK, POWER_HIGH_LOCK, 63,
|
|
|
|
RAPL_DOMAIN_REG_PL4, ARBITRARY_UNIT, 0),
|
|
|
|
[PL1_ENABLE] = PRIMITIVE_INFO_INIT(PL1_ENABLE, TPMI_POWER_LIMIT_ENABLE, 62,
|
|
|
|
RAPL_DOMAIN_REG_LIMIT, ARBITRARY_UNIT, 0),
|
|
|
|
[PL2_ENABLE] = PRIMITIVE_INFO_INIT(PL2_ENABLE, TPMI_POWER_LIMIT_ENABLE, 62,
|
|
|
|
RAPL_DOMAIN_REG_PL2, ARBITRARY_UNIT, 0),
|
|
|
|
[PL4_ENABLE] = PRIMITIVE_INFO_INIT(PL4_ENABLE, TPMI_POWER_LIMIT_ENABLE, 62,
|
|
|
|
RAPL_DOMAIN_REG_PL4, ARBITRARY_UNIT, 0),
|
|
|
|
[TIME_WINDOW1] = PRIMITIVE_INFO_INIT(TIME_WINDOW1, TPMI_TIME_WINDOW_MASK, 18,
|
|
|
|
RAPL_DOMAIN_REG_LIMIT, TIME_UNIT, 0),
|
|
|
|
[TIME_WINDOW2] = PRIMITIVE_INFO_INIT(TIME_WINDOW2, TPMI_TIME_WINDOW_MASK, 18,
|
|
|
|
RAPL_DOMAIN_REG_PL2, TIME_UNIT, 0),
|
|
|
|
[THERMAL_SPEC_POWER] = PRIMITIVE_INFO_INIT(THERMAL_SPEC_POWER, TPMI_INFO_SPEC_MASK, 0,
|
|
|
|
RAPL_DOMAIN_REG_INFO, POWER_UNIT, 0),
|
|
|
|
[MAX_POWER] = PRIMITIVE_INFO_INIT(MAX_POWER, TPMI_INFO_MAX_MASK, 36,
|
|
|
|
RAPL_DOMAIN_REG_INFO, POWER_UNIT, 0),
|
|
|
|
[MIN_POWER] = PRIMITIVE_INFO_INIT(MIN_POWER, TPMI_INFO_MIN_MASK, 18,
|
|
|
|
RAPL_DOMAIN_REG_INFO, POWER_UNIT, 0),
|
|
|
|
[MAX_TIME_WINDOW] = PRIMITIVE_INFO_INIT(MAX_TIME_WINDOW, TPMI_INFO_MAX_TIME_WIN_MASK, 54,
|
|
|
|
RAPL_DOMAIN_REG_INFO, TIME_UNIT, 0),
|
|
|
|
[THROTTLED_TIME] = PRIMITIVE_INFO_INIT(THROTTLED_TIME, PERF_STATUS_THROTTLE_TIME_MASK, 0,
|
|
|
|
RAPL_DOMAIN_REG_PERF, TIME_UNIT, 0),
|
|
|
|
/* non-hardware */
|
|
|
|
[AVERAGE_POWER] = PRIMITIVE_INFO_INIT(AVERAGE_POWER, 0, 0, 0,
|
|
|
|
POWER_UNIT, RAPL_PRIMITIVE_DERIVED),
|
|
|
|
};
|
|
|
|
|
2023-04-19 02:44:08 +00:00
|
|
|
static struct rapl_primitive_info *get_rpi(struct rapl_package *rp, int prim)
|
|
|
|
{
|
|
|
|
struct rapl_primitive_info *rpi = rp->priv->rpi;
|
|
|
|
|
2024-08-20 08:41:34 +00:00
|
|
|
if (prim < 0 || prim >= NR_RAPL_PRIMITIVES || !rpi)
|
2023-04-19 02:44:08 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return &rpi[prim];
|
|
|
|
}
|
|
|
|
|
2023-04-19 02:44:07 +00:00
|
|
|
static int rapl_config(struct rapl_package *rp)
|
|
|
|
{
|
2023-04-19 02:44:17 +00:00
|
|
|
switch (rp->priv->type) {
|
|
|
|
/* MMIO I/F shares the same register layout as MSR registers */
|
|
|
|
case RAPL_IF_MMIO:
|
|
|
|
case RAPL_IF_MSR:
|
|
|
|
rp->priv->defaults = (void *)defaults_msr;
|
|
|
|
rp->priv->rpi = (void *)rpi_msr;
|
|
|
|
break;
|
2023-04-19 02:44:18 +00:00
|
|
|
case RAPL_IF_TPMI:
|
|
|
|
rp->priv->defaults = (void *)&defaults_tpmi;
|
|
|
|
rp->priv->rpi = (void *)rpi_tpmi;
|
|
|
|
break;
|
2023-04-19 02:44:17 +00:00
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2024-01-31 11:37:08 +00:00
|
|
|
|
|
|
|
/* defaults_msr can be NULL on unsupported platforms */
|
|
|
|
if (!rp->priv->defaults || !rp->priv->rpi)
|
|
|
|
return -ENODEV;
|
|
|
|
|
2023-04-19 02:44:07 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-12-07 13:17:34 +00:00
|
|
|
static enum rapl_primitives
|
|
|
|
prim_fixups(struct rapl_domain *rd, enum rapl_primitives prim)
|
|
|
|
{
|
2023-04-19 02:44:07 +00:00
|
|
|
struct rapl_defaults *defaults = get_defaults(rd->rp);
|
|
|
|
|
|
|
|
if (!defaults->spr_psys_bits)
|
2021-12-07 13:17:34 +00:00
|
|
|
return prim;
|
|
|
|
|
|
|
|
if (rd->id != RAPL_DOMAIN_PLATFORM)
|
|
|
|
return prim;
|
|
|
|
|
|
|
|
switch (prim) {
|
|
|
|
case POWER_LIMIT1:
|
|
|
|
return PSYS_POWER_LIMIT1;
|
|
|
|
case POWER_LIMIT2:
|
|
|
|
return PSYS_POWER_LIMIT2;
|
|
|
|
case PL1_ENABLE:
|
|
|
|
return PSYS_PL1_ENABLE;
|
|
|
|
case PL2_ENABLE:
|
|
|
|
return PSYS_PL2_ENABLE;
|
|
|
|
case TIME_WINDOW1:
|
|
|
|
return PSYS_TIME_WINDOW1;
|
|
|
|
case TIME_WINDOW2:
|
|
|
|
return PSYS_TIME_WINDOW2;
|
|
|
|
default:
|
|
|
|
return prim;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* Read primitive data based on its related struct rapl_primitive_info.
|
|
|
|
* if xlate flag is set, return translated data based on data units, i.e.
|
|
|
|
* time, energy, and power.
|
|
|
|
* RAPL MSRs are non-architectual and are laid out not consistently across
|
|
|
|
* domains. Here we use primitive info to allow writing consolidated access
|
|
|
|
* functions.
|
|
|
|
* For a given primitive, it is processed by MSR mask and shift. Unit conversion
|
|
|
|
* is pre-assigned based on RAPL unit MSRs read at init time.
|
|
|
|
* 63-------------------------- 31--------------------------- 0
|
|
|
|
* | xxxxx (mask) |
|
|
|
|
* | |<- shift ----------------|
|
|
|
|
* 63-------------------------- 31--------------------------- 0
|
|
|
|
*/
|
|
|
|
static int rapl_read_data_raw(struct rapl_domain *rd,
|
2019-07-10 13:44:30 +00:00
|
|
|
enum rapl_primitives prim, bool xlate, u64 *data)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
2019-07-10 13:44:27 +00:00
|
|
|
u64 value;
|
2021-12-07 13:17:34 +00:00
|
|
|
enum rapl_primitives prim_fixed = prim_fixups(rd, prim);
|
2023-04-19 02:44:08 +00:00
|
|
|
struct rapl_primitive_info *rpi = get_rpi(rd->rp, prim_fixed);
|
2019-07-10 13:44:27 +00:00
|
|
|
struct reg_action ra;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2023-04-19 02:44:08 +00:00
|
|
|
if (!rpi || !rpi->name || rpi->flag & RAPL_PRIMITIVE_DUMMY)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2023-04-19 02:44:08 +00:00
|
|
|
ra.reg = rd->regs[rpi->id];
|
2023-07-25 05:39:12 +00:00
|
|
|
if (!ra.reg.val)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
return -EINVAL;
|
2016-02-24 21:31:38 +00:00
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* non-hardware data are collected by the polling thread */
|
2023-04-19 02:44:08 +00:00
|
|
|
if (rpi->flag & RAPL_PRIMITIVE_DERIVED) {
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
*data = rd->rdd.primitives[prim];
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-04-19 02:44:08 +00:00
|
|
|
ra.mask = rpi->mask;
|
2019-07-10 13:44:27 +00:00
|
|
|
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
if (rd->rp->priv->read_raw(get_rid(rd->rp), &ra)) {
|
2023-07-25 05:39:12 +00:00
|
|
|
pr_debug("failed to read reg 0x%llx for %s:%s\n", ra.reg.val, rd->rp->name, rd->name);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
2023-04-19 02:44:08 +00:00
|
|
|
value = ra.value >> rpi->shift;
|
2019-07-10 13:44:27 +00:00
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
if (xlate)
|
2023-04-19 02:44:08 +00:00
|
|
|
*data = rapl_unit_xlate(rd, rpi->unit, value, 0);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
else
|
2019-07-10 13:44:27 +00:00
|
|
|
*data = value;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Similar use of primitive info in the read counterpart */
|
|
|
|
static int rapl_write_data_raw(struct rapl_domain *rd,
|
2019-07-10 13:44:30 +00:00
|
|
|
enum rapl_primitives prim,
|
|
|
|
unsigned long long value)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
2021-12-07 13:17:34 +00:00
|
|
|
enum rapl_primitives prim_fixed = prim_fixups(rd, prim);
|
2023-04-19 02:44:08 +00:00
|
|
|
struct rapl_primitive_info *rpi = get_rpi(rd->rp, prim_fixed);
|
2016-02-24 21:31:36 +00:00
|
|
|
u64 bits;
|
2019-07-10 13:44:27 +00:00
|
|
|
struct reg_action ra;
|
2016-02-24 21:31:36 +00:00
|
|
|
int ret;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2023-04-19 02:44:08 +00:00
|
|
|
if (!rpi || !rpi->name || rpi->flag & RAPL_PRIMITIVE_DUMMY)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
bits = rapl_unit_xlate(rd, rpi->unit, value, 1);
|
|
|
|
bits <<= rpi->shift;
|
|
|
|
bits &= rpi->mask;
|
2017-06-01 09:21:50 +00:00
|
|
|
|
2019-07-10 13:44:27 +00:00
|
|
|
memset(&ra, 0, sizeof(ra));
|
2016-02-24 21:31:36 +00:00
|
|
|
|
2023-04-19 02:44:08 +00:00
|
|
|
ra.reg = rd->regs[rpi->id];
|
|
|
|
ra.mask = rpi->mask;
|
2019-07-10 13:44:27 +00:00
|
|
|
ra.value = bits;
|
2016-02-24 21:31:36 +00:00
|
|
|
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
ret = rd->rp->priv->write_raw(get_rid(rd->rp), &ra);
|
2016-02-24 21:31:36 +00:00
|
|
|
|
|
|
|
return ret;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
static int rapl_read_pl_data(struct rapl_domain *rd, int pl,
|
|
|
|
enum pl_prims pl_prim, bool xlate, u64 *data)
|
|
|
|
{
|
2023-04-19 02:44:14 +00:00
|
|
|
enum rapl_primitives prim = get_pl_prim(rd, pl, pl_prim);
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
|
|
|
|
if (!is_pl_valid(rd, pl))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return rapl_read_data_raw(rd, prim, xlate, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rapl_write_pl_data(struct rapl_domain *rd, int pl,
|
|
|
|
enum pl_prims pl_prim,
|
|
|
|
unsigned long long value)
|
|
|
|
{
|
2023-04-19 02:44:14 +00:00
|
|
|
enum rapl_primitives prim = get_pl_prim(rd, pl, pl_prim);
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
|
|
|
|
if (!is_pl_valid(rd, pl))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2023-04-19 02:44:14 +00:00
|
|
|
if (rd->rpl[pl].locked) {
|
2023-10-24 19:17:19 +00:00
|
|
|
pr_debug("%s:%s:%s locked by BIOS\n", rd->rp->name, rd->name, pl_names[pl]);
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
return -EACCES;
|
|
|
|
}
|
|
|
|
|
|
|
|
return rapl_write_data_raw(rd, prim, value);
|
|
|
|
}
|
2014-11-07 17:29:26 +00:00
|
|
|
/*
|
|
|
|
* Raw RAPL data stored in MSRs are in certain scales. We need to
|
|
|
|
* convert them into standard units based on the units reported in
|
|
|
|
* the RAPL unit MSRs. This is specific to CPUs as the method to
|
|
|
|
* calculate units differ on different CPUs.
|
|
|
|
* We convert the units to below format based on CPUs.
|
|
|
|
* i.e.
|
2015-03-13 10:48:56 +00:00
|
|
|
* energy unit: picoJoules : Represented in picoJoules by default
|
2014-11-07 17:29:26 +00:00
|
|
|
* power unit : microWatts : Represented in milliWatts by default
|
|
|
|
* time unit : microseconds: Represented in seconds by default
|
|
|
|
*/
|
2023-04-19 02:44:15 +00:00
|
|
|
static int rapl_check_unit_core(struct rapl_domain *rd)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
2019-07-10 13:44:29 +00:00
|
|
|
struct reg_action ra;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
u32 value;
|
|
|
|
|
2023-04-19 02:44:09 +00:00
|
|
|
ra.reg = rd->regs[RAPL_DOMAIN_REG_UNIT];
|
2019-07-10 13:44:29 +00:00
|
|
|
ra.mask = ~0;
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
if (rd->rp->priv->read_raw(get_rid(rd->rp), &ra)) {
|
|
|
|
pr_err("Failed to read power unit REG 0x%llx on %s:%s, exit.\n",
|
2023-07-25 05:39:12 +00:00
|
|
|
ra.reg.val, rd->rp->name, rd->name);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2019-07-10 13:44:29 +00:00
|
|
|
value = (ra.value & ENERGY_UNIT_MASK) >> ENERGY_UNIT_OFFSET;
|
2023-04-19 02:44:09 +00:00
|
|
|
rd->energy_unit = ENERGY_UNIT_SCALE * 1000000 / (1 << value);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2019-07-10 13:44:29 +00:00
|
|
|
value = (ra.value & POWER_UNIT_MASK) >> POWER_UNIT_OFFSET;
|
2023-04-19 02:44:09 +00:00
|
|
|
rd->power_unit = 1000000 / (1 << value);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2019-07-10 13:44:29 +00:00
|
|
|
value = (ra.value & TIME_UNIT_MASK) >> TIME_UNIT_OFFSET;
|
2023-04-19 02:44:09 +00:00
|
|
|
rd->time_unit = 1000000 / (1 << value);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2023-04-19 02:44:09 +00:00
|
|
|
pr_debug("Core CPU %s:%s energy=%dpJ, time=%dus, power=%duW\n",
|
|
|
|
rd->rp->name, rd->name, rd->energy_unit, rd->time_unit, rd->power_unit);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-04-19 02:44:15 +00:00
|
|
|
static int rapl_check_unit_atom(struct rapl_domain *rd)
|
2014-11-07 17:29:26 +00:00
|
|
|
{
|
2019-07-10 13:44:29 +00:00
|
|
|
struct reg_action ra;
|
2014-11-07 17:29:26 +00:00
|
|
|
u32 value;
|
|
|
|
|
2023-04-19 02:44:09 +00:00
|
|
|
ra.reg = rd->regs[RAPL_DOMAIN_REG_UNIT];
|
2019-07-10 13:44:29 +00:00
|
|
|
ra.mask = ~0;
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
if (rd->rp->priv->read_raw(get_rid(rd->rp), &ra)) {
|
|
|
|
pr_err("Failed to read power unit REG 0x%llx on %s:%s, exit.\n",
|
2023-07-25 05:39:12 +00:00
|
|
|
ra.reg.val, rd->rp->name, rd->name);
|
2014-11-07 17:29:26 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
2019-07-10 13:44:29 +00:00
|
|
|
|
|
|
|
value = (ra.value & ENERGY_UNIT_MASK) >> ENERGY_UNIT_OFFSET;
|
2023-04-19 02:44:09 +00:00
|
|
|
rd->energy_unit = ENERGY_UNIT_SCALE * 1 << value;
|
2014-11-07 17:29:26 +00:00
|
|
|
|
2019-07-10 13:44:29 +00:00
|
|
|
value = (ra.value & POWER_UNIT_MASK) >> POWER_UNIT_OFFSET;
|
2023-04-19 02:44:09 +00:00
|
|
|
rd->power_unit = (1 << value) * 1000;
|
2014-11-07 17:29:26 +00:00
|
|
|
|
2019-07-10 13:44:29 +00:00
|
|
|
value = (ra.value & TIME_UNIT_MASK) >> TIME_UNIT_OFFSET;
|
2023-04-19 02:44:09 +00:00
|
|
|
rd->time_unit = 1000000 / (1 << value);
|
2014-11-07 17:29:26 +00:00
|
|
|
|
2023-04-19 02:44:09 +00:00
|
|
|
pr_debug("Atom %s:%s energy=%dpJ, time=%dus, power=%duW\n",
|
|
|
|
rd->rp->name, rd->name, rd->energy_unit, rd->time_unit, rd->power_unit);
|
2014-11-07 17:29:26 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-02-24 21:31:36 +00:00
|
|
|
static void power_limit_irq_save_cpu(void *info)
|
|
|
|
{
|
|
|
|
u32 l, h = 0;
|
|
|
|
struct rapl_package *rp = (struct rapl_package *)info;
|
|
|
|
|
|
|
|
/* save the state of PLN irq mask bit before disabling it */
|
|
|
|
rdmsr_safe(MSR_IA32_PACKAGE_THERM_INTERRUPT, &l, &h);
|
|
|
|
if (!(rp->power_limit_irq & PACKAGE_PLN_INT_SAVED)) {
|
|
|
|
rp->power_limit_irq = l & PACKAGE_THERM_INT_PLN_ENABLE;
|
|
|
|
rp->power_limit_irq |= PACKAGE_PLN_INT_SAVED;
|
|
|
|
}
|
|
|
|
l &= ~PACKAGE_THERM_INT_PLN_ENABLE;
|
|
|
|
wrmsr_safe(MSR_IA32_PACKAGE_THERM_INTERRUPT, l, h);
|
|
|
|
}
|
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* REVISIT:
|
|
|
|
* When package power limit is set artificially low by RAPL, LVT
|
|
|
|
* thermal interrupt for package power limit should be ignored
|
|
|
|
* since we are not really exceeding the real limit. The intention
|
|
|
|
* is to avoid excessive interrupts while we are trying to save power.
|
|
|
|
* A useful feature might be routing the package_power_limit interrupt
|
|
|
|
* to userspace via eventfd. once we have a usecase, this is simple
|
|
|
|
* to do by adding an atomic notifier.
|
|
|
|
*/
|
|
|
|
|
2016-02-24 21:31:37 +00:00
|
|
|
static void package_power_limit_irq_save(struct rapl_package *rp)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
if (rp->lead_cpu < 0)
|
|
|
|
return;
|
|
|
|
|
2016-02-24 21:31:36 +00:00
|
|
|
if (!boot_cpu_has(X86_FEATURE_PTS) || !boot_cpu_has(X86_FEATURE_PLN))
|
|
|
|
return;
|
|
|
|
|
2016-02-24 21:31:38 +00:00
|
|
|
smp_call_function_single(rp->lead_cpu, power_limit_irq_save_cpu, rp, 1);
|
2016-02-24 21:31:36 +00:00
|
|
|
}
|
|
|
|
|
2016-11-22 21:16:02 +00:00
|
|
|
/*
|
|
|
|
* Restore per package power limit interrupt enable state. Called from cpu
|
|
|
|
* hotplug code on package removal.
|
|
|
|
*/
|
|
|
|
static void package_power_limit_irq_restore(struct rapl_package *rp)
|
2016-02-24 21:31:36 +00:00
|
|
|
{
|
2016-11-22 21:16:02 +00:00
|
|
|
u32 l, h;
|
|
|
|
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
if (rp->lead_cpu < 0)
|
|
|
|
return;
|
|
|
|
|
2016-11-22 21:16:02 +00:00
|
|
|
if (!boot_cpu_has(X86_FEATURE_PTS) || !boot_cpu_has(X86_FEATURE_PLN))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* irq enable state not saved, nothing to restore */
|
|
|
|
if (!(rp->power_limit_irq & PACKAGE_PLN_INT_SAVED))
|
|
|
|
return;
|
2016-02-24 21:31:36 +00:00
|
|
|
|
|
|
|
rdmsr_safe(MSR_IA32_PACKAGE_THERM_INTERRUPT, &l, &h);
|
|
|
|
|
|
|
|
if (rp->power_limit_irq & PACKAGE_THERM_INT_PLN_ENABLE)
|
|
|
|
l |= PACKAGE_THERM_INT_PLN_ENABLE;
|
|
|
|
else
|
|
|
|
l &= ~PACKAGE_THERM_INT_PLN_ENABLE;
|
|
|
|
|
|
|
|
wrmsr_safe(MSR_IA32_PACKAGE_THERM_INTERRUPT, l, h);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
|
2014-11-07 17:29:26 +00:00
|
|
|
static void set_floor_freq_default(struct rapl_domain *rd, bool mode)
|
|
|
|
{
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
int i;
|
2014-11-07 17:29:26 +00:00
|
|
|
|
|
|
|
/* always enable clamp such that p-state can go below OS requested
|
|
|
|
* range. power capping priority over guranteed frequency.
|
|
|
|
*/
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
rapl_write_pl_data(rd, POWER_LIMIT1, PL_CLAMP, mode);
|
2014-11-07 17:29:26 +00:00
|
|
|
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
for (i = POWER_LIMIT2; i < NR_POWER_LIMITS; i++) {
|
|
|
|
rapl_write_pl_data(rd, i, PL_ENABLE, mode);
|
|
|
|
rapl_write_pl_data(rd, i, PL_CLAMP, mode);
|
2014-11-07 17:29:26 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void set_floor_freq_atom(struct rapl_domain *rd, bool enable)
|
|
|
|
{
|
|
|
|
static u32 power_ctrl_orig_val;
|
2023-04-19 02:44:07 +00:00
|
|
|
struct rapl_defaults *defaults = get_defaults(rd->rp);
|
2014-11-07 17:29:26 +00:00
|
|
|
u32 mdata;
|
|
|
|
|
2023-04-19 02:44:07 +00:00
|
|
|
if (!defaults->floor_freq_reg_addr) {
|
2015-04-29 20:13:23 +00:00
|
|
|
pr_err("Invalid floor frequency config register\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-11-07 17:29:26 +00:00
|
|
|
if (!power_ctrl_orig_val)
|
2015-11-11 17:59:29 +00:00
|
|
|
iosf_mbi_read(BT_MBI_UNIT_PMC, MBI_CR_READ,
|
2023-04-19 02:44:07 +00:00
|
|
|
defaults->floor_freq_reg_addr,
|
2015-11-11 17:59:29 +00:00
|
|
|
&power_ctrl_orig_val);
|
2014-11-07 17:29:26 +00:00
|
|
|
mdata = power_ctrl_orig_val;
|
|
|
|
if (enable) {
|
|
|
|
mdata &= ~(0x7f << 8);
|
|
|
|
mdata |= 1 << 8;
|
|
|
|
}
|
2015-11-11 17:59:29 +00:00
|
|
|
iosf_mbi_write(BT_MBI_UNIT_PMC, MBI_CR_WRITE,
|
2023-04-19 02:44:07 +00:00
|
|
|
defaults->floor_freq_reg_addr, mdata);
|
2014-11-07 17:29:26 +00:00
|
|
|
}
|
|
|
|
|
2023-04-19 02:44:09 +00:00
|
|
|
static u64 rapl_compute_time_window_core(struct rapl_domain *rd, u64 value,
|
2019-07-10 13:44:30 +00:00
|
|
|
bool to_raw)
|
2014-11-07 17:29:26 +00:00
|
|
|
{
|
2019-07-10 13:44:30 +00:00
|
|
|
u64 f, y; /* fraction and exp. used for time unit */
|
2014-11-07 17:29:26 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Special processing based on 2^Y*(1+F/4), refer
|
|
|
|
* to Intel Software Developer's manual Vol.3B: CH 14.9.3.
|
|
|
|
*/
|
|
|
|
if (!to_raw) {
|
|
|
|
f = (value & 0x60) >> 5;
|
|
|
|
y = value & 0x1f;
|
2023-04-19 02:44:09 +00:00
|
|
|
value = (1 << y) * (4 + f) * rd->time_unit / 4;
|
2014-11-07 17:29:26 +00:00
|
|
|
} else {
|
2023-04-19 02:44:09 +00:00
|
|
|
if (value < rd->time_unit)
|
2022-09-20 06:08:26 +00:00
|
|
|
return 0;
|
|
|
|
|
2023-04-19 02:44:09 +00:00
|
|
|
do_div(value, rd->time_unit);
|
2014-11-07 17:29:26 +00:00
|
|
|
y = ilog2(value);
|
powercap: intel_rapl: Fix handling for large time window
When setting the power limit time window, software updates the 'y' bits
and 'f' bits in the power limit register, and the value hardware takes
follows the formula below
Time window = 2 ^ y * (1 + f / 4) * Time_Unit
When handling large time window input from userspace, using left
shifting breaks in two cases:
1. when ilog2(value) is bigger than 31, in expression "1 << y", left
shifting by more than 31 bits has undefined behavior. This breaks
'y'. For example, on an Alderlake platform, "1 << 32" returns 1.
2. when ilog2(value) equals 31, "1 << 31" returns negative value
because '1' is recognized as signed int. And this breaks 'f'.
Given that 'y' has 5 bits and hardware can never take a value larger
than 31, fix the first problem by clamp the time window to the maximum
possible value that the hardware can take.
Fix the second problem by using unsigned bit left shift.
Note that hardware has its own maximum time window limitation, which
may be lower than the time window value retrieved from the power limit
register. When this happens, hardware clamps the input to its maximum
time window limitation. That is why a software clamp is preferred to
handle the problem on hand.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[ rjw: Adjusted the comment added by this change ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-02-11 03:17:10 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The target hardware field is 7 bits wide, so return all ones
|
|
|
|
* if the exponent is too large.
|
|
|
|
*/
|
|
|
|
if (y > 0x1f)
|
|
|
|
return 0x7f;
|
|
|
|
|
|
|
|
f = div64_u64(4 * (value - (1ULL << y)), 1ULL << y);
|
2014-11-07 17:29:26 +00:00
|
|
|
value = (y & 0x1f) | ((f & 0x3) << 5);
|
|
|
|
}
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
2023-04-19 02:44:09 +00:00
|
|
|
static u64 rapl_compute_time_window_atom(struct rapl_domain *rd, u64 value,
|
2019-07-10 13:44:30 +00:00
|
|
|
bool to_raw)
|
2014-11-07 17:29:26 +00:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Atom time unit encoding is straight forward val * time_unit,
|
|
|
|
* where time_unit is default to 1 sec. Never 0.
|
|
|
|
*/
|
|
|
|
if (!to_raw)
|
2023-04-19 02:44:09 +00:00
|
|
|
return (value) ? value * rd->time_unit : rd->time_unit;
|
2019-07-10 13:44:30 +00:00
|
|
|
|
2023-04-19 02:44:09 +00:00
|
|
|
value = div64_u64(value, rd->time_unit);
|
2014-11-07 17:29:26 +00:00
|
|
|
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
2023-04-19 02:44:18 +00:00
|
|
|
/* TPMI Unit register has different layout */
|
|
|
|
#define TPMI_POWER_UNIT_OFFSET POWER_UNIT_OFFSET
|
|
|
|
#define TPMI_POWER_UNIT_MASK POWER_UNIT_MASK
|
|
|
|
#define TPMI_ENERGY_UNIT_OFFSET 0x06
|
|
|
|
#define TPMI_ENERGY_UNIT_MASK 0x7C0
|
|
|
|
#define TPMI_TIME_UNIT_OFFSET 0x0C
|
|
|
|
#define TPMI_TIME_UNIT_MASK 0xF000
|
|
|
|
|
|
|
|
static int rapl_check_unit_tpmi(struct rapl_domain *rd)
|
|
|
|
{
|
|
|
|
struct reg_action ra;
|
|
|
|
u32 value;
|
|
|
|
|
|
|
|
ra.reg = rd->regs[RAPL_DOMAIN_REG_UNIT];
|
|
|
|
ra.mask = ~0;
|
|
|
|
if (rd->rp->priv->read_raw(get_rid(rd->rp), &ra)) {
|
|
|
|
pr_err("Failed to read power unit REG 0x%llx on %s:%s, exit.\n",
|
2023-07-25 05:39:12 +00:00
|
|
|
ra.reg.val, rd->rp->name, rd->name);
|
2023-04-19 02:44:18 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
value = (ra.value & TPMI_ENERGY_UNIT_MASK) >> TPMI_ENERGY_UNIT_OFFSET;
|
|
|
|
rd->energy_unit = ENERGY_UNIT_SCALE * 1000000 / (1 << value);
|
|
|
|
|
|
|
|
value = (ra.value & TPMI_POWER_UNIT_MASK) >> TPMI_POWER_UNIT_OFFSET;
|
|
|
|
rd->power_unit = 1000000 / (1 << value);
|
|
|
|
|
|
|
|
value = (ra.value & TPMI_TIME_UNIT_MASK) >> TPMI_TIME_UNIT_OFFSET;
|
|
|
|
rd->time_unit = 1000000 / (1 << value);
|
|
|
|
|
|
|
|
pr_debug("Core CPU %s:%s energy=%dpJ, time=%dus, power=%duW\n",
|
|
|
|
rd->rp->name, rd->name, rd->energy_unit, rd->time_unit, rd->power_unit);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct rapl_defaults defaults_tpmi = {
|
|
|
|
.check_unit = rapl_check_unit_tpmi,
|
|
|
|
/* Reuse existing logic, ignore the PL_CLAMP failures and enable all Power Limits */
|
|
|
|
.set_floor_freq = set_floor_freq_default,
|
|
|
|
.compute_time_window = rapl_compute_time_window_core,
|
|
|
|
};
|
|
|
|
|
2014-11-07 17:29:25 +00:00
|
|
|
static const struct rapl_defaults rapl_defaults_core = {
|
2015-04-29 20:13:23 +00:00
|
|
|
.floor_freq_reg_addr = 0,
|
2014-11-07 17:29:26 +00:00
|
|
|
.check_unit = rapl_check_unit_core,
|
|
|
|
.set_floor_freq = set_floor_freq_default,
|
|
|
|
.compute_time_window = rapl_compute_time_window_core,
|
2014-11-07 17:29:25 +00:00
|
|
|
};
|
|
|
|
|
2015-03-13 10:48:56 +00:00
|
|
|
static const struct rapl_defaults rapl_defaults_hsw_server = {
|
|
|
|
.check_unit = rapl_check_unit_core,
|
|
|
|
.set_floor_freq = set_floor_freq_default,
|
|
|
|
.compute_time_window = rapl_compute_time_window_core,
|
|
|
|
.dram_domain_energy_unit = 15300,
|
|
|
|
};
|
|
|
|
|
2020-06-29 05:34:50 +00:00
|
|
|
static const struct rapl_defaults rapl_defaults_spr_server = {
|
|
|
|
.check_unit = rapl_check_unit_core,
|
|
|
|
.set_floor_freq = set_floor_freq_default,
|
|
|
|
.compute_time_window = rapl_compute_time_window_core,
|
|
|
|
.psys_domain_energy_unit = 1000000000,
|
2021-12-07 13:17:34 +00:00
|
|
|
.spr_psys_bits = true,
|
2020-06-29 05:34:50 +00:00
|
|
|
};
|
|
|
|
|
2015-04-29 20:13:23 +00:00
|
|
|
static const struct rapl_defaults rapl_defaults_byt = {
|
|
|
|
.floor_freq_reg_addr = IOSF_CPU_POWER_BUDGET_CTL_BYT,
|
|
|
|
.check_unit = rapl_check_unit_atom,
|
|
|
|
.set_floor_freq = set_floor_freq_atom,
|
|
|
|
.compute_time_window = rapl_compute_time_window_atom,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct rapl_defaults rapl_defaults_tng = {
|
|
|
|
.floor_freq_reg_addr = IOSF_CPU_POWER_BUDGET_CTL_TNG,
|
2014-11-07 17:29:26 +00:00
|
|
|
.check_unit = rapl_check_unit_atom,
|
|
|
|
.set_floor_freq = set_floor_freq_atom,
|
|
|
|
.compute_time_window = rapl_compute_time_window_atom,
|
2014-11-07 17:29:25 +00:00
|
|
|
};
|
|
|
|
|
2015-04-29 20:13:23 +00:00
|
|
|
static const struct rapl_defaults rapl_defaults_ann = {
|
|
|
|
.floor_freq_reg_addr = 0,
|
|
|
|
.check_unit = rapl_check_unit_atom,
|
|
|
|
.set_floor_freq = NULL,
|
|
|
|
.compute_time_window = rapl_compute_time_window_atom,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct rapl_defaults rapl_defaults_cht = {
|
|
|
|
.floor_freq_reg_addr = 0,
|
|
|
|
.check_unit = rapl_check_unit_atom,
|
|
|
|
.set_floor_freq = NULL,
|
|
|
|
.compute_time_window = rapl_compute_time_window_atom,
|
|
|
|
};
|
|
|
|
|
2020-10-27 07:23:56 +00:00
|
|
|
static const struct rapl_defaults rapl_defaults_amd = {
|
|
|
|
.check_unit = rapl_check_unit_core,
|
|
|
|
};
|
|
|
|
|
2015-03-25 21:15:52 +00:00
|
|
|
static const struct x86_cpu_id rapl_ids[] __initconst = {
|
2024-05-28 18:47:20 +00:00
|
|
|
X86_MATCH_VFM(INTEL_SANDYBRIDGE, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_SANDYBRIDGE_X, &rapl_defaults_core),
|
|
|
|
|
|
|
|
X86_MATCH_VFM(INTEL_IVYBRIDGE, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_IVYBRIDGE_X, &rapl_defaults_core),
|
|
|
|
|
|
|
|
X86_MATCH_VFM(INTEL_HASWELL, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_HASWELL_L, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_HASWELL_G, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_HASWELL_X, &rapl_defaults_hsw_server),
|
|
|
|
|
|
|
|
X86_MATCH_VFM(INTEL_BROADWELL, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_BROADWELL_G, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_BROADWELL_D, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_BROADWELL_X, &rapl_defaults_hsw_server),
|
|
|
|
|
|
|
|
X86_MATCH_VFM(INTEL_SKYLAKE, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_SKYLAKE_L, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_SKYLAKE_X, &rapl_defaults_hsw_server),
|
|
|
|
X86_MATCH_VFM(INTEL_KABYLAKE_L, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_KABYLAKE, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_CANNONLAKE_L, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_ICELAKE_L, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_ICELAKE, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_ICELAKE_NNPI, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_ICELAKE_X, &rapl_defaults_hsw_server),
|
|
|
|
X86_MATCH_VFM(INTEL_ICELAKE_D, &rapl_defaults_hsw_server),
|
|
|
|
X86_MATCH_VFM(INTEL_COMETLAKE_L, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_COMETLAKE, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_TIGERLAKE_L, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_TIGERLAKE, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_ROCKETLAKE, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_ALDERLAKE, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_ALDERLAKE_L, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_ATOM_GRACEMONT, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_RAPTORLAKE, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_RAPTORLAKE_P, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_RAPTORLAKE_S, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_METEORLAKE, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_METEORLAKE_L, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_SAPPHIRERAPIDS_X, &rapl_defaults_spr_server),
|
|
|
|
X86_MATCH_VFM(INTEL_EMERALDRAPIDS_X, &rapl_defaults_spr_server),
|
|
|
|
X86_MATCH_VFM(INTEL_LUNARLAKE_M, &rapl_defaults_core),
|
2024-12-03 07:58:00 +00:00
|
|
|
X86_MATCH_VFM(INTEL_PANTHERLAKE_L, &rapl_defaults_core),
|
2024-05-28 18:47:20 +00:00
|
|
|
X86_MATCH_VFM(INTEL_ARROWLAKE_H, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_ARROWLAKE, &rapl_defaults_core),
|
2024-08-16 11:33:32 +00:00
|
|
|
X86_MATCH_VFM(INTEL_ARROWLAKE_U, &rapl_defaults_core),
|
2024-05-28 18:47:20 +00:00
|
|
|
X86_MATCH_VFM(INTEL_LAKEFIELD, &rapl_defaults_core),
|
|
|
|
|
|
|
|
X86_MATCH_VFM(INTEL_ATOM_SILVERMONT, &rapl_defaults_byt),
|
|
|
|
X86_MATCH_VFM(INTEL_ATOM_AIRMONT, &rapl_defaults_cht),
|
|
|
|
X86_MATCH_VFM(INTEL_ATOM_SILVERMONT_MID, &rapl_defaults_tng),
|
|
|
|
X86_MATCH_VFM(INTEL_ATOM_AIRMONT_MID, &rapl_defaults_ann),
|
|
|
|
X86_MATCH_VFM(INTEL_ATOM_GOLDMONT, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_ATOM_GOLDMONT_PLUS, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_ATOM_GOLDMONT_D, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_ATOM_TREMONT, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_ATOM_TREMONT_D, &rapl_defaults_core),
|
|
|
|
X86_MATCH_VFM(INTEL_ATOM_TREMONT_L, &rapl_defaults_core),
|
|
|
|
|
|
|
|
X86_MATCH_VFM(INTEL_XEON_PHI_KNL, &rapl_defaults_hsw_server),
|
|
|
|
X86_MATCH_VFM(INTEL_XEON_PHI_KNM, &rapl_defaults_hsw_server),
|
2020-10-27 07:23:56 +00:00
|
|
|
|
|
|
|
X86_MATCH_VENDOR_FAM(AMD, 0x17, &rapl_defaults_amd),
|
2020-10-27 07:23:57 +00:00
|
|
|
X86_MATCH_VENDOR_FAM(AMD, 0x19, &rapl_defaults_amd),
|
2024-07-19 10:12:35 +00:00
|
|
|
X86_MATCH_VENDOR_FAM(AMD, 0x1A, &rapl_defaults_amd),
|
2021-03-02 02:01:08 +00:00
|
|
|
X86_MATCH_VENDOR_FAM(HYGON, 0x18, &rapl_defaults_amd),
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{}
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
|
|
|
|
|
2016-11-22 21:15:58 +00:00
|
|
|
/* Read once for all raw primitive data for domains */
|
|
|
|
static void rapl_update_domain_data(struct rapl_package *rp)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
|
|
|
int dmn, prim;
|
|
|
|
u64 val;
|
|
|
|
|
2016-11-22 21:15:58 +00:00
|
|
|
for (dmn = 0; dmn < rp->nr_domains; dmn++) {
|
2019-05-13 17:58:53 +00:00
|
|
|
pr_debug("update %s domain %s data\n", rp->name,
|
2016-11-22 21:15:58 +00:00
|
|
|
rp->domains[dmn].name);
|
|
|
|
/* exclude non-raw primitives */
|
|
|
|
for (prim = 0; prim < NR_RAW_PRIMITIVES; prim++) {
|
2023-04-19 02:44:08 +00:00
|
|
|
struct rapl_primitive_info *rpi = get_rpi(rp, prim);
|
|
|
|
|
2016-11-22 21:15:58 +00:00
|
|
|
if (!rapl_read_data_raw(&rp->domains[dmn], prim,
|
2023-04-19 02:44:08 +00:00
|
|
|
rpi->unit, &val))
|
2019-07-10 13:44:30 +00:00
|
|
|
rp->domains[dmn].rdd.primitives[prim] = val;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rapl_package_register_powercap(struct rapl_package *rp)
|
|
|
|
{
|
|
|
|
struct rapl_domain *rd;
|
|
|
|
struct powercap_zone *power_zone = NULL;
|
2018-01-17 10:30:34 +00:00
|
|
|
int nr_pl, ret;
|
2016-11-22 21:15:58 +00:00
|
|
|
|
|
|
|
/* Update the domain data of the new package */
|
|
|
|
rapl_update_domain_data(rp);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2019-07-10 13:44:30 +00:00
|
|
|
/* first we register package domain as the parent zone */
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
for (rd = rp->domains; rd < rp->domains + rp->nr_domains; rd++) {
|
|
|
|
if (rd->id == RAPL_DOMAIN_PACKAGE) {
|
|
|
|
nr_pl = find_nr_power_limit(rd);
|
2019-05-13 17:58:53 +00:00
|
|
|
pr_debug("register package domain %s\n", rp->name);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
power_zone = powercap_register_zone(&rd->power_zone,
|
2019-07-10 13:44:30 +00:00
|
|
|
rp->priv->control_type, rp->name,
|
|
|
|
NULL, &zone_ops[rd->id], nr_pl,
|
|
|
|
&constraint_ops);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
if (IS_ERR(power_zone)) {
|
2019-05-13 17:58:53 +00:00
|
|
|
pr_debug("failed to register power zone %s\n",
|
2019-07-10 13:44:30 +00:00
|
|
|
rp->name);
|
2016-11-22 21:15:58 +00:00
|
|
|
return PTR_ERR(power_zone);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
/* track parent zone in per package/socket data */
|
|
|
|
rp->power_zone = power_zone;
|
|
|
|
/* done, only one package domain per socket */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!power_zone) {
|
|
|
|
pr_err("no package domain found, unknown topology!\n");
|
2016-11-22 21:15:58 +00:00
|
|
|
return -ENODEV;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
2019-07-10 13:44:30 +00:00
|
|
|
/* now register domains as children of the socket/package */
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
for (rd = rp->domains; rd < rp->domains + rp->nr_domains; rd++) {
|
2020-10-13 07:42:41 +00:00
|
|
|
struct powercap_zone *parent = rp->power_zone;
|
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
if (rd->id == RAPL_DOMAIN_PACKAGE)
|
|
|
|
continue;
|
2020-10-13 07:42:41 +00:00
|
|
|
if (rd->id == RAPL_DOMAIN_PLATFORM)
|
|
|
|
parent = NULL;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* number of power limits per domain varies */
|
|
|
|
nr_pl = find_nr_power_limit(rd);
|
|
|
|
power_zone = powercap_register_zone(&rd->power_zone,
|
2019-07-10 13:44:30 +00:00
|
|
|
rp->priv->control_type,
|
2020-10-13 07:42:41 +00:00
|
|
|
rd->name, parent,
|
2019-07-10 13:44:30 +00:00
|
|
|
&zone_ops[rd->id], nr_pl,
|
|
|
|
&constraint_ops);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
if (IS_ERR(power_zone)) {
|
2019-05-13 17:58:53 +00:00
|
|
|
pr_debug("failed to register power_zone, %s:%s\n",
|
2019-07-10 13:44:30 +00:00
|
|
|
rp->name, rd->name);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
ret = PTR_ERR(power_zone);
|
|
|
|
goto err_cleanup;
|
|
|
|
}
|
|
|
|
}
|
2016-11-22 21:15:58 +00:00
|
|
|
return 0;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
err_cleanup:
|
2016-11-22 21:16:02 +00:00
|
|
|
/*
|
|
|
|
* Clean up previously initialized domains within the package if we
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
* failed after the first domain setup.
|
|
|
|
*/
|
|
|
|
while (--rd >= rp->domains) {
|
2019-05-13 17:58:53 +00:00
|
|
|
pr_debug("unregister %s domain %s\n", rp->name, rd->name);
|
2019-07-10 13:44:30 +00:00
|
|
|
powercap_unregister_zone(rp->priv->control_type,
|
|
|
|
&rd->power_zone);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2023-04-19 02:44:15 +00:00
|
|
|
static int rapl_check_domain(int domain, struct rapl_package *rp)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
2019-07-10 13:44:29 +00:00
|
|
|
struct reg_action ra;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
switch (domain) {
|
|
|
|
case RAPL_DOMAIN_PACKAGE:
|
|
|
|
case RAPL_DOMAIN_PP0:
|
|
|
|
case RAPL_DOMAIN_PP1:
|
|
|
|
case RAPL_DOMAIN_DRAM:
|
2020-10-13 07:42:41 +00:00
|
|
|
case RAPL_DOMAIN_PLATFORM:
|
2019-07-10 13:44:29 +00:00
|
|
|
ra.reg = rp->priv->regs[domain][RAPL_DOMAIN_REG_STATUS];
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
pr_err("invalid domain id %d\n", domain);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2014-04-29 22:33:06 +00:00
|
|
|
/* make sure domain counters are available and contains non-zero
|
|
|
|
* values, otherwise skip it.
|
2014-02-10 14:11:51 +00:00
|
|
|
*/
|
2019-07-10 13:44:29 +00:00
|
|
|
|
2020-10-13 07:42:40 +00:00
|
|
|
ra.mask = ENERGY_STATUS_MASK;
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
if (rp->priv->read_raw(get_rid(rp), &ra) || !ra.value)
|
2014-04-29 22:33:06 +00:00
|
|
|
return -ENODEV;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2014-04-29 22:33:06 +00:00
|
|
|
return 0;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
|
2023-04-19 02:44:09 +00:00
|
|
|
/*
|
|
|
|
* Get per domain energy/power/time unit.
|
|
|
|
* RAPL Interfaces without per domain unit register will use the package
|
|
|
|
* scope unit register to set per domain units.
|
|
|
|
*/
|
|
|
|
static int rapl_get_domain_unit(struct rapl_domain *rd)
|
|
|
|
{
|
|
|
|
struct rapl_defaults *defaults = get_defaults(rd->rp);
|
|
|
|
int ret;
|
|
|
|
|
2023-07-25 05:39:12 +00:00
|
|
|
if (!rd->regs[RAPL_DOMAIN_REG_UNIT].val) {
|
|
|
|
if (!rd->rp->priv->reg_unit.val) {
|
2023-04-19 02:44:09 +00:00
|
|
|
pr_err("No valid Unit register found\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
rd->regs[RAPL_DOMAIN_REG_UNIT] = rd->rp->priv->reg_unit;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!defaults->check_unit) {
|
|
|
|
pr_err("missing .check_unit() callback\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2023-04-19 02:44:15 +00:00
|
|
|
ret = defaults->check_unit(rd);
|
2023-04-19 02:44:09 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
if (rd->id == RAPL_DOMAIN_DRAM && defaults->dram_domain_energy_unit)
|
|
|
|
rd->energy_unit = defaults->dram_domain_energy_unit;
|
|
|
|
if (rd->id == RAPL_DOMAIN_PLATFORM && defaults->psys_domain_energy_unit)
|
|
|
|
rd->energy_unit = defaults->psys_domain_energy_unit;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-31 20:41:29 +00:00
|
|
|
/*
|
|
|
|
* Check if power limits are available. Two cases when they are not available:
|
|
|
|
* 1. Locked by BIOS, in this case we still provide read-only access so that
|
|
|
|
* users can see what limit is set by the BIOS.
|
|
|
|
* 2. Some CPUs make some domains monitoring only which means PLx MSRs may not
|
2019-07-10 13:44:30 +00:00
|
|
|
* exist at all. In this case, we do not show the constraints in powercap.
|
2016-05-31 20:41:29 +00:00
|
|
|
*
|
|
|
|
* Called after domains are detected and initialized.
|
|
|
|
*/
|
|
|
|
static void rapl_detect_powerlimit(struct rapl_domain *rd)
|
|
|
|
{
|
|
|
|
u64 val64;
|
|
|
|
int i;
|
|
|
|
|
2023-04-19 02:44:14 +00:00
|
|
|
for (i = POWER_LIMIT1; i < NR_POWER_LIMITS; i++) {
|
|
|
|
if (!rapl_read_pl_data(rd, i, PL_LOCK, false, &val64)) {
|
|
|
|
if (val64) {
|
|
|
|
rd->rpl[i].locked = true;
|
|
|
|
pr_info("%s:%s:%s locked by BIOS\n",
|
|
|
|
rd->rp->name, rd->name, pl_names[i]);
|
|
|
|
}
|
2016-05-31 20:41:29 +00:00
|
|
|
}
|
2019-07-10 13:44:30 +00:00
|
|
|
|
powercap: intel_rapl: Fix invalid setting of Power Limit 4
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 <rui.zhang@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Tested-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Cc: 6.5+ <stable@vger.kernel.org> # 6.5+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-09-06 19:08:16 +00:00
|
|
|
if (rapl_read_pl_data(rd, i, PL_LIMIT, false, &val64))
|
2016-05-31 20:41:29 +00:00
|
|
|
rd->rpl[i].name = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* Detect active and valid domains for the given CPU, caller must
|
|
|
|
* ensure the CPU belongs to the targeted package and CPU hotlug is disabled.
|
|
|
|
*/
|
2023-04-19 02:44:15 +00:00
|
|
|
static int rapl_detect_domains(struct rapl_package *rp)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
|
|
|
struct rapl_domain *rd;
|
2016-11-22 21:16:02 +00:00
|
|
|
int i;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
for (i = 0; i < RAPL_DOMAIN_MAX; i++) {
|
|
|
|
/* use physical package id to read counters */
|
2023-04-19 02:44:15 +00:00
|
|
|
if (!rapl_check_domain(i, rp)) {
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
rp->domain_map |= 1 << i;
|
2014-09-02 09:55:21 +00:00
|
|
|
pr_info("Found RAPL domain %s\n", rapl_domain_names[i]);
|
|
|
|
}
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
2019-07-10 13:44:30 +00:00
|
|
|
rp->nr_domains = bitmap_weight(&rp->domain_map, RAPL_DOMAIN_MAX);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
if (!rp->nr_domains) {
|
2019-05-13 17:58:53 +00:00
|
|
|
pr_debug("no valid rapl domains found in %s\n", rp->name);
|
2016-11-22 21:16:02 +00:00
|
|
|
return -ENODEV;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
2019-05-13 17:58:53 +00:00
|
|
|
pr_debug("found %d domains on %s\n", rp->nr_domains, rp->name);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2023-04-07 02:47:59 +00:00
|
|
|
rp->domains = kcalloc(rp->nr_domains, sizeof(struct rapl_domain),
|
2019-07-10 13:44:30 +00:00
|
|
|
GFP_KERNEL);
|
2016-11-22 21:16:02 +00:00
|
|
|
if (!rp->domains)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
rapl_init_domains(rp);
|
|
|
|
|
2023-04-19 02:44:09 +00:00
|
|
|
for (rd = rp->domains; rd < rp->domains + rp->nr_domains; rd++) {
|
|
|
|
rapl_get_domain_unit(rd);
|
2016-05-31 20:41:29 +00:00
|
|
|
rapl_detect_powerlimit(rd);
|
2023-04-19 02:44:09 +00:00
|
|
|
}
|
2016-05-31 20:41:29 +00:00
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
powercap: intel_rapl: Introduce APIs for PMU support
Introduce two new APIs rapl_package_add_pmu()/rapl_package_remove_pmu().
RAPL driver can invoke these APIs to expose its supported energy
counters via perf PMU. The new RAPL PMU is fully compatible with current
MSR RAPL PMU, including using the same PMU name and events
name/id/unit/scale, etc.
For example, use below command
perf stat -e power/energy-pkg/ -e power/energy-ram/ FOO
to get the energy consumption if power/energy-pkg/ and power/energy-ram/
events are available in the "perf list" output.
This does not introduce any conflict because TPMI RAPL is the only user
of these APIs currently, and it never co-exists with MSR RAPL.
Note that RAPL Packages can be probed/removed dynamically, and the
events supported by each TPMI RAPL device can be different. Thus the
RAPL PMU support is done on demand, which means
1. PMU is registered only if it is needed by a RAPL Package. PMU events
for unsupported counters are not exposed.
2. PMU is unregistered and registered when a new RAPL Package is probed
and supports new counters that are not supported by current PMU.
For example, on a dual-package system using TPMI RAPL, it is possible
that Package 1 behaves as TPMI domain root and supports Psys domain.
In this case, register PMU without Psys event when probing Package 0,
and re-register the PMU with Psys event when probing Package 1.
3. PMU is unregistered when all registered RAPL Packages don't need PMU.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-04-28 09:24:26 +00:00
|
|
|
#ifdef CONFIG_PERF_EVENTS
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Support for RAPL PMU
|
|
|
|
*
|
|
|
|
* Register a PMU if any of the registered RAPL Packages have the requirement
|
|
|
|
* of exposing its energy counters via Perf PMU.
|
|
|
|
*
|
|
|
|
* PMU Name:
|
|
|
|
* power
|
|
|
|
*
|
|
|
|
* Events:
|
|
|
|
* Name Event id RAPL Domain
|
|
|
|
* energy_cores 0x01 RAPL_DOMAIN_PP0
|
|
|
|
* energy_pkg 0x02 RAPL_DOMAIN_PACKAGE
|
|
|
|
* energy_ram 0x03 RAPL_DOMAIN_DRAM
|
|
|
|
* energy_gpu 0x04 RAPL_DOMAIN_PP1
|
|
|
|
* energy_psys 0x05 RAPL_DOMAIN_PLATFORM
|
|
|
|
*
|
|
|
|
* Unit:
|
|
|
|
* Joules
|
|
|
|
*
|
|
|
|
* Scale:
|
|
|
|
* 2.3283064365386962890625e-10
|
|
|
|
* The same RAPL domain in different RAPL Packages may have different
|
|
|
|
* energy units. Use 2.3283064365386962890625e-10 (2^-32) Joules as
|
|
|
|
* the fixed unit for all energy counters, and covert each hardware
|
|
|
|
* counter increase to N times of PMU event counter increases.
|
|
|
|
*
|
|
|
|
* This is fully compatible with the current MSR RAPL PMU. This means that
|
|
|
|
* userspace programs like turbostat can use the same code to handle RAPL Perf
|
|
|
|
* PMU, no matter what RAPL Interface driver (MSR/TPMI, etc) is running
|
|
|
|
* underlying on the platform.
|
|
|
|
*
|
|
|
|
* Note that RAPL Packages can be probed/removed dynamically, and the events
|
|
|
|
* supported by each TPMI RAPL device can be different. Thus the RAPL PMU
|
|
|
|
* support is done on demand, which means
|
|
|
|
* 1. PMU is registered only if it is needed by a RAPL Package. PMU events for
|
|
|
|
* unsupported counters are not exposed.
|
|
|
|
* 2. PMU is unregistered and registered when a new RAPL Package is probed and
|
|
|
|
* supports new counters that are not supported by current PMU.
|
|
|
|
* 3. PMU is unregistered when all registered RAPL Packages don't need PMU.
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct rapl_pmu {
|
|
|
|
struct pmu pmu; /* Perf PMU structure */
|
|
|
|
u64 timer_ms; /* Maximum expiration time to avoid counter overflow */
|
|
|
|
unsigned long domain_map; /* Events supported by current registered PMU */
|
|
|
|
bool registered; /* Whether the PMU has been registered or not */
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct rapl_pmu rapl_pmu;
|
|
|
|
|
|
|
|
/* PMU helpers */
|
|
|
|
|
|
|
|
static int get_pmu_cpu(struct rapl_package *rp)
|
|
|
|
{
|
|
|
|
int cpu;
|
|
|
|
|
|
|
|
if (!rp->has_pmu)
|
|
|
|
return nr_cpu_ids;
|
|
|
|
|
|
|
|
/* Only TPMI RAPL is supported for now */
|
|
|
|
if (rp->priv->type != RAPL_IF_TPMI)
|
|
|
|
return nr_cpu_ids;
|
|
|
|
|
|
|
|
/* TPMI RAPL uses any CPU in the package for PMU */
|
|
|
|
for_each_online_cpu(cpu)
|
|
|
|
if (topology_physical_package_id(cpu) == rp->id)
|
|
|
|
return cpu;
|
|
|
|
|
|
|
|
return nr_cpu_ids;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool is_rp_pmu_cpu(struct rapl_package *rp, int cpu)
|
|
|
|
{
|
|
|
|
if (!rp->has_pmu)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Only TPMI RAPL is supported for now */
|
|
|
|
if (rp->priv->type != RAPL_IF_TPMI)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* TPMI RAPL uses any CPU in the package for PMU */
|
|
|
|
return topology_physical_package_id(cpu) == rp->id;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct rapl_package_pmu_data *event_to_pmu_data(struct perf_event *event)
|
|
|
|
{
|
|
|
|
struct rapl_package *rp = event->pmu_private;
|
|
|
|
|
|
|
|
return &rp->pmu_data;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* PMU event callbacks */
|
|
|
|
|
|
|
|
static u64 event_read_counter(struct perf_event *event)
|
|
|
|
{
|
|
|
|
struct rapl_package *rp = event->pmu_private;
|
|
|
|
u64 val;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* Return 0 for unsupported events */
|
|
|
|
if (event->hw.idx < 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
ret = rapl_read_data_raw(&rp->domains[event->hw.idx], ENERGY_COUNTER, false, &val);
|
|
|
|
|
|
|
|
/* Return 0 for failed read */
|
|
|
|
if (ret)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __rapl_pmu_event_start(struct perf_event *event)
|
|
|
|
{
|
|
|
|
struct rapl_package_pmu_data *data = event_to_pmu_data(event);
|
|
|
|
|
|
|
|
if (WARN_ON_ONCE(!(event->hw.state & PERF_HES_STOPPED)))
|
|
|
|
return;
|
|
|
|
|
|
|
|
event->hw.state = 0;
|
|
|
|
|
|
|
|
list_add_tail(&event->active_entry, &data->active_list);
|
|
|
|
|
|
|
|
local64_set(&event->hw.prev_count, event_read_counter(event));
|
|
|
|
if (++data->n_active == 1)
|
|
|
|
hrtimer_start(&data->hrtimer, data->timer_interval,
|
|
|
|
HRTIMER_MODE_REL_PINNED);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rapl_pmu_event_start(struct perf_event *event, int mode)
|
|
|
|
{
|
|
|
|
struct rapl_package_pmu_data *data = event_to_pmu_data(event);
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
raw_spin_lock_irqsave(&data->lock, flags);
|
|
|
|
__rapl_pmu_event_start(event);
|
|
|
|
raw_spin_unlock_irqrestore(&data->lock, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
static u64 rapl_event_update(struct perf_event *event)
|
|
|
|
{
|
|
|
|
struct hw_perf_event *hwc = &event->hw;
|
|
|
|
struct rapl_package_pmu_data *data = event_to_pmu_data(event);
|
|
|
|
u64 prev_raw_count, new_raw_count;
|
|
|
|
s64 delta, sdelta;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Follow the generic code to drain hwc->prev_count.
|
|
|
|
* The loop is not expected to run for multiple times.
|
|
|
|
*/
|
|
|
|
prev_raw_count = local64_read(&hwc->prev_count);
|
|
|
|
do {
|
|
|
|
new_raw_count = event_read_counter(event);
|
|
|
|
} while (!local64_try_cmpxchg(&hwc->prev_count,
|
|
|
|
&prev_raw_count, new_raw_count));
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now we have the new raw value and have updated the prev
|
|
|
|
* timestamp already. We can now calculate the elapsed delta
|
|
|
|
* (event-)time and add that to the generic event.
|
|
|
|
*/
|
|
|
|
delta = new_raw_count - prev_raw_count;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Scale delta to smallest unit (2^-32)
|
|
|
|
* users must then scale back: count * 1/(1e9*2^32) to get Joules
|
|
|
|
* or use ldexp(count, -32).
|
|
|
|
* Watts = Joules/Time delta
|
|
|
|
*/
|
|
|
|
sdelta = delta * data->scale[event->hw.flags];
|
|
|
|
|
|
|
|
local64_add(sdelta, &event->count);
|
|
|
|
|
|
|
|
return new_raw_count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rapl_pmu_event_stop(struct perf_event *event, int mode)
|
|
|
|
{
|
|
|
|
struct rapl_package_pmu_data *data = event_to_pmu_data(event);
|
|
|
|
struct hw_perf_event *hwc = &event->hw;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
raw_spin_lock_irqsave(&data->lock, flags);
|
|
|
|
|
|
|
|
/* Mark event as deactivated and stopped */
|
|
|
|
if (!(hwc->state & PERF_HES_STOPPED)) {
|
|
|
|
WARN_ON_ONCE(data->n_active <= 0);
|
|
|
|
if (--data->n_active == 0)
|
|
|
|
hrtimer_cancel(&data->hrtimer);
|
|
|
|
|
|
|
|
list_del(&event->active_entry);
|
|
|
|
|
|
|
|
WARN_ON_ONCE(hwc->state & PERF_HES_STOPPED);
|
|
|
|
hwc->state |= PERF_HES_STOPPED;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check if update of sw counter is necessary */
|
|
|
|
if ((mode & PERF_EF_UPDATE) && !(hwc->state & PERF_HES_UPTODATE)) {
|
|
|
|
/*
|
|
|
|
* Drain the remaining delta count out of a event
|
|
|
|
* that we are disabling:
|
|
|
|
*/
|
|
|
|
rapl_event_update(event);
|
|
|
|
hwc->state |= PERF_HES_UPTODATE;
|
|
|
|
}
|
|
|
|
|
|
|
|
raw_spin_unlock_irqrestore(&data->lock, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rapl_pmu_event_add(struct perf_event *event, int mode)
|
|
|
|
{
|
|
|
|
struct rapl_package_pmu_data *data = event_to_pmu_data(event);
|
|
|
|
struct hw_perf_event *hwc = &event->hw;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
raw_spin_lock_irqsave(&data->lock, flags);
|
|
|
|
|
|
|
|
hwc->state = PERF_HES_UPTODATE | PERF_HES_STOPPED;
|
|
|
|
|
|
|
|
if (mode & PERF_EF_START)
|
|
|
|
__rapl_pmu_event_start(event);
|
|
|
|
|
|
|
|
raw_spin_unlock_irqrestore(&data->lock, flags);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rapl_pmu_event_del(struct perf_event *event, int flags)
|
|
|
|
{
|
|
|
|
rapl_pmu_event_stop(event, PERF_EF_UPDATE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* RAPL PMU event ids, same as shown in sysfs */
|
|
|
|
enum perf_rapl_events {
|
|
|
|
PERF_RAPL_PP0 = 1, /* all cores */
|
|
|
|
PERF_RAPL_PKG, /* entire package */
|
|
|
|
PERF_RAPL_RAM, /* DRAM */
|
|
|
|
PERF_RAPL_PP1, /* gpu */
|
|
|
|
PERF_RAPL_PSYS, /* psys */
|
|
|
|
PERF_RAPL_MAX
|
|
|
|
};
|
|
|
|
#define RAPL_EVENT_MASK GENMASK(7, 0)
|
|
|
|
|
|
|
|
static const int event_to_domain[PERF_RAPL_MAX] = {
|
|
|
|
[PERF_RAPL_PP0] = RAPL_DOMAIN_PP0,
|
|
|
|
[PERF_RAPL_PKG] = RAPL_DOMAIN_PACKAGE,
|
|
|
|
[PERF_RAPL_RAM] = RAPL_DOMAIN_DRAM,
|
|
|
|
[PERF_RAPL_PP1] = RAPL_DOMAIN_PP1,
|
|
|
|
[PERF_RAPL_PSYS] = RAPL_DOMAIN_PLATFORM,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int rapl_pmu_event_init(struct perf_event *event)
|
|
|
|
{
|
|
|
|
struct rapl_package *pos, *rp = NULL;
|
|
|
|
u64 cfg = event->attr.config & RAPL_EVENT_MASK;
|
|
|
|
int domain, idx;
|
|
|
|
|
|
|
|
/* Only look at RAPL events */
|
|
|
|
if (event->attr.type != event->pmu->type)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
/* Check for supported events only */
|
|
|
|
if (!cfg || cfg >= PERF_RAPL_MAX)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (event->cpu < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* Find out which Package the event belongs to */
|
|
|
|
list_for_each_entry(pos, &rapl_packages, plist) {
|
|
|
|
if (is_rp_pmu_cpu(pos, event->cpu)) {
|
|
|
|
rp = pos;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!rp)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
/* Find out which RAPL Domain the event belongs to */
|
|
|
|
domain = event_to_domain[cfg];
|
|
|
|
|
|
|
|
event->event_caps |= PERF_EV_CAP_READ_ACTIVE_PKG;
|
|
|
|
event->pmu_private = rp; /* Which package */
|
|
|
|
event->hw.flags = domain; /* Which domain */
|
|
|
|
|
|
|
|
event->hw.idx = -1;
|
|
|
|
/* Find out the index in rp->domains[] to get domain pointer */
|
|
|
|
for (idx = 0; idx < rp->nr_domains; idx++) {
|
|
|
|
if (rp->domains[idx].id == domain) {
|
|
|
|
event->hw.idx = idx;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rapl_pmu_event_read(struct perf_event *event)
|
|
|
|
{
|
|
|
|
rapl_event_update(event);
|
|
|
|
}
|
|
|
|
|
|
|
|
static enum hrtimer_restart rapl_hrtimer_handle(struct hrtimer *hrtimer)
|
|
|
|
{
|
|
|
|
struct rapl_package_pmu_data *data =
|
|
|
|
container_of(hrtimer, struct rapl_package_pmu_data, hrtimer);
|
|
|
|
struct perf_event *event;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
if (!data->n_active)
|
|
|
|
return HRTIMER_NORESTART;
|
|
|
|
|
|
|
|
raw_spin_lock_irqsave(&data->lock, flags);
|
|
|
|
|
|
|
|
list_for_each_entry(event, &data->active_list, active_entry)
|
|
|
|
rapl_event_update(event);
|
|
|
|
|
|
|
|
raw_spin_unlock_irqrestore(&data->lock, flags);
|
|
|
|
|
|
|
|
hrtimer_forward_now(hrtimer, data->timer_interval);
|
|
|
|
|
|
|
|
return HRTIMER_RESTART;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* PMU sysfs attributes */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* There are no default events, but we need to create "events" group (with
|
|
|
|
* empty attrs) before updating it with detected events.
|
|
|
|
*/
|
|
|
|
static struct attribute *attrs_empty[] = {
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct attribute_group pmu_events_group = {
|
|
|
|
.name = "events",
|
|
|
|
.attrs = attrs_empty,
|
|
|
|
};
|
|
|
|
|
|
|
|
static ssize_t cpumask_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct rapl_package *rp;
|
|
|
|
cpumask_var_t cpu_mask;
|
|
|
|
int cpu;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!alloc_cpumask_var(&cpu_mask, GFP_KERNEL))
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
cpus_read_lock();
|
|
|
|
|
|
|
|
cpumask_clear(cpu_mask);
|
|
|
|
|
|
|
|
/* Choose a cpu for each RAPL Package */
|
|
|
|
list_for_each_entry(rp, &rapl_packages, plist) {
|
|
|
|
cpu = get_pmu_cpu(rp);
|
|
|
|
if (cpu < nr_cpu_ids)
|
|
|
|
cpumask_set_cpu(cpu, cpu_mask);
|
|
|
|
}
|
|
|
|
cpus_read_unlock();
|
|
|
|
|
|
|
|
ret = cpumap_print_to_pagebuf(true, buf, cpu_mask);
|
|
|
|
|
|
|
|
free_cpumask_var(cpu_mask);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static DEVICE_ATTR_RO(cpumask);
|
|
|
|
|
|
|
|
static struct attribute *pmu_cpumask_attrs[] = {
|
|
|
|
&dev_attr_cpumask.attr,
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct attribute_group pmu_cpumask_group = {
|
|
|
|
.attrs = pmu_cpumask_attrs,
|
|
|
|
};
|
|
|
|
|
|
|
|
PMU_FORMAT_ATTR(event, "config:0-7");
|
|
|
|
static struct attribute *pmu_format_attr[] = {
|
|
|
|
&format_attr_event.attr,
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct attribute_group pmu_format_group = {
|
|
|
|
.name = "format",
|
|
|
|
.attrs = pmu_format_attr,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct attribute_group *pmu_attr_groups[] = {
|
|
|
|
&pmu_events_group,
|
|
|
|
&pmu_cpumask_group,
|
|
|
|
&pmu_format_group,
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
#define RAPL_EVENT_ATTR_STR(_name, v, str) \
|
|
|
|
static struct perf_pmu_events_attr event_attr_##v = { \
|
|
|
|
.attr = __ATTR(_name, 0444, perf_event_sysfs_show, NULL), \
|
|
|
|
.event_str = str, \
|
|
|
|
}
|
|
|
|
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-cores, rapl_cores, "event=0x01");
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-pkg, rapl_pkg, "event=0x02");
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-ram, rapl_ram, "event=0x03");
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-gpu, rapl_gpu, "event=0x04");
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-psys, rapl_psys, "event=0x05");
|
|
|
|
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-cores.unit, rapl_unit_cores, "Joules");
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-pkg.unit, rapl_unit_pkg, "Joules");
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-ram.unit, rapl_unit_ram, "Joules");
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-gpu.unit, rapl_unit_gpu, "Joules");
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-psys.unit, rapl_unit_psys, "Joules");
|
|
|
|
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-cores.scale, rapl_scale_cores, "2.3283064365386962890625e-10");
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-pkg.scale, rapl_scale_pkg, "2.3283064365386962890625e-10");
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-ram.scale, rapl_scale_ram, "2.3283064365386962890625e-10");
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-gpu.scale, rapl_scale_gpu, "2.3283064365386962890625e-10");
|
|
|
|
RAPL_EVENT_ATTR_STR(energy-psys.scale, rapl_scale_psys, "2.3283064365386962890625e-10");
|
|
|
|
|
|
|
|
#define RAPL_EVENT_GROUP(_name, domain) \
|
|
|
|
static struct attribute *pmu_attr_##_name[] = { \
|
|
|
|
&event_attr_rapl_##_name.attr.attr, \
|
|
|
|
&event_attr_rapl_unit_##_name.attr.attr, \
|
|
|
|
&event_attr_rapl_scale_##_name.attr.attr, \
|
|
|
|
NULL \
|
|
|
|
}; \
|
|
|
|
static umode_t is_visible_##_name(struct kobject *kobj, struct attribute *attr, int event) \
|
|
|
|
{ \
|
|
|
|
return rapl_pmu.domain_map & BIT(domain) ? attr->mode : 0; \
|
|
|
|
} \
|
|
|
|
static struct attribute_group pmu_group_##_name = { \
|
|
|
|
.name = "events", \
|
|
|
|
.attrs = pmu_attr_##_name, \
|
|
|
|
.is_visible = is_visible_##_name, \
|
|
|
|
}
|
|
|
|
|
|
|
|
RAPL_EVENT_GROUP(cores, RAPL_DOMAIN_PP0);
|
|
|
|
RAPL_EVENT_GROUP(pkg, RAPL_DOMAIN_PACKAGE);
|
|
|
|
RAPL_EVENT_GROUP(ram, RAPL_DOMAIN_DRAM);
|
|
|
|
RAPL_EVENT_GROUP(gpu, RAPL_DOMAIN_PP1);
|
|
|
|
RAPL_EVENT_GROUP(psys, RAPL_DOMAIN_PLATFORM);
|
|
|
|
|
|
|
|
static const struct attribute_group *pmu_attr_update[] = {
|
|
|
|
&pmu_group_cores,
|
|
|
|
&pmu_group_pkg,
|
|
|
|
&pmu_group_ram,
|
|
|
|
&pmu_group_gpu,
|
|
|
|
&pmu_group_psys,
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
static int rapl_pmu_update(struct rapl_package *rp)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
/* Return if PMU already covers all events supported by current RAPL Package */
|
|
|
|
if (rapl_pmu.registered && !(rp->domain_map & (~rapl_pmu.domain_map)))
|
|
|
|
goto end;
|
|
|
|
|
|
|
|
/* Unregister previous registered PMU */
|
|
|
|
if (rapl_pmu.registered)
|
|
|
|
perf_pmu_unregister(&rapl_pmu.pmu);
|
|
|
|
|
|
|
|
rapl_pmu.registered = false;
|
|
|
|
rapl_pmu.domain_map |= rp->domain_map;
|
|
|
|
|
|
|
|
memset(&rapl_pmu.pmu, 0, sizeof(struct pmu));
|
|
|
|
rapl_pmu.pmu.attr_groups = pmu_attr_groups;
|
|
|
|
rapl_pmu.pmu.attr_update = pmu_attr_update;
|
|
|
|
rapl_pmu.pmu.task_ctx_nr = perf_invalid_context;
|
|
|
|
rapl_pmu.pmu.event_init = rapl_pmu_event_init;
|
|
|
|
rapl_pmu.pmu.add = rapl_pmu_event_add;
|
|
|
|
rapl_pmu.pmu.del = rapl_pmu_event_del;
|
|
|
|
rapl_pmu.pmu.start = rapl_pmu_event_start;
|
|
|
|
rapl_pmu.pmu.stop = rapl_pmu_event_stop;
|
|
|
|
rapl_pmu.pmu.read = rapl_pmu_event_read;
|
|
|
|
rapl_pmu.pmu.module = THIS_MODULE;
|
|
|
|
rapl_pmu.pmu.capabilities = PERF_PMU_CAP_NO_EXCLUDE | PERF_PMU_CAP_NO_INTERRUPT;
|
|
|
|
ret = perf_pmu_register(&rapl_pmu.pmu, "power", -1);
|
|
|
|
if (ret) {
|
|
|
|
pr_info("Failed to register PMU\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
rapl_pmu.registered = true;
|
|
|
|
end:
|
|
|
|
rp->has_pmu = true;
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int rapl_package_add_pmu(struct rapl_package *rp)
|
|
|
|
{
|
|
|
|
struct rapl_package_pmu_data *data = &rp->pmu_data;
|
|
|
|
int idx;
|
|
|
|
|
|
|
|
if (rp->has_pmu)
|
|
|
|
return -EEXIST;
|
|
|
|
|
|
|
|
guard(cpus_read_lock)();
|
|
|
|
|
|
|
|
for (idx = 0; idx < rp->nr_domains; idx++) {
|
|
|
|
struct rapl_domain *rd = &rp->domains[idx];
|
|
|
|
int domain = rd->id;
|
|
|
|
u64 val;
|
|
|
|
|
|
|
|
if (!test_bit(domain, &rp->domain_map))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The RAPL PMU granularity is 2^-32 Joules
|
|
|
|
* data->scale[]: times of 2^-32 Joules for each ENERGY COUNTER increase
|
|
|
|
*/
|
|
|
|
val = rd->energy_unit * (1ULL << 32);
|
|
|
|
do_div(val, ENERGY_UNIT_SCALE * 1000000);
|
|
|
|
data->scale[domain] = val;
|
|
|
|
|
|
|
|
if (!rapl_pmu.timer_ms) {
|
|
|
|
struct rapl_primitive_info *rpi = get_rpi(rp, ENERGY_COUNTER);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate the timer rate:
|
|
|
|
* Use reference of 200W for scaling the timeout to avoid counter
|
|
|
|
* overflows.
|
|
|
|
*
|
|
|
|
* max_count = rpi->mask >> rpi->shift + 1
|
|
|
|
* max_energy_pj = max_count * rd->energy_unit
|
|
|
|
* max_time_sec = (max_energy_pj / 1000000000) / 200w
|
|
|
|
*
|
|
|
|
* rapl_pmu.timer_ms = max_time_sec * 1000 / 2
|
|
|
|
*/
|
|
|
|
val = (rpi->mask >> rpi->shift) + 1;
|
|
|
|
val *= rd->energy_unit;
|
|
|
|
do_div(val, 1000000 * 200 * 2);
|
|
|
|
rapl_pmu.timer_ms = val;
|
|
|
|
|
|
|
|
pr_debug("%llu ms overflow timer\n", rapl_pmu.timer_ms);
|
|
|
|
}
|
|
|
|
|
|
|
|
pr_debug("Domain %s: hw unit %lld * 2^-32 Joules\n", rd->name, data->scale[domain]);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Initialize per package PMU data */
|
|
|
|
raw_spin_lock_init(&data->lock);
|
|
|
|
INIT_LIST_HEAD(&data->active_list);
|
|
|
|
data->timer_interval = ms_to_ktime(rapl_pmu.timer_ms);
|
|
|
|
hrtimer_init(&data->hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
|
|
|
|
data->hrtimer.function = rapl_hrtimer_handle;
|
|
|
|
|
|
|
|
return rapl_pmu_update(rp);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rapl_package_add_pmu);
|
|
|
|
|
|
|
|
void rapl_package_remove_pmu(struct rapl_package *rp)
|
|
|
|
{
|
|
|
|
struct rapl_package *pos;
|
|
|
|
|
|
|
|
if (!rp->has_pmu)
|
|
|
|
return;
|
|
|
|
|
|
|
|
guard(cpus_read_lock)();
|
|
|
|
|
|
|
|
list_for_each_entry(pos, &rapl_packages, plist) {
|
|
|
|
/* PMU is still needed */
|
|
|
|
if (pos->has_pmu && pos != rp)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
perf_pmu_unregister(&rapl_pmu.pmu);
|
|
|
|
memset(&rapl_pmu, 0, sizeof(struct rapl_pmu));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rapl_package_remove_pmu);
|
|
|
|
#endif
|
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* called from CPU hotplug notifier, hotplug lock held */
|
2024-01-31 11:37:09 +00:00
|
|
|
void rapl_remove_package_cpuslocked(struct rapl_package *rp)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
|
|
|
struct rapl_domain *rd, *rd_package = NULL;
|
|
|
|
|
2016-11-22 21:16:02 +00:00
|
|
|
package_power_limit_irq_restore(rp);
|
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
for (rd = rp->domains; rd < rp->domains + rp->nr_domains; rd++) {
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = POWER_LIMIT1; i < NR_POWER_LIMITS; i++) {
|
|
|
|
rapl_write_pl_data(rd, i, PL_ENABLE, 0);
|
|
|
|
rapl_write_pl_data(rd, i, PL_CLAMP, 0);
|
2016-11-22 21:16:02 +00:00
|
|
|
}
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
if (rd->id == RAPL_DOMAIN_PACKAGE) {
|
|
|
|
rd_package = rd;
|
|
|
|
continue;
|
|
|
|
}
|
2019-05-13 17:58:53 +00:00
|
|
|
pr_debug("remove package, undo power limit on %s: %s\n",
|
|
|
|
rp->name, rd->name);
|
2019-07-10 13:44:30 +00:00
|
|
|
powercap_unregister_zone(rp->priv->control_type,
|
|
|
|
&rd->power_zone);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
/* do parent zone last */
|
2019-07-10 13:44:30 +00:00
|
|
|
powercap_unregister_zone(rp->priv->control_type,
|
|
|
|
&rd_package->power_zone);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
list_del(&rp->plist);
|
|
|
|
kfree(rp);
|
|
|
|
}
|
2024-01-31 11:37:09 +00:00
|
|
|
EXPORT_SYMBOL_GPL(rapl_remove_package_cpuslocked);
|
|
|
|
|
|
|
|
void rapl_remove_package(struct rapl_package *rp)
|
|
|
|
{
|
|
|
|
guard(cpus_read_lock)();
|
|
|
|
rapl_remove_package_cpuslocked(rp);
|
|
|
|
}
|
2019-07-10 13:44:30 +00:00
|
|
|
EXPORT_SYMBOL_GPL(rapl_remove_package);
|
|
|
|
|
powercap/intel_rapl: Fix the energy-pkg event for AMD CPUs
After commit ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf"),
on AMD processors that support extended CPUID leaf 0x80000026, the
topology_logical_die_id() macros, no longer returns package id, instead it
returns the CCD (Core Complex Die) id. This leads to the energy-pkg
event scope to be modified to CCD instead of package.
For more historical context, please refer to commit 32fb480e0a2c
("powercap/intel_rapl: Support multi-die/package"), which initially changed
the RAPL scope from package to die for all systems, as Intel systems
with Die enumeration have RAPL scope as die, and those without die
enumeration are not affected. So, all systems(Intel, AMD, Hygon), worked
correctly with topology_logical_die_id() until recently, but this changed
after the "0x80000026 leaf" commit mentioned above.
Future multi-die Intel systems will have package scope RAPL counters,
but they will be using TPMI RAPL interface, which is not affected by
this change.
Replacing topology_logical_die_id() with topology_physical_package_id()
conditionally only for AMD and Hygon fixes the energy-pkg event.
On an AMD 2 socket 8 CCD Zen4 server:
Before:
linux$ ls /sys/class/powercap/
intel-rapl intel-rapl:4 intel-rapl:8:0 intel-rapl:d
intel-rapl:0 intel-rapl:4:0 intel-rapl:9 intel-rapl:d:0
intel-rapl:0:0 intel-rapl:5 intel-rapl:9:0 intel-rapl:e
intel-rapl:1 intel-rapl:5:0 intel-rapl:a intel-rapl:e:0
intel-rapl:1:0 intel-rapl:6 intel-rapl:a:0 intel-rapl:f
intel-rapl:2 intel-rapl:6:0 intel-rapl:b intel-rapl:f:0
intel-rapl:2:0 intel-rapl:7 intel-rapl:b:0
intel-rapl:3 intel-rapl:7:0 intel-rapl:c
intel-rapl:3:0 intel-rapl:8 intel-rapl:c:0
After:
linux$ ls /sys/class/powercap/
intel-rapl intel-rapl:0 intel-rapl:0:0 intel-rapl:1 intel-rapl:1:0
Only one sysfs entry per-event per-package is created after this change.
Fixes: 63edbaa48a57 ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf")
Reported-by: Michael Larabel <michael@michaellarabel.com>
Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Link: https://patch.msgid.link/20240730044917.4680-3-Dhananjay.Ugwekar@amd.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-07-30 04:49:19 +00:00
|
|
|
/*
|
|
|
|
* RAPL Package energy counter scope:
|
|
|
|
* 1. AMD/HYGON platforms use per-PKG package energy counter
|
|
|
|
* 2. For Intel platforms
|
|
|
|
* 2.1 CLX-AP platform has per-DIE package energy counter
|
|
|
|
* 2.2 Other platforms that uses MSR RAPL are single die systems so the
|
|
|
|
* package energy counter can be considered as per-PKG/per-DIE,
|
|
|
|
* here it is considered as per-DIE.
|
|
|
|
* 2.3 New platforms that use TPMI RAPL doesn't care about the
|
|
|
|
* scope because they are not MSR/CPU based.
|
|
|
|
*/
|
|
|
|
#define rapl_msrs_are_pkg_scope() \
|
|
|
|
(boot_cpu_data.x86_vendor == X86_VENDOR_AMD || \
|
|
|
|
boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
|
|
|
|
|
2019-07-10 13:44:30 +00:00
|
|
|
/* caller to ensure CPU hotplug lock is held */
|
2024-01-31 11:37:09 +00:00
|
|
|
struct rapl_package *rapl_find_package_domain_cpuslocked(int id, struct rapl_if_priv *priv,
|
|
|
|
bool id_is_cpu)
|
2019-07-10 13:44:30 +00:00
|
|
|
{
|
|
|
|
struct rapl_package *rp;
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
int uid;
|
|
|
|
|
powercap/intel_rapl: Fix the energy-pkg event for AMD CPUs
After commit ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf"),
on AMD processors that support extended CPUID leaf 0x80000026, the
topology_logical_die_id() macros, no longer returns package id, instead it
returns the CCD (Core Complex Die) id. This leads to the energy-pkg
event scope to be modified to CCD instead of package.
For more historical context, please refer to commit 32fb480e0a2c
("powercap/intel_rapl: Support multi-die/package"), which initially changed
the RAPL scope from package to die for all systems, as Intel systems
with Die enumeration have RAPL scope as die, and those without die
enumeration are not affected. So, all systems(Intel, AMD, Hygon), worked
correctly with topology_logical_die_id() until recently, but this changed
after the "0x80000026 leaf" commit mentioned above.
Future multi-die Intel systems will have package scope RAPL counters,
but they will be using TPMI RAPL interface, which is not affected by
this change.
Replacing topology_logical_die_id() with topology_physical_package_id()
conditionally only for AMD and Hygon fixes the energy-pkg event.
On an AMD 2 socket 8 CCD Zen4 server:
Before:
linux$ ls /sys/class/powercap/
intel-rapl intel-rapl:4 intel-rapl:8:0 intel-rapl:d
intel-rapl:0 intel-rapl:4:0 intel-rapl:9 intel-rapl:d:0
intel-rapl:0:0 intel-rapl:5 intel-rapl:9:0 intel-rapl:e
intel-rapl:1 intel-rapl:5:0 intel-rapl:a intel-rapl:e:0
intel-rapl:1:0 intel-rapl:6 intel-rapl:a:0 intel-rapl:f
intel-rapl:2 intel-rapl:6:0 intel-rapl:b intel-rapl:f:0
intel-rapl:2:0 intel-rapl:7 intel-rapl:b:0
intel-rapl:3 intel-rapl:7:0 intel-rapl:c
intel-rapl:3:0 intel-rapl:8 intel-rapl:c:0
After:
linux$ ls /sys/class/powercap/
intel-rapl intel-rapl:0 intel-rapl:0:0 intel-rapl:1 intel-rapl:1:0
Only one sysfs entry per-event per-package is created after this change.
Fixes: 63edbaa48a57 ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf")
Reported-by: Michael Larabel <michael@michaellarabel.com>
Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Link: https://patch.msgid.link/20240730044917.4680-3-Dhananjay.Ugwekar@amd.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-07-30 04:49:19 +00:00
|
|
|
if (id_is_cpu) {
|
|
|
|
uid = rapl_msrs_are_pkg_scope() ?
|
|
|
|
topology_physical_package_id(id) : topology_logical_die_id(id);
|
|
|
|
if (uid < 0) {
|
|
|
|
pr_err("topology_logical_(package/die)_id() returned a negative value");
|
2024-08-23 12:51:36 +00:00
|
|
|
return NULL;
|
powercap/intel_rapl: Fix the energy-pkg event for AMD CPUs
After commit ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf"),
on AMD processors that support extended CPUID leaf 0x80000026, the
topology_logical_die_id() macros, no longer returns package id, instead it
returns the CCD (Core Complex Die) id. This leads to the energy-pkg
event scope to be modified to CCD instead of package.
For more historical context, please refer to commit 32fb480e0a2c
("powercap/intel_rapl: Support multi-die/package"), which initially changed
the RAPL scope from package to die for all systems, as Intel systems
with Die enumeration have RAPL scope as die, and those without die
enumeration are not affected. So, all systems(Intel, AMD, Hygon), worked
correctly with topology_logical_die_id() until recently, but this changed
after the "0x80000026 leaf" commit mentioned above.
Future multi-die Intel systems will have package scope RAPL counters,
but they will be using TPMI RAPL interface, which is not affected by
this change.
Replacing topology_logical_die_id() with topology_physical_package_id()
conditionally only for AMD and Hygon fixes the energy-pkg event.
On an AMD 2 socket 8 CCD Zen4 server:
Before:
linux$ ls /sys/class/powercap/
intel-rapl intel-rapl:4 intel-rapl:8:0 intel-rapl:d
intel-rapl:0 intel-rapl:4:0 intel-rapl:9 intel-rapl:d:0
intel-rapl:0:0 intel-rapl:5 intel-rapl:9:0 intel-rapl:e
intel-rapl:1 intel-rapl:5:0 intel-rapl:a intel-rapl:e:0
intel-rapl:1:0 intel-rapl:6 intel-rapl:a:0 intel-rapl:f
intel-rapl:2 intel-rapl:6:0 intel-rapl:b intel-rapl:f:0
intel-rapl:2:0 intel-rapl:7 intel-rapl:b:0
intel-rapl:3 intel-rapl:7:0 intel-rapl:c
intel-rapl:3:0 intel-rapl:8 intel-rapl:c:0
After:
linux$ ls /sys/class/powercap/
intel-rapl intel-rapl:0 intel-rapl:0:0 intel-rapl:1 intel-rapl:1:0
Only one sysfs entry per-event per-package is created after this change.
Fixes: 63edbaa48a57 ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf")
Reported-by: Michael Larabel <michael@michaellarabel.com>
Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Link: https://patch.msgid.link/20240730044917.4680-3-Dhananjay.Ugwekar@amd.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-07-30 04:49:19 +00:00
|
|
|
}
|
|
|
|
}
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
else
|
|
|
|
uid = id;
|
2019-07-10 13:44:30 +00:00
|
|
|
|
|
|
|
list_for_each_entry(rp, &rapl_packages, plist) {
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
if (rp->id == uid
|
2019-07-10 13:44:30 +00:00
|
|
|
&& rp->priv->control_type == priv->control_type)
|
|
|
|
return rp;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
2024-01-31 11:37:09 +00:00
|
|
|
EXPORT_SYMBOL_GPL(rapl_find_package_domain_cpuslocked);
|
|
|
|
|
|
|
|
struct rapl_package *rapl_find_package_domain(int id, struct rapl_if_priv *priv, bool id_is_cpu)
|
|
|
|
{
|
|
|
|
guard(cpus_read_lock)();
|
|
|
|
return rapl_find_package_domain_cpuslocked(id, priv, id_is_cpu);
|
|
|
|
}
|
2019-07-10 13:44:30 +00:00
|
|
|
EXPORT_SYMBOL_GPL(rapl_find_package_domain);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
/* called from CPU hotplug notifier, hotplug lock held */
|
2024-01-31 11:37:09 +00:00
|
|
|
struct rapl_package *rapl_add_package_cpuslocked(int id, struct rapl_if_priv *priv, bool id_is_cpu)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
|
|
|
struct rapl_package *rp;
|
2016-11-22 21:16:05 +00:00
|
|
|
int ret;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
|
|
|
rp = kzalloc(sizeof(struct rapl_package), GFP_KERNEL);
|
|
|
|
if (!rp)
|
2016-11-22 21:16:05 +00:00
|
|
|
return ERR_PTR(-ENOMEM);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
if (id_is_cpu) {
|
powercap/intel_rapl: Fix the energy-pkg event for AMD CPUs
After commit ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf"),
on AMD processors that support extended CPUID leaf 0x80000026, the
topology_logical_die_id() macros, no longer returns package id, instead it
returns the CCD (Core Complex Die) id. This leads to the energy-pkg
event scope to be modified to CCD instead of package.
For more historical context, please refer to commit 32fb480e0a2c
("powercap/intel_rapl: Support multi-die/package"), which initially changed
the RAPL scope from package to die for all systems, as Intel systems
with Die enumeration have RAPL scope as die, and those without die
enumeration are not affected. So, all systems(Intel, AMD, Hygon), worked
correctly with topology_logical_die_id() until recently, but this changed
after the "0x80000026 leaf" commit mentioned above.
Future multi-die Intel systems will have package scope RAPL counters,
but they will be using TPMI RAPL interface, which is not affected by
this change.
Replacing topology_logical_die_id() with topology_physical_package_id()
conditionally only for AMD and Hygon fixes the energy-pkg event.
On an AMD 2 socket 8 CCD Zen4 server:
Before:
linux$ ls /sys/class/powercap/
intel-rapl intel-rapl:4 intel-rapl:8:0 intel-rapl:d
intel-rapl:0 intel-rapl:4:0 intel-rapl:9 intel-rapl:d:0
intel-rapl:0:0 intel-rapl:5 intel-rapl:9:0 intel-rapl:e
intel-rapl:1 intel-rapl:5:0 intel-rapl:a intel-rapl:e:0
intel-rapl:1:0 intel-rapl:6 intel-rapl:a:0 intel-rapl:f
intel-rapl:2 intel-rapl:6:0 intel-rapl:b intel-rapl:f:0
intel-rapl:2:0 intel-rapl:7 intel-rapl:b:0
intel-rapl:3 intel-rapl:7:0 intel-rapl:c
intel-rapl:3:0 intel-rapl:8 intel-rapl:c:0
After:
linux$ ls /sys/class/powercap/
intel-rapl intel-rapl:0 intel-rapl:0:0 intel-rapl:1 intel-rapl:1:0
Only one sysfs entry per-event per-package is created after this change.
Fixes: 63edbaa48a57 ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf")
Reported-by: Michael Larabel <michael@michaellarabel.com>
Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Link: https://patch.msgid.link/20240730044917.4680-3-Dhananjay.Ugwekar@amd.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-07-30 04:49:19 +00:00
|
|
|
rp->id = rapl_msrs_are_pkg_scope() ?
|
|
|
|
topology_physical_package_id(id) : topology_logical_die_id(id);
|
|
|
|
if ((int)(rp->id) < 0) {
|
|
|
|
pr_err("topology_logical_(package/die)_id() returned a negative value");
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
rp->lead_cpu = id;
|
powercap/intel_rapl: Fix the energy-pkg event for AMD CPUs
After commit ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf"),
on AMD processors that support extended CPUID leaf 0x80000026, the
topology_logical_die_id() macros, no longer returns package id, instead it
returns the CCD (Core Complex Die) id. This leads to the energy-pkg
event scope to be modified to CCD instead of package.
For more historical context, please refer to commit 32fb480e0a2c
("powercap/intel_rapl: Support multi-die/package"), which initially changed
the RAPL scope from package to die for all systems, as Intel systems
with Die enumeration have RAPL scope as die, and those without die
enumeration are not affected. So, all systems(Intel, AMD, Hygon), worked
correctly with topology_logical_die_id() until recently, but this changed
after the "0x80000026 leaf" commit mentioned above.
Future multi-die Intel systems will have package scope RAPL counters,
but they will be using TPMI RAPL interface, which is not affected by
this change.
Replacing topology_logical_die_id() with topology_physical_package_id()
conditionally only for AMD and Hygon fixes the energy-pkg event.
On an AMD 2 socket 8 CCD Zen4 server:
Before:
linux$ ls /sys/class/powercap/
intel-rapl intel-rapl:4 intel-rapl:8:0 intel-rapl:d
intel-rapl:0 intel-rapl:4:0 intel-rapl:9 intel-rapl:d:0
intel-rapl:0:0 intel-rapl:5 intel-rapl:9:0 intel-rapl:e
intel-rapl:1 intel-rapl:5:0 intel-rapl:a intel-rapl:e:0
intel-rapl:1:0 intel-rapl:6 intel-rapl:a:0 intel-rapl:f
intel-rapl:2 intel-rapl:6:0 intel-rapl:b intel-rapl:f:0
intel-rapl:2:0 intel-rapl:7 intel-rapl:b:0
intel-rapl:3 intel-rapl:7:0 intel-rapl:c
intel-rapl:3:0 intel-rapl:8 intel-rapl:c:0
After:
linux$ ls /sys/class/powercap/
intel-rapl intel-rapl:0 intel-rapl:0:0 intel-rapl:1 intel-rapl:1:0
Only one sysfs entry per-event per-package is created after this change.
Fixes: 63edbaa48a57 ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf")
Reported-by: Michael Larabel <michael@michaellarabel.com>
Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Link: https://patch.msgid.link/20240730044917.4680-3-Dhananjay.Ugwekar@amd.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-07-30 04:49:19 +00:00
|
|
|
if (!rapl_msrs_are_pkg_scope() && topology_max_dies_per_package() > 1)
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
snprintf(rp->name, PACKAGE_DOMAIN_NAME_LENGTH, "package-%d-die-%d",
|
|
|
|
topology_physical_package_id(id), topology_die_id(id));
|
|
|
|
else
|
|
|
|
snprintf(rp->name, PACKAGE_DOMAIN_NAME_LENGTH, "package-%d",
|
|
|
|
topology_physical_package_id(id));
|
|
|
|
} else {
|
|
|
|
rp->id = id;
|
|
|
|
rp->lead_cpu = -1;
|
|
|
|
snprintf(rp->name, PACKAGE_DOMAIN_NAME_LENGTH, "package-%d", id);
|
|
|
|
}
|
2016-02-24 21:31:38 +00:00
|
|
|
|
powercap: intel_rapl: Make cpu optional for rapl_package
MSR RAPL Interface always removes a rapl_package when all the CPUs in
that rapl_package are offlined. This is because it relies on an online
CPU to access the MSR.
But for RAPL Interface using MMIO registers, when all the cpus within
the rapl_package are offlined,
1. the register can still be accessed
2. monitoring and setting the Power Pimits for the rapl_package is still
meaningful because of uncore power.
This means that, a valid rapl_package doesn't rely on one or more cpus
being onlined.
For this sense, make cpu optional for rapl_package. A rapl_package can
be registered either using a CPU id to represent the physical
package/die, or using the physical package id directly.
Note that, the thermal throttling interrupt is not disabled via
MSR_IA32_PACKAGE_THERM_INTERRUPT for such rapl_package at the moment.
If it is still needed in the future, this can be achieved by selecting
an onlined CPU using the physical package id.
Note that, processor_thermal_rapl, the current MMIO RAPL Interface
driver, can also be converted to register using a package id instead.
But this is not done right now because processor_thermal_rapl driver
works on single-package systems only, and offlining the only package
will not happen. So keep the previous logic.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:16 +00:00
|
|
|
rp->priv = priv;
|
2023-04-19 02:44:07 +00:00
|
|
|
ret = rapl_config(rp);
|
|
|
|
if (ret)
|
|
|
|
goto err_free_package;
|
|
|
|
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
/* check if the package contains valid domains */
|
2023-04-19 02:44:15 +00:00
|
|
|
if (rapl_detect_domains(rp)) {
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
ret = -ENODEV;
|
|
|
|
goto err_free_package;
|
|
|
|
}
|
2016-11-22 21:15:59 +00:00
|
|
|
ret = rapl_package_register_powercap(rp);
|
|
|
|
if (!ret) {
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
INIT_LIST_HEAD(&rp->plist);
|
|
|
|
list_add(&rp->plist, &rapl_packages);
|
2016-11-22 21:16:05 +00:00
|
|
|
return rp;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
err_free_package:
|
|
|
|
kfree(rp->domains);
|
|
|
|
kfree(rp);
|
2016-11-22 21:16:05 +00:00
|
|
|
return ERR_PTR(ret);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
2024-01-31 11:37:09 +00:00
|
|
|
EXPORT_SYMBOL_GPL(rapl_add_package_cpuslocked);
|
|
|
|
|
|
|
|
struct rapl_package *rapl_add_package(int id, struct rapl_if_priv *priv, bool id_is_cpu)
|
|
|
|
{
|
|
|
|
guard(cpus_read_lock)();
|
|
|
|
return rapl_add_package_cpuslocked(id, priv, id_is_cpu);
|
|
|
|
}
|
2019-07-10 13:44:30 +00:00
|
|
|
EXPORT_SYMBOL_GPL(rapl_add_package);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2018-01-10 00:38:23 +00:00
|
|
|
static void power_limit_state_save(void)
|
|
|
|
{
|
|
|
|
struct rapl_package *rp;
|
|
|
|
struct rapl_domain *rd;
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
int ret, i;
|
2018-01-10 00:38:23 +00:00
|
|
|
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_lock();
|
2018-01-10 00:38:23 +00:00
|
|
|
list_for_each_entry(rp, &rapl_packages, plist) {
|
|
|
|
if (!rp->power_zone)
|
|
|
|
continue;
|
|
|
|
rd = power_zone_to_rapl_domain(rp->power_zone);
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
for (i = POWER_LIMIT1; i < NR_POWER_LIMITS; i++) {
|
|
|
|
ret = rapl_read_pl_data(rd, i, PL_LIMIT, true,
|
2019-07-10 13:44:30 +00:00
|
|
|
&rd->rpl[i].last_power_limit);
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
if (ret)
|
|
|
|
rd->rpl[i].last_power_limit = 0;
|
2018-01-10 00:38:23 +00:00
|
|
|
}
|
|
|
|
}
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_unlock();
|
2018-01-10 00:38:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void power_limit_state_restore(void)
|
|
|
|
{
|
|
|
|
struct rapl_package *rp;
|
|
|
|
struct rapl_domain *rd;
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
int i;
|
2018-01-10 00:38:23 +00:00
|
|
|
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_lock();
|
2018-01-10 00:38:23 +00:00
|
|
|
list_for_each_entry(rp, &rapl_packages, plist) {
|
|
|
|
if (!rp->power_zone)
|
|
|
|
continue;
|
|
|
|
rd = power_zone_to_rapl_domain(rp->power_zone);
|
powercap: intel_rapl: Cleanup Power Limits support
The same set of operations are shared by different Powert Limits,
including Power Limit get/set, Power Limit enable/disable, clamping
enable/disable, time window get/set, and max power get/set, etc.
But the same operation for different Power Limit has different
primitives because they use different registers/register bits.
A lot of dirty/duplicate code was introduced to handle this difference.
Introduce a universal way to issue Power Limit operations.
Instead of using hardcoded primitive name directly, use Power Limit id
+ operation type, and hide all the Power Limit difference details in a
central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
rapl_write_pl_data(), are introduced at the same time to simplify the
code for issuing Power Limit operations.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Wang Wendy <wendy.wang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-04-19 02:44:13 +00:00
|
|
|
for (i = POWER_LIMIT1; i < NR_POWER_LIMITS; i++)
|
|
|
|
if (rd->rpl[i].last_power_limit)
|
|
|
|
rapl_write_pl_data(rd, i, PL_LIMIT,
|
|
|
|
rd->rpl[i].last_power_limit);
|
2018-01-10 00:38:23 +00:00
|
|
|
}
|
2021-08-03 14:16:01 +00:00
|
|
|
cpus_read_unlock();
|
2018-01-10 00:38:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int rapl_pm_callback(struct notifier_block *nb,
|
2019-07-10 13:44:30 +00:00
|
|
|
unsigned long mode, void *_unused)
|
2018-01-10 00:38:23 +00:00
|
|
|
{
|
|
|
|
switch (mode) {
|
|
|
|
case PM_SUSPEND_PREPARE:
|
|
|
|
power_limit_state_save();
|
|
|
|
break;
|
|
|
|
case PM_POST_SUSPEND:
|
|
|
|
power_limit_state_restore();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return NOTIFY_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct notifier_block rapl_pm_notifier = {
|
|
|
|
.notifier_call = rapl_pm_callback,
|
|
|
|
};
|
|
|
|
|
2019-07-10 13:44:34 +00:00
|
|
|
static struct platform_device *rapl_msr_platdev;
|
|
|
|
|
|
|
|
static int __init rapl_init(void)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
2014-11-07 17:29:25 +00:00
|
|
|
const struct x86_cpu_id *id;
|
2016-11-22 21:16:02 +00:00
|
|
|
int ret;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2014-11-07 17:29:25 +00:00
|
|
|
id = x86_match_cpu(rapl_ids);
|
2023-04-19 02:44:06 +00:00
|
|
|
if (id) {
|
2023-04-19 02:44:17 +00:00
|
|
|
defaults_msr = (struct rapl_defaults *)id->driver_data;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
|
2023-04-19 02:44:06 +00:00
|
|
|
rapl_msr_platdev = platform_device_alloc("intel_rapl_msr", 0);
|
|
|
|
if (!rapl_msr_platdev)
|
|
|
|
return -ENOMEM;
|
2018-01-10 00:38:23 +00:00
|
|
|
|
2023-04-19 02:44:06 +00:00
|
|
|
ret = platform_device_add(rapl_msr_platdev);
|
|
|
|
if (ret) {
|
|
|
|
platform_device_put(rapl_msr_platdev);
|
|
|
|
return ret;
|
|
|
|
}
|
2019-07-10 13:44:34 +00:00
|
|
|
}
|
|
|
|
|
2023-04-19 02:44:06 +00:00
|
|
|
ret = register_pm_notifier(&rapl_pm_notifier);
|
|
|
|
if (ret && rapl_msr_platdev) {
|
|
|
|
platform_device_del(rapl_msr_platdev);
|
2019-07-10 13:44:34 +00:00
|
|
|
platform_device_put(rapl_msr_platdev);
|
2023-04-19 02:44:06 +00:00
|
|
|
}
|
2019-07-10 13:44:34 +00:00
|
|
|
|
|
|
|
return ret;
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
|
2019-07-10 13:44:34 +00:00
|
|
|
static void __exit rapl_exit(void)
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
{
|
2019-07-10 13:44:34 +00:00
|
|
|
platform_device_unregister(rapl_msr_platdev);
|
2018-01-10 00:38:23 +00:00
|
|
|
unregister_pm_notifier(&rapl_pm_notifier);
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
}
|
|
|
|
|
2019-07-19 15:25:14 +00:00
|
|
|
fs_initcall(rapl_init);
|
2019-07-10 13:44:34 +00:00
|
|
|
module_exit(rapl_exit);
|
|
|
|
|
2019-07-10 13:44:30 +00:00
|
|
|
MODULE_DESCRIPTION("Intel Runtime Average Power Limit (RAPL) common code");
|
PowerCap: Introduce Intel RAPL power capping driver
The Intel Running Average Power Limit (RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied. In RAPL,
power control is divided into domains, which include package, DRAM
controller, CPU core (Power Plane 0), graphics uncore (power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in that platform
level power capping controls are exposed via this generic interface.
This driver is based on an earlier patch from Zhang Rui.
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
References: https://lkml.org/lkml/2011/5/26/93
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 17:28:35 +00:00
|
|
|
MODULE_AUTHOR("Jacob Pan <jacob.jun.pan@intel.com>");
|
|
|
|
MODULE_LICENSE("GPL v2");
|