linux-toradex.git/drivers/thermal/intel/intel_hfi.c, branch v6.13-rc7

thermal: intel: hfi: Give HFI instances package scope

2024-07-09T16:29:07+00:00

The Intel Software Developer's Manual defines the scope of HFI (registers
and memory buffer) as a package. Use package scope(*) in the software
representation of an HFI instance.

Using die scope in HFI instances has the effect of creating multiple
conflicting instances for the same package: each instance allocates its
own memory buffer and configures the same package-level registers.
Specifically, only one of the allocated memory buffers can be set in the
MSR_IA32_HW_FEEDBACK_PTR register. CPUs get incorrect HFI data from the
table.

The problem does not affect current HFI-capable platforms because they
all have single-die processors.

(*) We used die scope for HFI instances because there had been
    processors with packages enumerated as dies. None of those systems
    supported HFI, though. If such a system emerged, it would need to
    be quirked.

Co-developed-by: Chen Yu 
Signed-off-by: Chen Yu 
Signed-off-by: Zhang Rui 
Reviewed-by: Ricardo Neri 
Link: https://patch.msgid.link/20240703055445.125362-1-rui.zhang@intel.com
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: Increase the number of CPU capabilities per netlink event

2024-05-08T12:02:02+00:00

The number of updated CPU capabilities per netlink event is hard-coded to
16. On systems with more than 16 CPUs (a common case), it takes more than
one thermal netlink event to relay all the new capabilities after an HFI
interrupt. This adds unnecessary overhead to both the kernel and user space
entities.

Increase the number of CPU capabilities updated per event to 64. Any system
with 64 CPUs or less can now update all the capabilities in a single
thermal netlink event.

Signed-off-by: Ricardo Neri 
Acked-by: Zhang Rui 
Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: Rename HFI_MAX_THERM_NOTIFY_COUNT

2024-05-08T12:02:02+00:00

When processing a hardware update, HFI generates as many thermal netlink
events as needed to relay all the updated CPU capabilities to user space.
The constant HFI_MAX_THERM_NOTIFY_COUNT is the number of CPU capabilities
updated per each of those events.

Give this constant a more descriptive name.

Signed-off-by: Ricardo Neri 
Acked-by: Zhang Rui 
Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: Shorten the thermal netlink event delay to 100ms

2024-05-08T12:02:02+00:00

The delay between an HFI interrupt and its corresponding thermal netlink
event has so far been hard-coded to CONFIG_HZ jiffies (1 second). This
delay is too long for hardware that generates updates every tens of
milliseconds.

The HFI driver uses a delayed workqueue to send thermal netlink events. No
subsequent events will be sent if there is pending work.

As a result, much of the information of consecutive hardware updates will
be lost if the workqueue delay is too long. User space entities may act on
obsolete data. If the delay is too short, multiple events may overwhelm
listeners.

Set the delay to 100ms to strike a balance between too many and too few
events. Use milliseconds instead of jiffies to improve readability.

Signed-off-by: Ricardo Neri 
Acked-by: Zhang Rui 
Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: Rename HFI_UPDATE_INTERVAL

2024-05-08T12:02:02+00:00

The name of the constant HFI_UPDATE_INTERVAL is misleading. It is not a
periodic interval at which HFI updates are processed. It is the delay in
the processing of an HFI update after the arrival of an HFI interrupt.

Acked-by: Zhang Rui 
Signed-off-by: Ricardo Neri 
Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: Enable HFI only when required

2024-03-27T13:50:26+00:00

Enable and disable hardware feedback interface (HFI) when user space
handler is present. For example, enable HFI, when intel-speed-select or
Intel Low Power daemon is running and subscribing to thermal netlink
events. When user space handlers exit or remove subscription for
thermal netlink events, disable HFI.

Summary of changes:

 - Register a thermal genetlink notifier

 - In the notifier, process THERMAL_NOTIFY_BIND and THERMAL_NOTIFY_UNBIND
   reason codes to count number of thermal event group netlink multicast
   clients. If thermal netlink group has any listener enable HFI on all
   packages. If there are no listener disable HFI on all packages.

- When CPU is online, instead of blindly enabling HFI, check if
  the thermal netlink group has any listener. This will make sure that
  HFI is not enabled by default during boot time.

- Actual processing to enable/disable matches what is done in
  suspend/resume callbacks. Create two functions hfi_enable_instance()
  and hfi_disable_instance(), which can be called from the netlink
  notifier callback and suspend/resume callbacks.

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: Rafael J. Wysocki

x86/cpu/topology: Rename topology_max_die_per_package()

2024-02-15T21:07:45+00:00

The plural of die is dies.

Signed-off-by: Thomas Gleixner 
Tested-by: Michael Kelley 
Tested-by: Sohil Mehta 
Link: https://lore.kernel.org/r/20240213210253.065874205@linutronix.de

thermal: intel: hfi: Add syscore callbacks for system-wide PM

2024-01-12T14:44:42+00:00

The kernel allocates a memory buffer and provides its location to the
hardware, which uses it to update the HFI table. This allocation occurs
during boot and remains constant throughout runtime.

When resuming from hibernation, the restore kernel allocates a second
memory buffer and reprograms the HFI hardware with the new location as
part of a normal boot. The location of the second memory buffer may
differ from the one allocated by the image kernel.

When the restore kernel transfers control to the image kernel, its HFI
buffer becomes invalid, potentially leading to memory corruption if the
hardware writes to it (the hardware continues to use the buffer from the
restore kernel).

It is also possible that the hardware "forgets" the address of the memory
buffer when resuming from "deep" suspend. Memory corruption may also occur
in such a scenario.

To prevent the described memory corruption, disable HFI when preparing to
suspend or hibernate. Enable it when resuming.

Add syscore callbacks to handle the package of the boot CPU (packages of
non-boot CPUs are handled via CPU offline). Syscore ops always run on the
boot CPU. Additionally, HFI only needs to be disabled during "deep" suspend
and hibernation. Syscore ops only run in these cases.

Cc: 6.1+  # 6.1+
Signed-off-by: Ricardo Neri 
[ rjw: Comment adjustment, subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: Disable an HFI instance when all its CPUs go offline

2024-01-03T13:06:40+00:00

In preparation to support hibernation, add functionality to disable an HFI
instance during CPU offline. The last CPU of an instance that goes offline
will disable such instance.

The Intel Software Development Manual states that the operating system must
wait for the hardware to set MSR_IA32_PACKAGE_THERM_STATUS[26] after
disabling an HFI instance to ensure that it will no longer write on the HFI
memory. Some processors, however, do not ever set such bit. Wait a minimum
of 2ms to give time hardware to complete any pending memory writes.

Signed-off-by: Ricardo Neri 
Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: Enable an HFI instance from its first online CPU

2024-01-03T13:06:40+00:00

Previously, HFI instances were never disabled once enabled. A CPU in an
instance only had to check during boot whether another CPU had previously
initialized the instance and its corresponding data structure.

A subsequent changeset will add functionality to disable instances
to support hibernation. Such change will also make possible to disable an
HFI instance during runtime via CPU hotplug.

Enable an HFI instance from the first of its CPUs that comes online. This
covers the boot, CPU hotplug, and resume-from-suspend cases. It also covers
systems with one or more HFI instances (i.e., packages).

Signed-off-by: Ricardo Neri 
Signed-off-by: Rafael J. Wysocki