thermal: int340x: processor_thermal: Support power floor notifications

When the hardware reduces the power to the minimum possible, the power
floor is notified via an interrupt.

This can happen whe

thermal: int340x: processor_thermal: Support power floor notifications

When the hardware reduces the power to the minimum possible, the power
floor is notified via an interrupt.

This can happen when user space requests a power limit via powercap RAPL
interface, which forces the system to enter to the lowest power. This
power floor indication can be used as a hint to resort to other methods
of reducing power than via RAPL power limit.

Before power floor status can be read or the firmware can trigger
notifications regarding it, it needs to be configured via a mailbox
command. The actual power floor status is read via bit 39 of MMIO
offset 0x5B18 of the processor thermal PCI device.

To show the current power floor status and get notification
on a sysfs attribute, add 2 new attributes to
/sys/bus/pci/devices/0000\:00\:04.0/power_limits/

power_floor_enable : This attribute is present when power floor
notifications are supported. This attribute allows to enable/disable
power floor notifications.

power_floor_status : This attribute is present when power floor
notifications are supported. When enabled via power_floor_enable, this
attribute shows the current power floor status.

The power floor implementation provides interfaces which are called
from the sysfs callbacks to enable/disable and read power floor
status. It also provides two additional interfaces to check if the
current processor thermal device interrupt is for power floor status
and to send notifications to user space.

Signed-off-by: Srinivas Pandruvada <[email protected]>
[ rjw: Changelog and documentation changes edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

thermal: int340x: processor_thermal: Add workload type hint interface

Prior to Meteor Lake processor generation, user space can pass workload
type request to the firmware. Then firmware can optimize

thermal: int340x: processor_thermal: Add workload type hint interface

Prior to Meteor Lake processor generation, user space can pass workload
type request to the firmware. Then firmware can optimize power based on
the indicated workload type. User space also uses workload type requests
to implement its own heuristics.

The firmware in Meteor Lake processor generation is capable of predicting
workload type without software help.

To avoid duplicate processing, add a sysfs interface allowing user space
to obtain the workload hint from the firmware instead of trying to
predict the workload type by itself.

This workload hint is passed from the firmware via MMIO offset 0x5B18 of
the processor thermal PCI device. Before workload hints can be produced by
the firmware, it needs to be configured via a mailbox command. This
mailbox command turns ON the workload hint and it allows to program a
notification delay to control the rate of notifications.

The notification delay can be changed from user space vis sysfs.

Attribute group 'workload_hint' in sysfs is used for implementing the
workload hints interface between user space and the kernel.

It contains the following attributes:

workload_type_enable:
Enables/disables workload type hints from the firmware.

notification_delay_ms:
Notification delay in milliseconds.

workload_type_index:
The current workload type index predicted by the firmware (see
the documentation changes below for supported index values and
their meaning).

Signed-off-by: Srinivas Pandruvada <[email protected]>
[ rjw: Changelog edits, documentation edits, whitespace adjustments ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

thermal: int340x: processor_thermal: Move mailbox code to common module

The processor thermal mailbox is used for workload type request and
also in the processor thermal RFIM module. So, move the wo

thermal: int340x: processor_thermal: Move mailbox code to common module

The processor thermal mailbox is used for workload type request and
also in the processor thermal RFIM module. So, move the workload type
request code to its own module from the current processor thermal
mailbox module.

processor_thermal_mailbox.c contains only mailbox read/write related
source code. The source related to workload_types requests is moved to
a module processor_thermal_wt_req.c.

In addition
- Rename PROC_THERMAL_FEATURE_MBOX to PROC_THERMAL_FEATURE_WT_REQ.
- proc_thermal_mbox_add(), which adds workload type sysfs attribute group
is renamed to proc_thermal_wt_req_add().
- proc_thermal_mbox_remove() is renamed to proc_thermal_wt_req_remove().

While here, resolve check patch warnings for 100 columns for only modified
lines.

No functional changes are expected.

Signed-off-by: Srinivas Pandruvada <[email protected]>
Reviewed-by: Zhang Rui <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

thermal/drivers/int340x/processor_thermal: Add PCI MMIO based thermal driver

Add a new PCI driver which register a thermal zone and allows to get
notification for threshold violation by a RW trip po

thermal/drivers/int340x/processor_thermal: Add PCI MMIO based thermal driver

Add a new PCI driver which register a thermal zone and allows to get
notification for threshold violation by a RW trip point. These
notifications are delivered from the device using MSI based
interrupt.

The main difference between this new PCI driver and the existing
one is that the temperature and trip points directly use PCI
MMIO instead of using ACPI methods.

This driver registers a thermal zone "TCPU_PCI" in addition to the
legacy processor thermal device, which uses ACPI companion device
to set name, temperature and trips.

This driver is enabled for AlderLake.

Signed-off-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal/drivers/int340x/processor_thermal: Split enumeration and processing part

Remove enumeration part from the processor_thermal_device to two
different modules. One for ACPI and one for PCI:
AC

thermal/drivers/int340x/processor_thermal: Split enumeration and processing part

Remove enumeration part from the processor_thermal_device to two
different modules. One for ACPI and one for PCI:
ACPI enumeration: int3401_thermal
PCI part: processor_thermal_device_pci_legacy

The current processor_thermal_device now just implements interface
functions to be used by the ACPI and PCI enumeration module. This is
done by:
1. Make functions proc_thermal_add() and proc_thermal_remove() non static
and export them for usage in other processor_thermal_device_pci_legacy.c
and in int3401_thermal.c.

2. Move the sysfs file creation for TCC offset and power limit attribute
group to the proc_thermal_add() from the individual enumeration callbacks
for PCI and ACPI.

3. Create new interface functions proc_thermal_mmio_add() and
proc_thermal_mmio_remove() which will be called from the
processor_thermal_device_pci_legacy module.

4. Export proc_thermal_resume(), so that it can be used by power
management callbacks.

5. Remove special check for double enumeration as it never happens.

While here, fix some cleanup on error conditions in proc_thermal_add().

No functional changes are expected with this change.

Signed-off-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal: int340x: processor_thermal: Add mailbox driver

Added processor thermal device mail box interface for workload hints
setting. These hints will give indication to hardware to better manage
po

thermal: int340x: processor_thermal: Add mailbox driver

Added processor thermal device mail box interface for workload hints
setting. These hints will give indication to hardware to better manage
power and thermals. The supported hints are:
idle
semi_active
burusty
sustained
battery_life

For example when the system is on battery, the hardware can be less
aggressive in power ramp up.

This will create an attribute group at
/sys/bus/pci/devices/0000:00:04.0/workload_request

This folder contains two attributes:
workload_available_types : (RO): This shows available workload types
workload_type: (RW) : Allows to set and get current workload type
setting

Signed-off-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal: int340x: processor_thermal: Add RFIM driver

Add support for RFIM (Radio Frequency Interference Mitigation) support
via processor thermal PCI device. This drivers allows adjustment of
FIVR (

thermal: int340x: processor_thermal: Add RFIM driver

Add support for RFIM (Radio Frequency Interference Mitigation) support
via processor thermal PCI device. This drivers allows adjustment of
FIVR (Fully Integrated Voltage Regulator) and DDR (Double Data Rate)
frequencies to avoid RF interference with WiFi and 5G.

Switching voltage regulators (VR) generate radiated EMI or RFI at the
fundamental frequency and its harmonics. Some harmonics may interfere
with very sensitive wireless receivers such as Wi-Fi and cellular that
are integrated into host systems like notebook PCs. One of mitigation
methods is requesting SOC integrated VR (IVR) switching frequency to a
small % and shift away the switching noise harmonic interference from
radio channels. OEM or ODMs can use the driver to control SOC IVR
operation within the range where it does not impact IVR performance.

DRAM devices of DDR IO interface and their power plane can generate EMI
at the data rates. Similar to IVR control mechanism, Intel offers a
mechanism by which DDR data rates can be changed if several conditions
are met: there is strong RFI interference because of DDR; CPU power
management has no other restriction in changing DDR data rates;
PC ODMs enable this feature (real time DDR RFI Mitigation referred to as
DDR-RFIM) for Wi-Fi from BIOS.

This change exports two folders under /sys/bus/pci/devices/0000:00:04.0.
One folder "fivr" contains all attributes exposed for controling FIVR
features. The other folder "dvfs" contains all attributes for DDR
features.

Changes done to implement:
- New module for rfim interfaces
- Two new per processor features for DDR and FIVR
- Enable feature for Tiger Lake (FIVR only) and Alder Lake

The attributes exposed and explanation:

FIVR attributes

vco_ref_code_lo (RW): The VCO reference code is an 11-bit field and
controls the FIVR switching frequency. This is the 3-bit LSB field.

vco_ref_code_hi (RW): The VCO reference code is an 11-bit field and
controls the FIVR switching frequency. This is the 8-bit MSB field.

spread_spectrum_pct (RW): Set the FIVR spread spectrum clocking
percentage

spread_spectrum_clk_enable (RW): Enable/disable of the FIVR spread
spectrum clocking feature

rfi_vco_ref_code (RW): This field is a read only status register which
reflects the current FIVR switching frequency

fivr_fffc_rev (RW): This field indicated the revision of the FIVR HW.

DVFS attributes

rfi_restriction_run_busy (RW): Request the restriction of specific DDR
data rate and set this value 1. Self reset to 0 after operation.

rfi_restriction_err_code (RW): Values: 0 :Request is accepted, 1:Feature
disabled, 2: the request restricts more points than it is allowed

rfi_restriction_data_rate_Delta (RW): Restricted DDR data rate for RFI
protection: Lower Limit

rfi_restriction_data_rate_Base (RW): Restricted DDR data rate for RFI
protection: Upper Limit

ddr_data_rate_point_0 (RO): DDR data rate selection 1st point

ddr_data_rate_point_1 (RO): DDR data rate selection 2nd point

ddr_data_rate_point_2 (RO): DDR data rate selection 3rd point

ddr_data_rate_point_3 (RO): DDR data rate selection 4th point

rfi_disable (RW): Disable DDR rate change feature

Signed-off-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal: int340x: processor_thermal: Refactor MMIO interface

The Processor Thermal PCI device supports multiple features. Currently
we export only RAPL. But we need more features from this device ex

thermal: int340x: processor_thermal: Refactor MMIO interface

The Processor Thermal PCI device supports multiple features. Currently
we export only RAPL. But we need more features from this device exposed
for Tiger Lake and Alder Lake based platforms. So re-structure the
current MMIO interface, so that more features can be added cleanly.

No functional changes are expected with this change.

Changes done in this patch:
- Using PCI_DEVICE_DATA(), hence names of defines changed
- Move RAPL MMIO code to its own module
- Move the RAPL MMIO offsets to RAPL MMIO module
- Adjust Kconfig dependency of PROC_THERMAL_MMIO_RAPL
- Per processor driver data now contains the supported features
- Moved all the common data structures and defines to a common header
file
- This new header file contains all the processor_thermal_* interfaces
- Based on the features supported the module interface is called
- Each module atleast provides one add and one remove function

Signed-off-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

drivers: thermal: Move various drivers for intel platforms into a subdir

This cleans up the directory a bit, now that we have several other
platforms using platform-specific sub-directories. Compile

drivers: thermal: Move various drivers for intel platforms into a subdir

This cleans up the directory a bit, now that we have several other
platforms using platform-specific sub-directories. Compile-tested with
ARCH=x86 defconfig and the drivers explicitly enabled with menuconfig.

Signed-off-by: Amit Kucheria <[email protected]>
Acked-by: Daniel Lezcano <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>

show more ...