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@xxxxxxxxx> > > > > > > Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting. > > > > > /snip/ > > > > > Acked-by: Guenter Roeck <linux@xxxxxxxxxxxx> > > > > > --- > > > .../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@xxxxxxxxxxxxxxxxxxxxx > > > 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@xxxxxxxxxxxxxxxxxxxxx > > > +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
