linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
To: "Zhang, Rui" <rui.zhang@intel.com>,
	"lukasz.luba@arm.com" <lukasz.luba@arm.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	 "daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>
Cc: "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] thermal: intel: int340x: Add platform temperature control interface
Date: Fri, 14 Mar 2025 07:30:39 -0700	[thread overview]
Message-ID: <ab3fb97f30656badde65c542c72885392bfd7762.camel@linux.intel.com> (raw)
In-Reply-To: <ca935ccd07fb27a77a39fa797738e7a2e96abeb1.camel@intel.com>

On Tue, 2025-03-11 at 05:56 +0000, Zhang, Rui wrote:
> On Sat, 2025-03-08 at 10:38 -0800, Srinivas Pandruvada wrote:
> > Platform Temperature Control is a dynamic control loop implemented
> > in
> > hardware to manage the skin or any board temperature of a device.
> > The
> > reported skin or board temperature is controlled by comparing to a
> > configured target temperature and adjusting the SoC (System on
> > Chip)
> > performance accordingly. The feature supports up to three platform
> > sensors.
> > 
> > OEMs (Original Equipment Manufacturers) can configure this feature
> > through the BIOS and provide temperature input directly to the
> > hardware
> > via the Platform Environment Control Interface (PECI).
> 
> Does this mean each PTC instance is bound to a certain skin/board
> sensor?
Yes.

>  And writing the "temperature_target" sysfs tells firmware the
> target temperature, as well as the target sensor that the temperature
> applies to? 
Yes

> if yes, is there a way for userspace to know which sensor
> each PTC instance applies to?
No.
You can just change threshold up and down by observation only.

Thanks,
Srinivas

> 
> >  As a result,
> > this feature can operate independently of any OS-level control.
> > 
> > The OS interface can be used to further fine-tune the default OEM
> > configuration. Here are some scenarios where the OS interface is
> > beneficial:
> > Verification of Firmware Control: Check if firmware-based control
> > is
> > enabled. If it is, thermal controls from the OS/user space can be
> > backed out.
> > Adjusting Target Limits: While OEMs can set an aggressive target
> > limit,
> > the OS can adjust this to a less aggressive limit based on
> > operating
> > modes or conditions.
> > 
> > The hardware control interface is via a MMIO offsets via processor
> > thermal device. There are three instances of MMIO registers. All
> > are 64 bit registers
> > 
> > Name: PLATFORM_TEMPERATURE_CONTROL
> > Offsets: 0x5B20, 0x5B28, 0x5B30
> > 
> > All values have RW access
> > 
> > Bits    Description
> > 7:0     TARGET_TEMP : Target temperature limit to which the control
> >         mechanism is regulating. Units: 0.5C.
> > 8:8     ENABLE: Read current enable status of the feature or enable
> > 	feature.
> > 11:9	GAIN: Sets the aggressiveness of control loop from 0 to 7
> > 	7 graceful, favors performance at the expense of
> > temperature
> > 	overshoots
> > 	0 aggressive, favors tight regulation over performance
> > 12:12	TEMPERATURE_OVERRIDE_EN
> > 	When set, hardware will use TEMPERATURE_OVERRIDE values
> > instead
> > 	of reading from corresponding sensor.
> > 15:13	RESERVED
> > 23:16	MIN_PERFORMANCE_LEVEL: Minimum Performance level below
> > which
> > the
> > 	there will be no throttling. 0 - all levels of throttling
> > allowed
> > 	including survivability actions. 255 - no throttling
> > allowed.
> > 31:24	TEMPERATURE_OVERRIDE: Allows SW to override the input
> > temperature.
> > 	hardware will use this value instead of the sensor
> > temperature.
> > 	Units: 0.5C.
> > 63:32	RESERVED
> > 
> > Out of the above controls, only "enable" and "temperature_target"
> > is
> > exposed via sysfs.
> > There are three instances of this controls. So up to three
> > different
> > sensors can be controlled independently.
> > 
> > Sysfs interface:
> > tree
> > /sys/bus/pci/devices/0000\:00\:04.0/platform_temperature_?_control/
> > /sys/bus/pci/devices/0000:00:04.0/platform_temperature_0_control/
> > ├── enable
> > ├── temperature_target
> > /sys/bus/pci/devices/0000:00:04.0/platform_temperature_1_control/
> > ├── enable
> > ├── temperature_target
> > /sys/bus/pci/devices/0000:00:04.0/platform_temperature_2_control/
> > ├── enable
> > ├── temperature_target
> > 
> > Description of attributes:
> > 
> > Enable: 1 for enable, 0 for disable. This attribute can be used to
> > read the current status. User space can write 0 or 1 to disable or
> > enable this feature respectively.
> > temperature_target: Target temperature limit to which hardware
> > will try to limit in milli degree C.
> > 
> > Signed-off-by: Srinivas Pandruvada
> > <srinivas.pandruvada@linux.intel.com>
> > ---
> >  .../thermal/intel/int340x_thermal/Makefile    |   1 +
> >  .../platform_temperature_control.c            | 181
> > ++++++++++++++++++
> >  .../processor_thermal_device.c                |  15 +-
> >  .../processor_thermal_device.h                |   3 +
> >  4 files changed, 199 insertions(+), 1 deletion(-)
> >  create mode 100644
> > drivers/thermal/intel/int340x_thermal/platform_temperature_control.
> > c
> > 
> > diff --git a/drivers/thermal/intel/int340x_thermal/Makefile
> > b/drivers/thermal/intel/int340x_thermal/Makefile
> > index fe3f43924525..184318d1792b 100644
> > --- a/drivers/thermal/intel/int340x_thermal/Makefile
> > +++ b/drivers/thermal/intel/int340x_thermal/Makefile
> > @@ -9,6 +9,7 @@ obj-$(CONFIG_INT340X_THERMAL)	+=
> > processor_thermal_device_pci_legacy.o
> >  obj-$(CONFIG_INT340X_THERMAL)	+= processor_thermal_device_pci.o
> >  obj-$(CONFIG_PROC_THERMAL_MMIO_RAPL) += processor_thermal_rapl.o
> >  obj-$(CONFIG_INT340X_THERMAL)	+= processor_thermal_rfim.o
> > +obj-$(CONFIG_INT340X_THERMAL)	+= platform_temperature_control.o
> >  obj-$(CONFIG_INT340X_THERMAL)	+= processor_thermal_mbox.o
> >  obj-$(CONFIG_INT340X_THERMAL)	+= processor_thermal_wt_req.o
> >  obj-$(CONFIG_INT340X_THERMAL)	+= processor_thermal_wt_hint.o
> > diff --git
> > a/drivers/thermal/intel/int340x_thermal/platform_temperature_contro
> > l.
> > c
> > b/drivers/thermal/intel/int340x_thermal/platform_temperature_contro
> > l.
> > c
> > new file mode 100644
> > index 000000000000..dd3ea7165800
> > --- /dev/null
> > +++
> > b/drivers/thermal/intel/int340x_thermal/platform_temperature_contro
> > l.
> > c
> > @@ -0,0 +1,181 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * processor thermal device platform temperature controls
> > + * Copyright (c) 2025, Intel Corporation.
> > + */
> > +
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/pci.h>
> > +#include "processor_thermal_device.h"
> > +
> > +struct mmio_reg {
> > +	int bits;
> > +	u16 mask;
> > +	u16 shift;
> > +	u16 units;
> > +};
> > +
> > +#define MAX_ATTR_GROUP_NAME_LEN 32
> > +
> > +struct ptc_data {
> > +	u32 offset;
> > +	struct attribute_group ptc_attr_group;
> > +	struct attribute *ptc_attrs[3];
> > +	struct device_attribute temperature_target_attr;
> > +	struct device_attribute enable_attr;
> > +	char group_name[MAX_ATTR_GROUP_NAME_LEN];
> > +};
> > +
> > +static const struct mmio_reg ptc_mmio_regs[] = {
> > +	{ 8, 0xFF, 0, 500}, /* temperature_target, units 0.5C*/
> > +	{ 1, 0x01, 8, 0}, /* enable */
> > +	{ 3, 0x7, 9, 0}, /* gain */
> > +	{ 8, 0xFF, 16, 0}, /* min_performance_level */
> > +	{ 1, 0x1, 12, 0}, /* temperature_override_enable */
> > +	{ 8, 0xFF, 24, 500}, /* temperature_override, units 0.5C
> > */
> > +};
> > +
> > +/* Unique offset for each PTC instance */
> > +static u32 ptc_offsets[] = {0x5B20, 0x5B28, 0x5B30};
> 
> I'd prefer to define PTC_MAX_INSTANCES earlier and use
>   static u32 ptc_offsets[PTC_MAX_INSTANCES] = {0x5B20, 0x5B28,
> 0x5B30};
> instead.
> 
> thanks,
> rui


  reply	other threads:[~2025-03-14 14:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-08 18:38 [PATCH 0/3] Platform Temperature Control interface Srinivas Pandruvada
2025-03-08 18:38 ` [PATCH 1/3] thermal: intel: int340x: Add platform temperature control interface Srinivas Pandruvada
2025-03-11  5:56   ` Zhang, Rui
2025-03-14 14:30     ` srinivas pandruvada [this message]
2025-03-08 18:38 ` [PATCH 2/3] thermal: intel: int340x: Enable platform temperature control Srinivas Pandruvada
2025-03-08 18:38 ` [PATCH 3/3] thermal: int340x: processor_thermal: Platform temperature control documentation Srinivas Pandruvada
2025-03-08 18:40 ` [PATCH 0/3] Platform Temperature Control interface srinivas pandruvada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ab3fb97f30656badde65c542c72885392bfd7762.camel@linux.intel.com \
    --to=srinivas.pandruvada@linux.intel.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=rafael@kernel.org \
    --cc=rui.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).