mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Winiarska, Iwona" <iwona.winiarska@intel.com>
To: "linux@roeck-us.net" <linux@roeck-us.net>,
	"robh@kernel.org" <robh@kernel.org>,
	"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
	"conor+dt@kernel.org" <conor+dt@kernel.org>,
	"changhuang.liang@starfivetech.com"
	<changhuang.liang@starfivetech.com>
Cc: "p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
	"linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 5/6] hwmon: (peci/cputemp) Add support for Granite Rapids (GNR)
Date: Thu, 17 Sep 2026 20:49:24 +0000	[thread overview]
Message-ID: <1019d238455fbe7767f50d063566f4f43056807e.camel@intel.com> (raw)
In-Reply-To: <ZQ4PR01MB120212E0FFA32C9501736A94F2BC2@ZQ4PR01MB1202.CHNPR01.prod.partner.outlook.cn>

On Sun, 2026-09-13 at 03:36 +0000, Changhuang Liang wrote:
> Hi, Guenter
> 
> Thanks for the review.
> 
> > On 9/3/26 06:34, Changhuang Liang wrote:
> > > Add Granite Rapids (GNR) CPU support to the PECI cputemp driver. The
> > > GNR platform does not support the core mask scan via PCI local read,
> > > so handle this case explicitly by returning -EPERM and skipping the
> > > core mask initialization.
> > > 
> > 
> > After reading the next patch of the series: Are you sure that this is the
> > case, or
> > is it possible that Granite Rapids just uses a different access mechanism to
> > provide the information ?
> > 
> 
> This is the information I obtained by referring to the commit below. 
> Of course, it would be best if Iwona could also help verify it.
> 
> https://github.com/ocp-hm-openbmc-opf-ami/linux/commit/94b4b0c83d33bec70dcc92f687c4a32e1a1e253c

It's not that it's not supported - it's just a bit more complicated.
GNR introduces a concept of domains, and to figure out the core mask, we need to
query all the domains.
With that - there are some opens on how the domain support should be
implemented. For example, we might want to consider representing domains as
separate PECI devices, which would have an impact on the device/driver model.

Thanks
-Iwona

> 
> > Thanks,
> > Guenter
> > 
> > > Define new cpu_info structure for GNR with minimum PECI revision 0x40
> > > and the thermal margin conversion function
> > dts_ten_dot_six_to_millidegree().
> > > 
> > > Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> > > ---
> > >   drivers/hwmon/peci/cputemp.c | 20 ++++++++++++++++++++
> > >   1 file changed, 20 insertions(+)
> > > 
> > > diff --git a/drivers/hwmon/peci/cputemp.c
> > > b/drivers/hwmon/peci/cputemp.c index 457089c561b4..43e52a6db79b
> > 100644
> > > --- a/drivers/hwmon/peci/cputemp.c
> > > +++ b/drivers/hwmon/peci/cputemp.c
> > > @@ -339,6 +339,17 @@ static int init_core_mask(struct peci_cputemp
> > *priv)
> > >   	u32 data;
> > >   	int ret;
> > > 
> > > +	/*
> > > +	 * Some platforms (e.g. Granite Rapids) do not expose the
> > RESOLVED_CORES
> > > +	 * register over PECI - per-core temperatures are simply not
> > > available.
> > > +	 */
> > > +	if (!reg) {
> > > +		dev_dbg(priv->dev,
> > > +			"resolved cores scan is not supported on vendor-
> > > family-model
> > 0x%x\n",
> > > +			peci_dev->info.x86_vfm);
> > > +		return -EOPNOTSUPP;
> > > +	}
> > > +
> > >   	/* Get the RESOLVED_CORES register value */
> > >   	switch (peci_dev->info.x86_vfm) {
> > >   	case INTEL_ICELAKE_X:
> > > @@ -543,6 +554,11 @@ static const struct cpu_info cpu_emr = {
> > >   	.thermal_margin_to_millidegree =
> > &dts_ten_dot_six_to_millidegree,
> > >   };
> > > 
> > > +static const struct cpu_info cpu_gnr = {
> > > +	.min_peci_revision = 0x40,
> > > +	.thermal_margin_to_millidegree = &dts_ten_dot_six_to_millidegree,
> > > };
> > > +
> > >   static const struct auxiliary_device_id peci_cputemp_ids[] = {
> > >   	{
> > >   		.name = "peci_cpu.cputemp.hsx",
> > > @@ -576,6 +592,10 @@ static const struct auxiliary_device_id
> > peci_cputemp_ids[] = {
> > >   		.name = "peci_cpu.cputemp.emr",
> > >   		.driver_data = (kernel_ulong_t)&cpu_emr,
> > >   	},
> > > +	{
> > > +		.name = "peci_cpu.cputemp.gnr",
> > > +		.driver_data = (kernel_ulong_t)&cpu_gnr,
> > > +	},
> > >   	{ }
> > >   };
> > >   MODULE_DEVICE_TABLE(auxiliary, peci_cputemp_ids);
> 
> Best Regards,
> Changhuang

  reply	other threads:[~2026-09-17 20:49 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03 13:34 [PATCH v1 0/6] Add StarFive JHB100 PECI support Changhuang Liang
2026-09-03 13:34 ` [PATCH v1 1/6] dt-bindings: peci: Add StarFive JHB100 PECI controller Changhuang Liang
2026-09-03 16:35   ` Conor Dooley
2026-09-03 13:34 ` [PATCH v1 2/6] peci: controller: Add StarFive JHB100 PECI driver Changhuang Liang
2026-09-17 20:47   ` Winiarska, Iwona
2026-09-18  2:30     ` Changhuang Liang
2026-09-03 13:34 ` [PATCH v1 3/6] peci: Add support for PECI CC 0x83 retry condition Changhuang Liang
2026-09-17 20:47   ` Winiarska, Iwona
2026-09-18  2:32     ` Changhuang Liang
2026-09-03 13:34 ` [PATCH v1 4/6] peci: cpu: Add Intel Granite Rapids support Changhuang Liang
2026-09-03 13:34 ` [PATCH v1 5/6] hwmon: (peci/cputemp) Add support for Granite Rapids (GNR) Changhuang Liang
2026-09-12 14:58   ` Guenter Roeck
2026-09-12 15:13   ` Guenter Roeck
2026-09-13  3:36     ` Changhuang Liang
2026-09-17 20:49       ` Winiarska, Iwona [this message]
2026-09-17 20:48   ` Winiarska, Iwona
2026-09-18  2:33     ` Changhuang Liang
2026-09-03 13:34 ` [PATCH v1 6/6] hwmon: (peci/dimmtemp) " Changhuang Liang
2026-09-12 15:10   ` Guenter Roeck
2026-09-13  4:07     ` Changhuang Liang
2026-09-13  4:16       ` Guenter Roeck
2026-09-16  0:57         ` Changhuang Liang
2026-09-17 20:50       ` Winiarska, Iwona

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=1019d238455fbe7767f50d063566f4f43056807e.camel@intel.com \
    --to=iwona.winiarska@intel.com \
    --cc=changhuang.liang@starfivetech.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=openbmc@lists.ozlabs.org \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    /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

all inboxes | Powered by JetHome®