From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5AD7BC64EC4 for ; Thu, 9 Mar 2023 16:34:06 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5514310E175; Thu, 9 Mar 2023 16:34:05 +0000 (UTC) Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) by gabe.freedesktop.org (Postfix) with ESMTPS id B981910E175; Thu, 9 Mar 2023 16:34:02 +0000 (UTC) Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-1755e639b65so2894990fac.3; Thu, 09 Mar 2023 08:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678379642; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=kEkr4IaQKiN+bzmiIZcnvGMMGRo7jIir1uiKe1VUqZU=; b=X5SYnXrMqzjgz7pSQ1n/dLxLkITJDxgyHHYSj/ycchtVrh4S7dT7u/jyFQsfE/Jx+h Nkl7p9mvAMmKGB0tyJMD6gj2N55oSzzC1uULgZiKDFHtWDZub+wOlRcVAoMwqIASiRc5 mpZ1JmR0LYRjSVCYCgyWDT2ULe8NRqAOAKoNq1sA3acwapQt6/pIb6eTCJjouziTPIIH E2Z0AivkzUY1yQAABFbslknMES4uL3at0+9Njau2KTx7NgkcxyNrUIR/G+FaSo9ixIBg 08GWJJ/97aFQ4p60DN4LiR9FAdiiURh5iRlPaULzoCZRpZQVdnP/gS+UrFWWLDq4lLKB tdlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678379642; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kEkr4IaQKiN+bzmiIZcnvGMMGRo7jIir1uiKe1VUqZU=; b=TbMLTJRzjjdm39nsktpJWjqGPsGNpYxrHWT/KrpEozhi/6clxIYYkL3/uQfSrSDDWh ml9BY7R3Tn2+aBn3Bf55Iv9CpigHemUFGQA2VtFDxY035Cso/DYvPF7twD0hz947eFul HP4JWnV9pnxUBf/B3bDG6g3UUUnqfcrqvv+HgdtIIkjXhQ/54ByfgmJUMBpCvGovv0AL TwP47+gvdp8YgcxmBsP9h8YImCtArv6i4bKKwgRp/ZLY45Ena8u6S6397GopnOroP0KY WPMpzKMYWaquEaoCc9x0Vxdoglssr29HvhJx+PVfjzGE0rJVuIgQrFclVugrvZFN5U2L srfw== X-Gm-Message-State: AO0yUKWsBQYhqsirVvuIrt5uekHLB8IksRf0Q76PPqvx7qtGKyyK648Z 9CjSy90NIpvpk/FJ0VJm3m4= X-Google-Smtp-Source: AK7set+KhEAx3r4Y9MIM+NVdqGP5VOGZRy6Nk+cs5k+7rrb+TRVpcVOW4MMUPsUfZPMGuLum1I/gzQ== X-Received: by 2002:a05:6870:819d:b0:172:21e9:21c7 with SMTP id k29-20020a056870819d00b0017221e921c7mr13509074oae.40.1678379641913; Thu, 09 Mar 2023 08:34:01 -0800 (PST) Received: from server.roeck-us.net ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id bf7-20020a0568700a0700b0017243e98ce9sm6969444oac.54.2023.03.09.08.34.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Mar 2023 08:34:01 -0800 (PST) Date: Thu, 9 Mar 2023 08:33:59 -0800 From: Guenter Roeck To: "Dixit, Ashutosh" Subject: Re: [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting Message-ID: <5d99cb43-4372-43e3-ae38-b45fc21896b4@roeck-us.net> References: <20220812173715.2398586-1-badal.nilawar@intel.com> <20220812173715.2398586-4-badal.nilawar@intel.com> <87wn4132v4.wl-ashutosh.dixit@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wn4132v4.wl-ashutosh.dixit@intel.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 , riana.tauro@intel.com Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 > > > > > > Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting. > > > > > /snip/ > > > > > Acked-by: Guenter Roeck > > > > > --- > > > .../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/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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 42E05C64EC4 for ; Thu, 9 Mar 2023 16:34:13 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2A8D110E199; Thu, 9 Mar 2023 16:34:06 +0000 (UTC) Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) by gabe.freedesktop.org (Postfix) with ESMTPS id B981910E175; Thu, 9 Mar 2023 16:34:02 +0000 (UTC) Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-1755e639b65so2894990fac.3; Thu, 09 Mar 2023 08:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678379642; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=kEkr4IaQKiN+bzmiIZcnvGMMGRo7jIir1uiKe1VUqZU=; b=X5SYnXrMqzjgz7pSQ1n/dLxLkITJDxgyHHYSj/ycchtVrh4S7dT7u/jyFQsfE/Jx+h Nkl7p9mvAMmKGB0tyJMD6gj2N55oSzzC1uULgZiKDFHtWDZub+wOlRcVAoMwqIASiRc5 mpZ1JmR0LYRjSVCYCgyWDT2ULe8NRqAOAKoNq1sA3acwapQt6/pIb6eTCJjouziTPIIH E2Z0AivkzUY1yQAABFbslknMES4uL3at0+9Njau2KTx7NgkcxyNrUIR/G+FaSo9ixIBg 08GWJJ/97aFQ4p60DN4LiR9FAdiiURh5iRlPaULzoCZRpZQVdnP/gS+UrFWWLDq4lLKB tdlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678379642; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kEkr4IaQKiN+bzmiIZcnvGMMGRo7jIir1uiKe1VUqZU=; b=TbMLTJRzjjdm39nsktpJWjqGPsGNpYxrHWT/KrpEozhi/6clxIYYkL3/uQfSrSDDWh ml9BY7R3Tn2+aBn3Bf55Iv9CpigHemUFGQA2VtFDxY035Cso/DYvPF7twD0hz947eFul HP4JWnV9pnxUBf/B3bDG6g3UUUnqfcrqvv+HgdtIIkjXhQ/54ByfgmJUMBpCvGovv0AL TwP47+gvdp8YgcxmBsP9h8YImCtArv6i4bKKwgRp/ZLY45Ena8u6S6397GopnOroP0KY WPMpzKMYWaquEaoCc9x0Vxdoglssr29HvhJx+PVfjzGE0rJVuIgQrFclVugrvZFN5U2L srfw== X-Gm-Message-State: AO0yUKWsBQYhqsirVvuIrt5uekHLB8IksRf0Q76PPqvx7qtGKyyK648Z 9CjSy90NIpvpk/FJ0VJm3m4= X-Google-Smtp-Source: AK7set+KhEAx3r4Y9MIM+NVdqGP5VOGZRy6Nk+cs5k+7rrb+TRVpcVOW4MMUPsUfZPMGuLum1I/gzQ== X-Received: by 2002:a05:6870:819d:b0:172:21e9:21c7 with SMTP id k29-20020a056870819d00b0017221e921c7mr13509074oae.40.1678379641913; Thu, 09 Mar 2023 08:34:01 -0800 (PST) Received: from server.roeck-us.net ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id bf7-20020a0568700a0700b0017243e98ce9sm6969444oac.54.2023.03.09.08.34.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Mar 2023 08:34:01 -0800 (PST) Date: Thu, 9 Mar 2023 08:33:59 -0800 From: Guenter Roeck To: "Dixit, Ashutosh" Message-ID: <5d99cb43-4372-43e3-ae38-b45fc21896b4@roeck-us.net> References: <20220812173715.2398586-1-badal.nilawar@intel.com> <20220812173715.2398586-4-badal.nilawar@intel.com> <87wn4132v4.wl-ashutosh.dixit@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wn4132v4.wl-ashutosh.dixit@intel.com> Subject: Re: [Intel-gfx] [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-hwmon@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" 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 > > > > > > Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting. > > > > > /snip/ > > > > > Acked-by: Guenter Roeck > > > > > --- > > > .../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/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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8DDC3C64EC4 for ; Thu, 9 Mar 2023 16:45:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229613AbjCIQpf (ORCPT ); Thu, 9 Mar 2023 11:45:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229611AbjCIQpQ (ORCPT ); Thu, 9 Mar 2023 11:45:16 -0500 Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [IPv6:2001:4860:4864:20::36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACC616E692 for ; Thu, 9 Mar 2023 08:34:02 -0800 (PST) Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-176e43eb199so2872545fac.7 for ; Thu, 09 Mar 2023 08:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678379642; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=kEkr4IaQKiN+bzmiIZcnvGMMGRo7jIir1uiKe1VUqZU=; b=X5SYnXrMqzjgz7pSQ1n/dLxLkITJDxgyHHYSj/ycchtVrh4S7dT7u/jyFQsfE/Jx+h Nkl7p9mvAMmKGB0tyJMD6gj2N55oSzzC1uULgZiKDFHtWDZub+wOlRcVAoMwqIASiRc5 mpZ1JmR0LYRjSVCYCgyWDT2ULe8NRqAOAKoNq1sA3acwapQt6/pIb6eTCJjouziTPIIH E2Z0AivkzUY1yQAABFbslknMES4uL3at0+9Njau2KTx7NgkcxyNrUIR/G+FaSo9ixIBg 08GWJJ/97aFQ4p60DN4LiR9FAdiiURh5iRlPaULzoCZRpZQVdnP/gS+UrFWWLDq4lLKB tdlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678379642; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kEkr4IaQKiN+bzmiIZcnvGMMGRo7jIir1uiKe1VUqZU=; b=q+IDCigigGYr4GL26QIpUIqBXhe6an3mCFw8yb43achgEOP7w3idB98VuKZgYVOlmD n5bs52Yo05mtrwj+N6JCINWTDgD0DKb84v4SaQ5iTmhvsupJE1vNt/o0MaN1htKSJbcY Q/7+dxzw3SkEIVunFbMOKniE1iltHU9rvqY2b8mbLSTSdoxKgYnxne9gFTlKGrQZYw6S +iu7LStyCmi3X6yj69kb76TkRSHtVWQwVapKYVMZnM4HNG1mw4Lh/Y3UmQb1PDWxHRwU OUgbASOqtlqItafnPkT76v+65h9PRlPsJ/84/j31rdenx+bBCsfNxpGfyRo7JM2Ocvwl MqLA== X-Gm-Message-State: AO0yUKV7S9mJUXyPzlDyXq7/g/SIiHetZuYo9qZrgeUMOrTLfVFXTvZx RLKRtG8c5XtPbJWXPqwMTdMoBrUNAXw= X-Google-Smtp-Source: AK7set+KhEAx3r4Y9MIM+NVdqGP5VOGZRy6Nk+cs5k+7rrb+TRVpcVOW4MMUPsUfZPMGuLum1I/gzQ== X-Received: by 2002:a05:6870:819d:b0:172:21e9:21c7 with SMTP id k29-20020a056870819d00b0017221e921c7mr13509074oae.40.1678379641913; Thu, 09 Mar 2023 08:34:01 -0800 (PST) Received: from server.roeck-us.net ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id bf7-20020a0568700a0700b0017243e98ce9sm6969444oac.54.2023.03.09.08.34.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Mar 2023 08:34:01 -0800 (PST) Sender: Guenter Roeck Date: Thu, 9 Mar 2023 08:33:59 -0800 From: Guenter Roeck To: "Dixit, Ashutosh" Cc: Badal Nilawar , intel-gfx@lists.freedesktop.org, linux-hwmon@vger.kernel.org, riana.tauro@intel.com, anshuman.gupta@intel.com, jon.ewins@intel.com, Joonas Lahtinen , dri-devel@lists.freedesktop.org Subject: Re: [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting Message-ID: <5d99cb43-4372-43e3-ae38-b45fc21896b4@roeck-us.net> References: <20220812173715.2398586-1-badal.nilawar@intel.com> <20220812173715.2398586-4-badal.nilawar@intel.com> <87wn4132v4.wl-ashutosh.dixit@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wn4132v4.wl-ashutosh.dixit@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-hwmon@vger.kernel.org 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 > > > > > > Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting. > > > > > /snip/ > > > > > Acked-by: Guenter Roeck > > > > > --- > > > .../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/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