All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
Cc: linux-hwmon@vger.kernel.org, anshuman.gupta@intel.com,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	jon.ewins@intel.com, Badal Nilawar <badal.nilawar@intel.com>,
	riana.tauro@intel.com
Subject: Re: [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting
Date: Thu, 9 Mar 2023 08:33:59 -0800	[thread overview]
Message-ID: <5d99cb43-4372-43e3-ae38-b45fc21896b4@roeck-us.net> (raw)
In-Reply-To: <87wn4132v4.wl-ashutosh.dixit@intel.com>

On Tue, Feb 28, 2023 at 01:18:55PM -0800, Dixit, Ashutosh wrote:
> On Fri, 12 Aug 2022 11:06:58 -0700, Guenter Roeck wrote:
> >
> 
> Hi Guenter/linux-hwmon,
> 
> 
> > On 8/12/22 10:37, Badal Nilawar wrote:
> > > From: Dale B Stimson <dale.b.stimson@intel.com>
> > >
> > > Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
> > >
> 
> /snip/
> 
> >
> > Acked-by: Guenter Roeck <linux@roeck-us.net>
> >
> > > ---
> > >   .../ABI/testing/sysfs-driver-intel-i915-hwmon |  20 ++
> > >   drivers/gpu/drm/i915/i915_hwmon.c             | 176 +++++++++++++++++-
> > >   drivers/gpu/drm/i915/i915_reg.h               |  16 ++
> > >   drivers/gpu/drm/i915/intel_mchbar_regs.h      |   7 +
> > >   4 files changed, 217 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > > index 24c4b7477d51..9a2d10edfce8 100644
> > > --- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > > +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > > @@ -5,3 +5,23 @@ Contact:	dri-devel@lists.freedesktop.org
> > >   Description:	RO. Current Voltage in millivolt.
> > >			Only supported for particular Intel i915 graphics
> > > platforms.
> > > +
> > > +What:		/sys/devices/.../hwmon/hwmon<i>/power1_max
> > > +Date:		June 2022
> > > +KernelVersion:	5.19
> > > +Contact:	dri-devel@lists.freedesktop.org
> > > +Description:	RW. Card reactive sustained  (PL1/Tau) power limit in microwatts.
> > > +
> > > +		The power controller will throttle the operating frequency
> > > +		if the power averaged over a window (typically seconds)
> > > +		exceeds this limit.
> 
> We exposed this as 'power1_max' previously. However this is a "power
> limit".
> 
> https://github.com/torvalds/linux/blob/master/Documentation/hwmon/sysfs-interface.rst
> 
> says power1_max is "Maximum power". On the other hand, power1_cap is "If
> power use rises above this limit, the system should take action to reduce
> power use". So it would seem we should have chosen power1_cap for this
> power limit instead of power1_max? So do you think we should change this to
> power1_cap instead? Though even power1_max has an associated alarm so it
> also seems to be a sort of limit.
> 
> Is there any guidance as to how these different power limits should be
> used? Generally speaking is: power1_max <= power1_cap <= power1_crit, or is
> it arbitrary or something else?
> 

Nothing should ever be "arbitrary" but have some reason. Arbitrary is
if you glue all the possible attributes onto a wall and then select the
ones to use by throwing darts at it.

powerX_min, powerX_max and powerX_crit are typically hard limits which
can not actively be influenced without drastic measures such as turning
off some hardware. powerX_cap is supposed to be more flexible; the
assumption is that the hardware or firmware has some means to control power
such that it does not exceed powerX_cap (while maintaining operational
status), for example by modifying operational frequencies.

Nowadays everything may be a bit more flexible; for example, one could
imagine that a modern system could (via software) reduce the operational
frequency of the system if power consumption exceeds powerX_max or
powerX_crit. The distinction would be that with powerX_cap, the hardware
or firmware would in general be in control, while with powerX_max
and powerX_crit the host software would be in control.

> Also, only power1_cap seems to have power1_cap_min and power1_cap_max (in
> case we wanted to use min/max values for the limits), not the others.

powerX_min is supported by the infrastructure. It not being documented
is an oversight.

Guenter

> 
> Separately, we have already used up power1_crit (which is the other limit
> in official hwmon power limits) so we can't use that.
> 
> Thanks.
> --
> Ashutosh

WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net>
To: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
Cc: linux-hwmon@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting
Date: Thu, 9 Mar 2023 08:33:59 -0800	[thread overview]
Message-ID: <5d99cb43-4372-43e3-ae38-b45fc21896b4@roeck-us.net> (raw)
In-Reply-To: <87wn4132v4.wl-ashutosh.dixit@intel.com>

On Tue, Feb 28, 2023 at 01:18:55PM -0800, Dixit, Ashutosh wrote:
> On Fri, 12 Aug 2022 11:06:58 -0700, Guenter Roeck wrote:
> >
> 
> Hi Guenter/linux-hwmon,
> 
> 
> > On 8/12/22 10:37, Badal Nilawar wrote:
> > > From: Dale B Stimson <dale.b.stimson@intel.com>
> > >
> > > Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
> > >
> 
> /snip/
> 
> >
> > Acked-by: Guenter Roeck <linux@roeck-us.net>
> >
> > > ---
> > >   .../ABI/testing/sysfs-driver-intel-i915-hwmon |  20 ++
> > >   drivers/gpu/drm/i915/i915_hwmon.c             | 176 +++++++++++++++++-
> > >   drivers/gpu/drm/i915/i915_reg.h               |  16 ++
> > >   drivers/gpu/drm/i915/intel_mchbar_regs.h      |   7 +
> > >   4 files changed, 217 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > > index 24c4b7477d51..9a2d10edfce8 100644
> > > --- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > > +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > > @@ -5,3 +5,23 @@ Contact:	dri-devel@lists.freedesktop.org
> > >   Description:	RO. Current Voltage in millivolt.
> > >			Only supported for particular Intel i915 graphics
> > > platforms.
> > > +
> > > +What:		/sys/devices/.../hwmon/hwmon<i>/power1_max
> > > +Date:		June 2022
> > > +KernelVersion:	5.19
> > > +Contact:	dri-devel@lists.freedesktop.org
> > > +Description:	RW. Card reactive sustained  (PL1/Tau) power limit in microwatts.
> > > +
> > > +		The power controller will throttle the operating frequency
> > > +		if the power averaged over a window (typically seconds)
> > > +		exceeds this limit.
> 
> We exposed this as 'power1_max' previously. However this is a "power
> limit".
> 
> https://github.com/torvalds/linux/blob/master/Documentation/hwmon/sysfs-interface.rst
> 
> says power1_max is "Maximum power". On the other hand, power1_cap is "If
> power use rises above this limit, the system should take action to reduce
> power use". So it would seem we should have chosen power1_cap for this
> power limit instead of power1_max? So do you think we should change this to
> power1_cap instead? Though even power1_max has an associated alarm so it
> also seems to be a sort of limit.
> 
> Is there any guidance as to how these different power limits should be
> used? Generally speaking is: power1_max <= power1_cap <= power1_crit, or is
> it arbitrary or something else?
> 

Nothing should ever be "arbitrary" but have some reason. Arbitrary is
if you glue all the possible attributes onto a wall and then select the
ones to use by throwing darts at it.

powerX_min, powerX_max and powerX_crit are typically hard limits which
can not actively be influenced without drastic measures such as turning
off some hardware. powerX_cap is supposed to be more flexible; the
assumption is that the hardware or firmware has some means to control power
such that it does not exceed powerX_cap (while maintaining operational
status), for example by modifying operational frequencies.

Nowadays everything may be a bit more flexible; for example, one could
imagine that a modern system could (via software) reduce the operational
frequency of the system if power consumption exceeds powerX_max or
powerX_crit. The distinction would be that with powerX_cap, the hardware
or firmware would in general be in control, while with powerX_max
and powerX_crit the host software would be in control.

> Also, only power1_cap seems to have power1_cap_min and power1_cap_max (in
> case we wanted to use min/max values for the limits), not the others.

powerX_min is supported by the infrastructure. It not being documented
is an oversight.

Guenter

> 
> Separately, we have already used up power1_crit (which is the other limit
> in official hwmon power limits) so we can't use that.
> 
> Thanks.
> --
> Ashutosh

WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net>
To: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
Cc: Badal Nilawar <badal.nilawar@intel.com>,
	intel-gfx@lists.freedesktop.org, linux-hwmon@vger.kernel.org,
	riana.tauro@intel.com, anshuman.gupta@intel.com,
	jon.ewins@intel.com,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting
Date: Thu, 9 Mar 2023 08:33:59 -0800	[thread overview]
Message-ID: <5d99cb43-4372-43e3-ae38-b45fc21896b4@roeck-us.net> (raw)
In-Reply-To: <87wn4132v4.wl-ashutosh.dixit@intel.com>

On Tue, Feb 28, 2023 at 01:18:55PM -0800, Dixit, Ashutosh wrote:
> On Fri, 12 Aug 2022 11:06:58 -0700, Guenter Roeck wrote:
> >
> 
> Hi Guenter/linux-hwmon,
> 
> 
> > On 8/12/22 10:37, Badal Nilawar wrote:
> > > From: Dale B Stimson <dale.b.stimson@intel.com>
> > >
> > > Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
> > >
> 
> /snip/
> 
> >
> > Acked-by: Guenter Roeck <linux@roeck-us.net>
> >
> > > ---
> > >   .../ABI/testing/sysfs-driver-intel-i915-hwmon |  20 ++
> > >   drivers/gpu/drm/i915/i915_hwmon.c             | 176 +++++++++++++++++-
> > >   drivers/gpu/drm/i915/i915_reg.h               |  16 ++
> > >   drivers/gpu/drm/i915/intel_mchbar_regs.h      |   7 +
> > >   4 files changed, 217 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > > index 24c4b7477d51..9a2d10edfce8 100644
> > > --- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > > +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > > @@ -5,3 +5,23 @@ Contact:	dri-devel@lists.freedesktop.org
> > >   Description:	RO. Current Voltage in millivolt.
> > >			Only supported for particular Intel i915 graphics
> > > platforms.
> > > +
> > > +What:		/sys/devices/.../hwmon/hwmon<i>/power1_max
> > > +Date:		June 2022
> > > +KernelVersion:	5.19
> > > +Contact:	dri-devel@lists.freedesktop.org
> > > +Description:	RW. Card reactive sustained  (PL1/Tau) power limit in microwatts.
> > > +
> > > +		The power controller will throttle the operating frequency
> > > +		if the power averaged over a window (typically seconds)
> > > +		exceeds this limit.
> 
> We exposed this as 'power1_max' previously. However this is a "power
> limit".
> 
> https://github.com/torvalds/linux/blob/master/Documentation/hwmon/sysfs-interface.rst
> 
> says power1_max is "Maximum power". On the other hand, power1_cap is "If
> power use rises above this limit, the system should take action to reduce
> power use". So it would seem we should have chosen power1_cap for this
> power limit instead of power1_max? So do you think we should change this to
> power1_cap instead? Though even power1_max has an associated alarm so it
> also seems to be a sort of limit.
> 
> Is there any guidance as to how these different power limits should be
> used? Generally speaking is: power1_max <= power1_cap <= power1_crit, or is
> it arbitrary or something else?
> 

Nothing should ever be "arbitrary" but have some reason. Arbitrary is
if you glue all the possible attributes onto a wall and then select the
ones to use by throwing darts at it.

powerX_min, powerX_max and powerX_crit are typically hard limits which
can not actively be influenced without drastic measures such as turning
off some hardware. powerX_cap is supposed to be more flexible; the
assumption is that the hardware or firmware has some means to control power
such that it does not exceed powerX_cap (while maintaining operational
status), for example by modifying operational frequencies.

Nowadays everything may be a bit more flexible; for example, one could
imagine that a modern system could (via software) reduce the operational
frequency of the system if power consumption exceeds powerX_max or
powerX_crit. The distinction would be that with powerX_cap, the hardware
or firmware would in general be in control, while with powerX_max
and powerX_crit the host software would be in control.

> Also, only power1_cap seems to have power1_cap_min and power1_cap_max (in
> case we wanted to use min/max values for the limits), not the others.

powerX_min is supported by the infrastructure. It not being documented
is an oversight.

Guenter

> 
> Separately, we have already used up power1_crit (which is the other limit
> in official hwmon power limits) so we can't use that.
> 
> Thanks.
> --
> Ashutosh

  reply	other threads:[~2023-03-09 16:34 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-12 17:37 [PATCH 0/7] drm/i915: Add HWMON support Badal Nilawar
2022-08-12 17:37 ` [Intel-gfx] " Badal Nilawar
2022-08-12 17:37 ` [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure Badal Nilawar
2022-08-12 17:37   ` [Intel-gfx] " Badal Nilawar
2022-08-12 18:05   ` Guenter Roeck
2022-08-12 18:05     ` [Intel-gfx] " Guenter Roeck
2022-08-12 17:37 ` [PATCH 2/7] drm/i915/hwmon: Add HWMON current voltage support Badal Nilawar
2022-08-12 17:37   ` [Intel-gfx] " Badal Nilawar
2022-08-12 18:05   ` Guenter Roeck
2022-08-12 18:05     ` [Intel-gfx] " Guenter Roeck
2022-08-12 17:37 ` [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting Badal Nilawar
2022-08-12 17:37   ` [Intel-gfx] " Badal Nilawar
2022-08-12 18:06   ` Guenter Roeck
2022-08-12 18:06     ` [Intel-gfx] " Guenter Roeck
2023-02-28 21:18     ` Dixit, Ashutosh
2023-02-28 21:18       ` [Intel-gfx] " Dixit, Ashutosh
2023-02-28 21:18       ` Dixit, Ashutosh
2023-03-09 16:33       ` Guenter Roeck [this message]
2023-03-09 16:33         ` Guenter Roeck
2023-03-09 16:33         ` [Intel-gfx] " Guenter Roeck
2022-08-12 17:37 ` [PATCH 4/7] drm/i915/hwmon: Show device level energy usage Badal Nilawar
2022-08-12 17:37   ` [Intel-gfx] " Badal Nilawar
2022-08-12 18:08   ` Guenter Roeck
2022-08-12 18:08     ` Guenter Roeck
2022-08-12 17:37 ` [PATCH 5/7] drm/i915/hwmon: Expose card reactive critical power Badal Nilawar
2022-08-12 17:37   ` [Intel-gfx] " Badal Nilawar
2022-08-12 18:09   ` Guenter Roeck
2022-08-12 18:09     ` [Intel-gfx] " Guenter Roeck
2022-08-12 17:37 ` [PATCH 6/7] drm/i915/hwmon: Expose power1_max_interval Badal Nilawar
2022-08-12 17:37   ` [Intel-gfx] " Badal Nilawar
2022-08-12 18:10   ` Guenter Roeck
2022-08-12 18:10     ` [Intel-gfx] " Guenter Roeck
2022-08-12 17:37 ` [PATCH 7/7] drm/i915/hwmon: Extend power/energy for XEHPSDV Badal Nilawar
2022-08-12 17:37   ` [Intel-gfx] " Badal Nilawar
2022-08-12 18:11   ` Guenter Roeck
2022-08-12 18:11     ` [Intel-gfx] " Guenter Roeck
2022-08-12 18:15 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add HWMON support (rev3) Patchwork
2022-08-12 18:15 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-08-12 18:38 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-08-13  0:27 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-08-18 19:38 [PATCH 0/7] drm/i915: Add HWMON support Badal Nilawar
2022-08-18 19:38 ` [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting Badal Nilawar
2022-08-25 13:21 [PATCH 0/7] drm/i915: Add HWMON support Badal Nilawar
2022-08-25 13:21 ` [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting Badal Nilawar
2022-08-30  2:33   ` Dixit, Ashutosh
2022-09-16 15:00 [PATCH 0/7] drm/i915: Add HWMON support Badal Nilawar
2022-09-16 15:00 ` [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting Badal Nilawar
2022-09-16 15:00   ` Badal Nilawar
2022-09-21  0:02   ` Dixit, Ashutosh
2022-09-21  0:02     ` Dixit, Ashutosh
2022-09-21 11:45   ` Gupta, Anshuman
2022-09-21 11:45     ` Gupta, Anshuman
2022-09-21 14:53     ` Nilawar, Badal
2022-09-21 14:53       ` Nilawar, Badal
2022-09-22  7:08       ` Gupta, Anshuman
2022-09-22  7:08         ` Gupta, Anshuman
2022-09-23  2:26         ` Dixit, Ashutosh
2022-09-23  2:26           ` Dixit, Ashutosh
2022-09-23 19:56 [PATCH 0/7] drm/i915: Add HWMON support Badal Nilawar
2022-09-23 19:56 ` [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting Badal Nilawar
2022-09-23 19:56   ` Badal Nilawar
2022-09-26 17:52 [PATCH 0/7] Add HWMON support Badal Nilawar
2022-09-26 17:52 ` [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting Badal Nilawar
2022-09-26 17:52   ` Badal Nilawar
2022-09-27  8:04   ` kernel test robot
2022-09-27 13:51   ` Gupta, Anshuman
2022-09-27 13:51     ` Gupta, Anshuman
2022-09-27  5:50 [PATCH 0/7] drm/i915: Add HWMON support Badal Nilawar
2022-09-27  5:50 ` [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting Badal Nilawar
2022-09-27  5:50   ` Badal Nilawar
2022-09-28  7:08   ` Gupta, Anshuman
2022-09-28  7:08     ` Gupta, Anshuman
2022-10-13 15:45 [PATCH 0/7] drm/i915: Add HWMON support Ashutosh Dixit
2022-10-13 15:45 ` [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting Ashutosh Dixit
2022-10-13 15:45   ` Ashutosh Dixit
2022-10-13 19:32   ` kernel test robot
2022-10-22 13:31   ` kernel test robot
2022-10-20  1:15 kernel test robot

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=5d99cb43-4372-43e3-ae38-b45fc21896b4@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=anshuman.gupta@intel.com \
    --cc=ashutosh.dixit@intel.com \
    --cc=badal.nilawar@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jon.ewins@intel.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=riana.tauro@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.