| 7b3ffe0d | 17-Jun-2024 |
Tero Kristo <[email protected]> |
platform/x86/intel-uncore-freq: Use generic helpers for current frequency
Use the generic sysfs helpers for reading the current frequency also, and remove the custom ones.
No functional change inte
platform/x86/intel-uncore-freq: Use generic helpers for current frequency
Use the generic sysfs helpers for reading the current frequency also, and remove the custom ones.
No functional change intended.
Signed-off-by: Tero Kristo <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
show more ...
|
| b2cc9f90 | 17-Jun-2024 |
Tero Kristo <[email protected]> |
platform/x86/intel-uncore-freq: Rename the sysfs helper macro names
The macros to create sysfs entries are going to be used for other attributes in addition to current min/max frequencies only, so r
platform/x86/intel-uncore-freq: Rename the sysfs helper macro names
The macros to create sysfs entries are going to be used for other attributes in addition to current min/max frequencies only, so rename these to be more generic.
No functional change intended.
Signed-off-by: Tero Kristo <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
show more ...
|
| d766abfb | 17-Jun-2024 |
Tero Kristo <[email protected]> |
platform/x86/intel-uncore-freq: Get rid of uncore_read_freq driver API
Get rid of uncore_read_freq driver API. Instead, add a new entry to the enumerated read interface and use this.
No functional
platform/x86/intel-uncore-freq: Get rid of uncore_read_freq driver API
Get rid of uncore_read_freq driver API. Instead, add a new entry to the enumerated read interface and use this.
No functional change intended.
Signed-off-by: Tero Kristo <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
show more ...
|
| 69207a0f | 17-Jun-2024 |
Tero Kristo <[email protected]> |
platform/x86/intel-uncore-freq: Use uncore_index with read_control_freq
Use the enumerated index for selecting the uncore driver parameter to read, instead of reading everything. This is done in pre
platform/x86/intel-uncore-freq: Use uncore_index with read_control_freq
Use the enumerated index for selecting the uncore driver parameter to read, instead of reading everything. This is done in preparation to expand the API to access more parameters later.
No functional change intended.
Signed-off-by: Tero Kristo <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ij: Removed underscores from variable names] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
show more ...
|
| 90583374 | 17-Jun-2024 |
Tero Kristo <[email protected]> |
platform/x86/intel-uncore-freq: Get rid of magic min_max argument
Get rid of the hardcoded / magic min_max argument from internal APIs. Instead, use an enumerated index value for it.
No functional
platform/x86/intel-uncore-freq: Get rid of magic min_max argument
Get rid of the hardcoded / magic min_max argument from internal APIs. Instead, use an enumerated index value for it.
No functional change intended.
Signed-off-by: Tero Kristo <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
show more ...
|
| 4babdbdc | 17-Jun-2024 |
Tero Kristo <[email protected]> |
platform/x86/intel-uncore-freq: Get rid of magic values
Get rid of any magic bitmasks from the code. Define proper macros for these, and use the bitfield operations to access them.
No functional ch
platform/x86/intel-uncore-freq: Get rid of magic values
Get rid of any magic bitmasks from the code. Define proper macros for these, and use the bitfield operations to access them.
No functional change intended.
Signed-off-by: Tero Kristo <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
show more ...
|
| 01c10f88 | 18-Apr-2023 |
Srinivas Pandruvada <[email protected]> |
platform/x86/intel-uncore-freq: tpmi: Provide cluster level control
The new generation of CPUs have granular control at a cluster level. Each package/die can have multiple power domains, which furth
platform/x86/intel-uncore-freq: tpmi: Provide cluster level control
The new generation of CPUs have granular control at a cluster level. Each package/die can have multiple power domains, which further can have multiple fabric clusters. The TPMI interface allows control at fabric cluster level.
Use the updated uncore sysfs feature to expose controls at cluster level. At each cluster level there is a control for maximum and minimum uncore frequency. Also present current uncore frequency at a cluster level.
Signed-off-by: Srinivas Pandruvada <[email protected]> Reviewed-by: Zhang Rui <[email protected]> Tested-by: Wendy Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
show more ...
|
| 9b8dea80 | 18-Apr-2023 |
Srinivas Pandruvada <[email protected]> |
platform/x86/intel-uncore-freq: Support for cluster level controls
An SoC can contain multiple power domains with individual or collection of mesh partitions. This partition is called fabric cluster
platform/x86/intel-uncore-freq: Support for cluster level controls
An SoC can contain multiple power domains with individual or collection of mesh partitions. This partition is called fabric cluster.
Certain type of meshes will need to run at the same frequency, they will be placed in the same fabric cluster. Benefit of fabric cluster is that it offers a scalable mechanism to deal with partitioned fabrics in a SoC.
The current sysfs interface supports control at package and die level. This interface is not enough to support more granular control at fabric cluster level.
SoCs with the support of TPMI (Topology Aware Register and PM Capsule Interface), can have multiple power domains. Each power domain can contain one or more fabric clusters.
To support such granular controls, enhance uncore common to optionally create new directories to provide controls at fabric cluster level. It is also important to have flexibility to change granularity for future version of SoCs. If the directory name contains scope like: "package_*_die_*_power_domain_*_cluster_*", then this is not expandable.
The cpufreq policies also have different scopes. There the scope of the policy (affected_cpus) specified by attributes inside each policy. So, follow the same model for uncore frequency scaling sysfs as: "sys/devices/system/cpu/cpufreq/policy*"
Allow client drivers to optionally support granular control for each fabric cluster. Here, the directory name will be "uncore" suffixed with an unique instance number. For example: uncore00, uncore01 etc. Attributes in the directory identify package id, power domain and fabric cluster id. This interface is expandable even if some new level of granularity is introduced. A new sysfs attribute can identify new level.
For compatibility with the existing sysfs and provide easy way to set limits for each fabric cluster in the package/die, the existing control at package/die levels are still provided. For majority of users, this is an easy approach.
For example: On a single package/die system, with three power domains and one fabric cluster per power domain:
$tree -L 2 /sys/devices/system/cpu/intel_uncore_frequency/ /sys/devices/system/cpu/intel_uncore_frequency/ ├── package_00_die_00 │ ├── current_freq_khz │ ├── initial_max_freq_khz │ ├── initial_min_freq_khz │ ├── max_freq_khz │ └── min_freq_khz ├── uncore00 │ ├── current_freq_khz │ ├── domain_id │ ├── fabric_cluster_id │ ├── initial_max_freq_khz │ ├── initial_min_freq_khz │ ├── max_freq_khz │ ├── min_freq_khz │ └── package_id ├── uncore01 │ ├── current_freq_khz │ ├── domain_id │ ├── fabric_cluster_id │ ├── initial_max_freq_khz │ ├── initial_min_freq_khz │ ├── max_freq_khz │ ├── min_freq_khz │ └── package_id └── uncore02 ├── current_freq_khz ├── domain_id ├── fabric_cluster_id ├── initial_max_freq_khz ├── initial_min_freq_khz ├── max_freq_khz ├── min_freq_khz └── package_id
The attribute for cluster id is "fabric_cluster_id" instead of just "cluster_id" is to avoid confusion with usage of term clusters in other part of the Linux kernel.
Signed-off-by: Srinivas Pandruvada <[email protected]> Reviewed-by: Zhang Rui <[email protected]> Tested-by: Wendy Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
show more ...
|
| 8a54e225 | 20-Apr-2023 |
Srinivas Pandruvada <[email protected]> |
platform/x86/intel-uncore-freq: Uncore frequency control via TPMI
Implement support of uncore frequency control via TPMI (Topology Aware Register and PM Capsule Interface). This driver provides the
platform/x86/intel-uncore-freq: Uncore frequency control via TPMI
Implement support of uncore frequency control via TPMI (Topology Aware Register and PM Capsule Interface). This driver provides the similar functionality as the current uncore frequency driver using MSRs.
The hardware interface to read/write is basically substitution of MSR 0x620 and 0x621. There are specific MMIO offset and bits to get/set minimum and maximum uncore ratio, similar to MSRs.
The scope of the uncore MSRs is package/die. But new generation of CPUs have more granular control at a cluster level. Each package/die can have multiple power domains, which further can have multiple clusters. The TPMI interface allows control at cluster level.
The primary use case for uncore sysfs is to set maximum and minimum uncore frequency to reduce power consumption or latency. The current uncore sysfs control is per package/die. This is enough for the majority of users as workload will move to different power domains as it moves between different CPUs.
The current uncore sysfs provides controls at package/die level. When user sets maximum/minimum limits, the driver sets the same limits to each cluster.
Here number of power domains = number of resources in this aux device. There are offsets and bits to discover number of clusters and offset for each cluster level controls.
The TPMI documentation can be downloaded from: https://github.com/intel/tpmi_power_management
Signed-off-by: Srinivas Pandruvada <[email protected]> Reviewed-by: Zhang Rui <[email protected]> Tested-by: Wendy Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
show more ...
|