summaryrefslogtreecommitdiffstats
path: root/drivers/thermal/intel/int340x_thermal/processor_thermal_device.h
Commit message (Collapse)AuthorAgeFilesLines
* thermal: intel: int340x: Support MSI interrupt for Lunar LakeSrinivas Pandruvada2024-06-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The legacy PCI interrupt is no longer supported for processor thermal device on Lunar Lake. The support is via MSI. Add feature PROC_THERMAL_FEATURE_MSI_SUPPORT to support MSI feature per generation. Define this feature for Lunar Lake processors. There are 4 MSI sources: 0 - Package thermal 1 - DDR Thermal 2 - Power floor interrupt 3 - Workload type hint On interrupt, check the source and call the corresponding handler. Here don't need to call proc_thermal_check_wt_intr() and proc_thermal_check_power_floor_intr() to check if the interrupt is for those sources as there is a dedicated MSI interrupt. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20240619172109.497639-3-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* thermal: int340x: processor_thermal: Add Lunar Lake-M PCI IDSrinivas Pandruvada2024-02-281-0/+1
| | | | | | | Add Lunar Lake-M PCI ID for processor thermal device. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* thermal: int340x: processor_thermal: Support power floor notificationsSrinivas Pandruvada2023-10-121-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <srinivas.pandruvada@linux.intel.com> [ rjw: Changelog and documentation changes edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* thermal: int340x: processor_thermal: Common function to clear SOC interruptSrinivas Pandruvada2023-10-121-0/+1
| | | | | | | | | | | | | | | | | The SOC interrupt status register contains multiple interrupt sources (workload hint interrupt and power floor interrupt). It is not possible to clear individual interrupt source with read-modify-write, as it may clear the new interrupt from the firmware after a read operation. It is also not possible to set the interrupt status bit to 1 for the other interrupt source, which is not part of clearing. Hence, create a common function, to clear all status bits at once. Call this function after processing all interrupt sources. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* thermal: int340x: processor_thermal: Move interrupt status MMIO offset to ↵Srinivas Pandruvada2023-10-121-0/+2
| | | | | | | | | | | common header Move define SOC_WT_RES_INT_STATUS_OFFSET to processor_thermal_device.h. This way it can be reused in other modules. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* thermal: int340x: Add ArrowLake-S PCI IDSrinivas Pandruvada2023-09-181-0/+1
| | | | | | | Add ArrowLake-S PCI ID for processor thermal device. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* thermal: int340x: processor_thermal: Add workload type hint interfaceSrinivas Pandruvada2023-09-141-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <srinivas.pandruvada@linux.intel.com> [ rjw: Changelog edits, documentation edits, whitespace adjustments ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* thermal: int340x: processor_thermal: Add interrupt configuration functionSrinivas Pandruvada2023-09-141-0/+2
| | | | | | | | | | | | | | | | | | Some features like workload type prediction and power floor events require interrupt support to avoid polling. Here interrupts are enabled and disabled via sending mailbox commands. The mailbox command ID is 0x1E for read and 0x1F for write. The interrupt configuration will require mutex protection as it involves read-modify-write operation. Since mutex are already used in the mailbox read/write functions: send_mbox_write_cmd() and send_mbox_read_cmd(), there will be double locking. But, this can be avoided by moving mutexes from mailbox read/write processing functions to the callers: processor_thermal_send_mbox_[read|write]_cmd(). Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Adjust subject, fix up computation ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* thermal: int340x: processor_thermal: Move mailbox code to common moduleSrinivas Pandruvada2023-09-141-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <srinivas.pandruvada@linux.intel.com> Reviewed-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* thermal: intel: int340x: Add DLVR support for RFIM controlSrinivas Pandruvada2023-04-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for DLVR (Digital Linear Voltage Regulator) attributes, which can be used to control RFIM. Here instead of "fivr" another directory "dlvr" is created with DLVR attributes: /sys/bus/pci/devices/0000:00:04.0/dlvr ├── dlvr_freq_mhz ├── dlvr_freq_select ├── dlvr_hardware_rev ├── dlvr_pll_busy ├── dlvr_rfim_enable └── dlvr_spread_spectrum_pct └── dlvr_control_mode └── dlvr_control_lock Attributes dlvr_freq_mhz (RO): Current DLVR PLL frequency in MHz. dlvr_freq_select (RW): Sets DLVR PLL clock frequency. dlvr_hardware_rev (RO): DLVR hardware revision. dlvr_pll_busy (RO): PLL can't accept frequency change when set. dlvr_rfim_enable (RW): 0: Disable RF frequency hopping, 1: Enable RF frequency hopping. dlvr_control_mode (RW): Specifies how frequencies are spread. 0: Down spread, 1: Spread in Center. dlvr_control_lock (RW): 1: future writes are ignored. dlvr_spread_spectrum_pct (RW) A write to this register updates the DLVR spread spectrum percent value. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* thermal: int340x: Add Meteor Lake PCI device IDSumeet Pawnikar2022-05-251-0/+1
| | | | | | | | Add Meteor Lake PCI ID for processor thermal device. Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* thermal: int340x: Add Raptor Lake PCI device idSrinivas Pandruvada2022-01-171-0/+1
| | | | | | | Add Raptor Lake PCI ID for processor thermal device. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* thermal/drivers/int340x: Fix RFIM mailbox write commandsSumeet Pawnikar2021-12-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing mail mechanism only supports writing of workload types. However, mailbox command for RFIM (cmd = 0x08) also requires write operation which is ignored. This results in failing to store RFI restriction. Fixint this requires enhancing mailbox writes for non workload commands too, so remove the check for MBOX_CMD_WORKLOAD_TYPE_WRITE in mailbox write to allow this other write commands to be supoorted. At the same time, however, we have to make sure that there is no impact on read commands, by avoiding to write anything into the mailbox data register. To properly implement that, add two separate functions for mbox read and write commands for the processor thermal workload command type. This helps to distinguish the read and write workload command types from each other while sending mbox commands. Fixes: 5d6fbc96bd36 ("thermal/drivers/int340x: processor_thermal: Export additional attributes") Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Cc: 5.14+ <stable@vger.kernel.org> # 5.14+ Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responsesSrinivas Pandruvada2021-11-041-1/+1
| | | | | | | | | | Some of the RFIM mail box command returns 64 bit values. So enhance mailbox interface to return 64 bit values and use them for RFIM commands. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Fixes: 5d6fbc96bd36 ("thermal/drivers/int340x: processor_thermal: Export additional attributes") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* thermal/drivers/int340x: Improve the tcc offset saving for suspend/resumeAntoine Tenart2021-10-211-0/+1
| | | | | | | | | | | | | | | | When the driver resumes, the tcc offset is set back to its previous value. But this only works if the value was user defined as otherwise the offset isn't saved. This asymmetric logic is harder to maintain and introduced some issues. Improve the logic by saving the tcc offset in a suspend op, so the right value is always restored after a resume. Signed-off-by: Antoine Tenart <atenart@kernel.org> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Srinivas Pandruvada <srinivas.pI andruvada@linux.intel.com> Link: https://lore.kernel.org/r/20210909085613.5577-3-atenart@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
* thermal/drivers/int340x/processor_thermal: Add PCI MMIO based thermal driverSrinivas Pandruvada2021-07-041-0/+1
| | | | | | | | | | | | | | | | | | | | | 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 <srinivas.pandruvada@linux.intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210525204811.3793651-3-srinivas.pandruvada@linux.intel.com
* thermal/drivers/int340x/processor_thermal: Split enumeration and processing partSrinivas Pandruvada2021-07-041-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <srinivas.pandruvada@linux.intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210525204811.3793651-2-srinivas.pandruvada@linux.intel.com
* thermal/drivers/int340x: processor_thermal: Export mailbox interfaceSrinivas Pandruvada2021-06-111-0/+2
| | | | | | | | | Export the mailbox interface to be used by other modules. Also change command id and response from u8 to u32 data type. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210517061441.1921901-2-srinivas.pandruvada@linux.intel.com
* thermal: int340x: processor_thermal: Add mailbox driverSrinivas Pandruvada2020-12-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <srinivas.pandruvada@linux.intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201126171829.945969-4-srinivas.pandruvada@linux.intel.com
* thermal: int340x: processor_thermal: Add RFIM driverSrinivas Pandruvada2020-12-101-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <srinivas.pandruvada@linux.intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201126171829.945969-3-srinivas.pandruvada@linux.intel.com
* thermal: int340x: processor_thermal: Add AlderLake PCI device idSrinivas Pandruvada2020-12-101-0/+1
| | | | | | | | | Added AlderLake PCI device id to support processor thermal driver. Reuse the feature set (just includes RAPL) from previous generations. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201126171829.945969-2-srinivas.pandruvada@linux.intel.com
* thermal: int340x: processor_thermal: Refactor MMIO interfaceSrinivas Pandruvada2020-12-101-0/+72
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 <srinivas.pandruvada@linux.intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201126171829.945969-1-srinivas.pandruvada@linux.intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-10 23:16:10 +0000