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 X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80787C4743D for ; Fri, 11 Jun 2021 06:55:46 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 498E261364 for ; Fri, 11 Jun 2021 06:55:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 498E261364 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8FE3A6E503; Fri, 11 Jun 2021 06:55:42 +0000 (UTC) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1D0926ED14 for ; Thu, 10 Jun 2021 15:40:58 +0000 (UTC) Received: by mail-oi1-x22a.google.com with SMTP id x196so2556938oif.10 for ; Thu, 10 Jun 2021 08:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jIeOXVZdX3oss7/1RmWBNPIezQSeenQ/7A4FW9ywRDo=; b=AS8+jF/qVkTPU8/koMEES0Y3StOcif6labsTuHWKlsV87lalI6EK6YupX1A8t83FJV CQ8RxtGouzYSsWJQQNszeTqhqrxbM/p/vv2QLT2k+N/tirlWatqUqYXKaka50zMQ+QlP 8sm9ge1jMnNbAa+BG5iyUMqSlxSaH074NH5MJ7Awpg7PogVHgIa1nPFQhseHAfZj39L3 7NmjFg9Z4GS0nfMllprS/NGNJU5GfOgvliaGyUa8sBYAc5lE9B+X/3V1K5/PPxQ3F3WC ySECIccK7K5+N8Siq+GLR/wwA8NWv2xu4S/yWtgvkmZOJqQ29tYelHqFQfOleXe8HctU CaBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jIeOXVZdX3oss7/1RmWBNPIezQSeenQ/7A4FW9ywRDo=; b=Qc/H3u/vdxphpJfw9bPfQNmurLVOIezVvwmAt4v/tn93ISN/PT6KkhAhFxH1BcPUsg grKROvVSfskDqIrkW3nDfJPQvu1klrSscCfwzvujxtpGMF/89ETVAJ3PWrGk2MzZF4Oh xk7RKLtQyfvIxbi6lHiNbkfRh8SKFuXH0UxH1r1JhAxcrHzwqCgrtIoVcb//u84NGlkl avdHQQ+w3FBl2puLSDjY48jLToUDSLNa6Wv8j85s+72O3uFfLw9cfJnovGhpHOUMRNe7 wLz5WSU0cGM9piaP3f6W//yTQz2G9xkZ0P0p5KNFIlEND0anAselI3+5HDC+aTtaqCHZ qWnw== X-Gm-Message-State: AOAM530keSRJ2fPBITd7ZxPXQ3eP1ZlzILy3J1dKjHh3UuTbRiiJy0bl 2vP5Y1xceMGHhqdmE8nfXdM2Vq3RmzUn0r+VABU6+Q== X-Google-Smtp-Source: ABdhPJyqbdXAyn4whN6gEhpiSFX5lOGReknxmYTjBobcqUZp7JqIBse5vTvv4zisINtvdGX+2FwkEMQ+HgVSRrM5yeM= X-Received: by 2002:a54:408b:: with SMTP id i11mr3976129oii.132.1623339657061; Thu, 10 Jun 2021 08:40:57 -0700 (PDT) MIME-Version: 1.0 References: <548dd463-3942-00a1-85c3-232897dea1a3@canonical.com> <162332615476.15946.17135355064135638083@jlahtine-mobl.ger.corp.intel.com> In-Reply-To: <162332615476.15946.17135355064135638083@jlahtine-mobl.ger.corp.intel.com> From: Jesse Barnes Date: Thu, 10 Jun 2021 08:40:45 -0700 Message-ID: Subject: Re: Computation of return value being discarded in get_cpu_power() in drivers/platform/x86/intel_ips.c To: Joonas Lahtinen Content-Type: multipart/alternative; boundary="0000000000009c528c05c46b37e9" X-Mailman-Approved-At: Fri, 11 Jun 2021 06:55:39 +0000 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: Mark Gross , intel-gfx@lists.freedesktop.org, "linux-kernel@vger.kernel.org" , platform-driver-x86@vger.kernel.org, Hans de Goede , "dri-devel@lists.freedesktop.org" , Rodrigo Vivi , Colin Ian King Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --0000000000009c528c05c46b37e9 Content-Type: text/plain; charset="UTF-8" It may be ok to drop this driver entirely now too; I doubt anyone is relying on GPU turbo in Ironlake for anything critical anymore. That would allow for some simplifications in i915 too if it's still supported. Jesse On Thu, Jun 10, 2021 at 4:56 AM Joonas Lahtinen < joonas.lahtinen@linux.intel.com> wrote: > (Address for Hans was corrupt in previous message, which confused my mail > client. Sorry for duplicate message, the other is without From: field). > > + Jesse > > Quoting Colin Ian King (2021-06-09 14:50:07) > > Hi, > > > > I was reviewing some old unassigned variable warnings from static > > analysis by Coverity and found an issue introduced with the following > > commit: > > > > commit aa7ffc01d254c91a36bf854d57a14049c6134c72 > > Author: Jesse Barnes > > Date: Fri May 14 15:41:14 2010 -0700 > > > > x86 platform driver: intelligent power sharing driver > > > > The analysis is as follows: > > > > drivers/platform/x86/intel_ips.c > > > > 871 static u32 get_cpu_power(struct ips_driver *ips, u32 *last, int > period) > > 872 { > > 873 u32 val; > > 874 u32 ret; > > 875 > > 876 /* > > 877 * CEC is in joules/65535. Take difference over time to > > 878 * get watts. > > 879 */ > > 880 val = thm_readl(THM_CEC); > > 881 > > 882 /* period is in ms and we want mW */ > > 883 ret = (((val - *last) * 1000) / period); > > > > Unused value (UNUSED_VALUE) > > assigned_value: Assigning value from ret * 1000U / 65535U to ret here, > > but that stored value is not used. > > > > 884 ret = (ret * 1000) / 65535; > > 885 *last = val; > > 886 > > 887 return 0; > > 888 } > > > > I'm really not sure why ret is being calculated on lines 883,884 and not > > being used. Should that be *last = ret on line 885? Looks suspect anyhow. > > According to git blame code seems to have been disabled intentionally by > the > following commit: > > commit 96f3823f537088c13735cfdfbf284436c802352a > Author: Jesse Barnes > Date: Tue Oct 5 14:50:59 2010 -0400 > > [PATCH 2/2] IPS driver: disable CPU turbo > > The undocumented interface we're using for reading CPU power seems to > be > overreporting power. Until we figure out how to correct it, disable > CPU > turbo and power reporting to be safe. This will keep the CPU within > default > limits and still allow us to increase GPU frequency as needed. > > Maybe wrap the code after thm_readl() in #if 0 in case somebody ends up > wanting to fix it? Or eliminate completely. > > In theory the thm_readl() may affect the system behavior so would not > remove that for extra paranoia. > > Regards, Joonas > > > Colin > > > > > --0000000000009c528c05c46b37e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It may be ok to drop this driver entirely now too; I doubt= anyone is relying on GPU turbo in Ironlake for anything critical anymore.= =C2=A0 That would allow for some simplifications in i915 too if it's st= ill supported.

Jesse

On Thu, Jun 10, 2021 at 4:56 A= M Joonas Lahtinen <jo= onas.lahtinen@linux.intel.com> wrote:
(Address for Hans was corrupt in previous mess= age, which confused my mail
client. Sorry for duplicate message, the other is without From: field).

+ Jesse

Quoting Colin Ian King (2021-06-09 14:50:07)
> Hi,
>
> I was reviewing some old unassigned variable warnings from static
> analysis by Coverity and found an issue introduced with the following<= br> > commit:
>
> commit aa7ffc01d254c91a36bf854d57a14049c6134c72
> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> Date:=C2=A0 =C2=A0Fri May 14 15:41:14 2010 -0700
>
>=C2=A0 =C2=A0 =C2=A0x86 platform driver: intelligent power sharing driv= er
>
> The analysis is as follows:
>
> drivers/platform/x86/intel_ips.c
>
>=C2=A0 871 static u32 get_cpu_power(struct ips_driver *ips, u32 *last, = int period)
>=C2=A0 872 {
>=C2=A0 873=C2=A0 =C2=A0 =C2=A0 =C2=A0 u32 val;
>=C2=A0 874=C2=A0 =C2=A0 =C2=A0 =C2=A0 u32 ret;
>=C2=A0 875
>=C2=A0 876=C2=A0 =C2=A0 =C2=A0 =C2=A0 /*
>=C2=A0 877=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* CEC is in joules/65535.= =C2=A0 Take difference over time to
>=C2=A0 878=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* get watts.
>=C2=A0 879=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
>=C2=A0 880=C2=A0 =C2=A0 =C2=A0 =C2=A0 val =3D thm_readl(THM_CEC);
>=C2=A0 881
>=C2=A0 882=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* period is in ms and we want mW= */
>=C2=A0 883=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret =3D (((val - *last) * 1000) /= period);
>
> Unused value (UNUSED_VALUE)
> assigned_value:=C2=A0 Assigning value from ret * 1000U / 65535U to ret= here,
> but that stored value is not used.
>
>=C2=A0 884=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret =3D (ret * 1000) / 65535;
>=C2=A0 885=C2=A0 =C2=A0 =C2=A0 =C2=A0 *last =3D val;
>=C2=A0 886
>=C2=A0 887=C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;
>=C2=A0 888 }
>
> I'm really not sure why ret is being calculated on lines 883,884 a= nd not
> being used. Should that be *last =3D ret on line 885? Looks suspect an= yhow.

According to git blame code seems to have been disabled intentionally by th= e
following commit:

commit 96f3823f537088c13735cfdfbf284436c802352a
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:=C2=A0 =C2=A0Tue Oct 5 14:50:59 2010 -0400

=C2=A0 =C2=A0 [PATCH 2/2] IPS driver: disable CPU turbo

=C2=A0 =C2=A0 The undocumented interface we're using for reading CPU po= wer seems to be
=C2=A0 =C2=A0 overreporting power.=C2=A0 Until we figure out how to correct= it, disable CPU
=C2=A0 =C2=A0 turbo and power reporting to be safe.=C2=A0 This will keep th= e CPU within default
=C2=A0 =C2=A0 limits and still allow us to increase GPU frequency as needed= .

Maybe wrap the code after thm_readl() in #if 0 in case somebody ends up
wanting to fix it? Or eliminate completely.

In theory the thm_readl() may affect the system behavior so would not
remove that for extra paranoia.

Regards, Joonas

> Colin
>
>
--0000000000009c528c05c46b37e9-- 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 X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,SPF_HELO_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA911C47094 for ; Thu, 10 Jun 2021 15:47:08 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id A3A7E613D8 for ; Thu, 10 Jun 2021 15:47:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A3A7E613D8 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 174C56ED64; Thu, 10 Jun 2021 15:47:08 +0000 (UTC) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) by gabe.freedesktop.org (Postfix) with ESMTPS id 053276E49B for ; Thu, 10 Jun 2021 15:40:57 +0000 (UTC) Received: by mail-oi1-x234.google.com with SMTP id t140so2604270oih.0 for ; Thu, 10 Jun 2021 08:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jIeOXVZdX3oss7/1RmWBNPIezQSeenQ/7A4FW9ywRDo=; b=AS8+jF/qVkTPU8/koMEES0Y3StOcif6labsTuHWKlsV87lalI6EK6YupX1A8t83FJV CQ8RxtGouzYSsWJQQNszeTqhqrxbM/p/vv2QLT2k+N/tirlWatqUqYXKaka50zMQ+QlP 8sm9ge1jMnNbAa+BG5iyUMqSlxSaH074NH5MJ7Awpg7PogVHgIa1nPFQhseHAfZj39L3 7NmjFg9Z4GS0nfMllprS/NGNJU5GfOgvliaGyUa8sBYAc5lE9B+X/3V1K5/PPxQ3F3WC ySECIccK7K5+N8Siq+GLR/wwA8NWv2xu4S/yWtgvkmZOJqQ29tYelHqFQfOleXe8HctU CaBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jIeOXVZdX3oss7/1RmWBNPIezQSeenQ/7A4FW9ywRDo=; b=V5QdzpDGB3B/LlmQTDN0cCEJnYOZMFbCH0T8QlMFgVQKqqPbcMQ+xs+TJOeRef0ILW 9mN3biMKO9E9mRb2eEpBfVSNJiWv/RyvCUEaDF+KsO5hBroPimnbaA/jTNVStzhO5iKV y6/scAfy9Vv7pL6uiGm9k2ouhD+fHyL6EtA9mhjpXgJEKHJDtMTQWLSFOWRQSjiItr/a Ou2YIrS9qJK7uBa4NpfmwcxZbfKYRrpggITZu3EoYQyNHnf2tp3KynusFJ+0rdPRreub A1heomf/UTvRNUmuBIDgmF1lt2lpV6UKrgqvpIKatBcrFNs2wToaY3vcY41yW5Ytotg+ zvaA== X-Gm-Message-State: AOAM53058qOC4Gl4QyMufm5mLveanRsPYXPk7KpO/pkacfHNtwjbLqOu QNyiJymyI36uRhpLlRFQOr8VohsI+pxy9uLUMoNUUQ== X-Google-Smtp-Source: ABdhPJyqbdXAyn4whN6gEhpiSFX5lOGReknxmYTjBobcqUZp7JqIBse5vTvv4zisINtvdGX+2FwkEMQ+HgVSRrM5yeM= X-Received: by 2002:a54:408b:: with SMTP id i11mr3976129oii.132.1623339657061; Thu, 10 Jun 2021 08:40:57 -0700 (PDT) MIME-Version: 1.0 References: <548dd463-3942-00a1-85c3-232897dea1a3@canonical.com> <162332615476.15946.17135355064135638083@jlahtine-mobl.ger.corp.intel.com> In-Reply-To: <162332615476.15946.17135355064135638083@jlahtine-mobl.ger.corp.intel.com> From: Jesse Barnes Date: Thu, 10 Jun 2021 08:40:45 -0700 Message-ID: To: Joonas Lahtinen X-Mailman-Approved-At: Thu, 10 Jun 2021 15:47:07 +0000 Subject: Re: [Intel-gfx] Computation of return value being discarded in get_cpu_power() in drivers/platform/x86/intel_ips.c 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: Mark Gross , intel-gfx@lists.freedesktop.org, "linux-kernel@vger.kernel.org" , platform-driver-x86@vger.kernel.org, "dri-devel@lists.freedesktop.org" , Colin Ian King Content-Type: multipart/mixed; boundary="===============1214586668==" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" --===============1214586668== Content-Type: multipart/alternative; boundary="0000000000009c528c05c46b37e9" --0000000000009c528c05c46b37e9 Content-Type: text/plain; charset="UTF-8" It may be ok to drop this driver entirely now too; I doubt anyone is relying on GPU turbo in Ironlake for anything critical anymore. That would allow for some simplifications in i915 too if it's still supported. Jesse On Thu, Jun 10, 2021 at 4:56 AM Joonas Lahtinen < joonas.lahtinen@linux.intel.com> wrote: > (Address for Hans was corrupt in previous message, which confused my mail > client. Sorry for duplicate message, the other is without From: field). > > + Jesse > > Quoting Colin Ian King (2021-06-09 14:50:07) > > Hi, > > > > I was reviewing some old unassigned variable warnings from static > > analysis by Coverity and found an issue introduced with the following > > commit: > > > > commit aa7ffc01d254c91a36bf854d57a14049c6134c72 > > Author: Jesse Barnes > > Date: Fri May 14 15:41:14 2010 -0700 > > > > x86 platform driver: intelligent power sharing driver > > > > The analysis is as follows: > > > > drivers/platform/x86/intel_ips.c > > > > 871 static u32 get_cpu_power(struct ips_driver *ips, u32 *last, int > period) > > 872 { > > 873 u32 val; > > 874 u32 ret; > > 875 > > 876 /* > > 877 * CEC is in joules/65535. Take difference over time to > > 878 * get watts. > > 879 */ > > 880 val = thm_readl(THM_CEC); > > 881 > > 882 /* period is in ms and we want mW */ > > 883 ret = (((val - *last) * 1000) / period); > > > > Unused value (UNUSED_VALUE) > > assigned_value: Assigning value from ret * 1000U / 65535U to ret here, > > but that stored value is not used. > > > > 884 ret = (ret * 1000) / 65535; > > 885 *last = val; > > 886 > > 887 return 0; > > 888 } > > > > I'm really not sure why ret is being calculated on lines 883,884 and not > > being used. Should that be *last = ret on line 885? Looks suspect anyhow. > > According to git blame code seems to have been disabled intentionally by > the > following commit: > > commit 96f3823f537088c13735cfdfbf284436c802352a > Author: Jesse Barnes > Date: Tue Oct 5 14:50:59 2010 -0400 > > [PATCH 2/2] IPS driver: disable CPU turbo > > The undocumented interface we're using for reading CPU power seems to > be > overreporting power. Until we figure out how to correct it, disable > CPU > turbo and power reporting to be safe. This will keep the CPU within > default > limits and still allow us to increase GPU frequency as needed. > > Maybe wrap the code after thm_readl() in #if 0 in case somebody ends up > wanting to fix it? Or eliminate completely. > > In theory the thm_readl() may affect the system behavior so would not > remove that for extra paranoia. > > Regards, Joonas > > > Colin > > > > > --0000000000009c528c05c46b37e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It may be ok to drop this driver entirely now too; I doubt= anyone is relying on GPU turbo in Ironlake for anything critical anymore.= =C2=A0 That would allow for some simplifications in i915 too if it's st= ill supported.

Jesse

On Thu, Jun 10, 2021 at 4:56 A= M Joonas Lahtinen <jo= onas.lahtinen@linux.intel.com> wrote:
(Address for Hans was corrupt in previous mess= age, which confused my mail
client. Sorry for duplicate message, the other is without From: field).

+ Jesse

Quoting Colin Ian King (2021-06-09 14:50:07)
> Hi,
>
> I was reviewing some old unassigned variable warnings from static
> analysis by Coverity and found an issue introduced with the following<= br> > commit:
>
> commit aa7ffc01d254c91a36bf854d57a14049c6134c72
> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> Date:=C2=A0 =C2=A0Fri May 14 15:41:14 2010 -0700
>
>=C2=A0 =C2=A0 =C2=A0x86 platform driver: intelligent power sharing driv= er
>
> The analysis is as follows:
>
> drivers/platform/x86/intel_ips.c
>
>=C2=A0 871 static u32 get_cpu_power(struct ips_driver *ips, u32 *last, = int period)
>=C2=A0 872 {
>=C2=A0 873=C2=A0 =C2=A0 =C2=A0 =C2=A0 u32 val;
>=C2=A0 874=C2=A0 =C2=A0 =C2=A0 =C2=A0 u32 ret;
>=C2=A0 875
>=C2=A0 876=C2=A0 =C2=A0 =C2=A0 =C2=A0 /*
>=C2=A0 877=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* CEC is in joules/65535.= =C2=A0 Take difference over time to
>=C2=A0 878=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* get watts.
>=C2=A0 879=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
>=C2=A0 880=C2=A0 =C2=A0 =C2=A0 =C2=A0 val =3D thm_readl(THM_CEC);
>=C2=A0 881
>=C2=A0 882=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* period is in ms and we want mW= */
>=C2=A0 883=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret =3D (((val - *last) * 1000) /= period);
>
> Unused value (UNUSED_VALUE)
> assigned_value:=C2=A0 Assigning value from ret * 1000U / 65535U to ret= here,
> but that stored value is not used.
>
>=C2=A0 884=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret =3D (ret * 1000) / 65535;
>=C2=A0 885=C2=A0 =C2=A0 =C2=A0 =C2=A0 *last =3D val;
>=C2=A0 886
>=C2=A0 887=C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;
>=C2=A0 888 }
>
> I'm really not sure why ret is being calculated on lines 883,884 a= nd not
> being used. Should that be *last =3D ret on line 885? Looks suspect an= yhow.

According to git blame code seems to have been disabled intentionally by th= e
following commit:

commit 96f3823f537088c13735cfdfbf284436c802352a
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:=C2=A0 =C2=A0Tue Oct 5 14:50:59 2010 -0400

=C2=A0 =C2=A0 [PATCH 2/2] IPS driver: disable CPU turbo

=C2=A0 =C2=A0 The undocumented interface we're using for reading CPU po= wer seems to be
=C2=A0 =C2=A0 overreporting power.=C2=A0 Until we figure out how to correct= it, disable CPU
=C2=A0 =C2=A0 turbo and power reporting to be safe.=C2=A0 This will keep th= e CPU within default
=C2=A0 =C2=A0 limits and still allow us to increase GPU frequency as needed= .

Maybe wrap the code after thm_readl() in #if 0 in case somebody ends up
wanting to fix it? Or eliminate completely.

In theory the thm_readl() may affect the system behavior so would not
remove that for extra paranoia.

Regards, Joonas

> Colin
>
>
--0000000000009c528c05c46b37e9-- --===============1214586668== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============1214586668==--