public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
To: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler
Date: Mon, 31 Oct 2022 08:37:59 +0200	[thread overview]
Message-ID: <49a3db03-a62c-374d-76cd-8557c761f18b@intel.com> (raw)
In-Reply-To: <878rkwefji.wl-ashutosh.dixit@intel.com>



On 10/31/22 7:19 AM, Dixit, Ashutosh wrote:
> On Fri, 28 Oct 2022 21:42:30 -0700, Gwan-gyeong Mun wrote:
>>
>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
>> index 9e9781493025..c588a17f97e9 100644
>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>>
>>   static void
>>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>> -			  u32 field_msk, int nshift,
>> -			  unsigned int scale_factor, long lval)
>> +			  int nshift, unsigned int scale_factor, long lval)
>>   {
>> 	u32 nval;
>> -	u32 bits_to_clear;
>> -	u32 bits_to_set;
>>
>> 	/* Computation in 64-bits to avoid overflow. Round to nearest. */
>> 	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>
>> -	bits_to_clear = field_msk;
>> -	bits_to_set = FIELD_PREP(field_msk, nval);
>> -
>> 	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>> -					    bits_to_clear, bits_to_set);
>> +					    PKG_PWR_LIM_1,
>> +					    REG_FIELD_PREP(PKG_PWR_LIM_1, nval));
> 
> I registered my objection to this patch already here:
> 
> https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.dixit@intel.com/
> 
> the crux of which is "hwm_field_scale_and_write() pairs with
> hwm_field_read_and_scale() (they are basically a set/get pair) so it is
> desirable they have identical arguments. This patch breaks that symmetry".
> 
> We can merge this patch now but the moment a second caller of
> hwm_field_scale_and_write arrives this patch will need to be reverted.
> 
> I have also posted my preferred way (as I previously indiecated) of fixing
> this issue here (if this needs to be fixed in i915):
> 
> https://patchwork.freedesktop.org/series/110301/
> 
The given link (https://patchwork.freedesktop.org/series/110301/) is an 
inline function that reduces the checks of REG_FIELD_PREP() and pursues 
the same functionality.
It's not a good idea to add and use duplicate new inline functions with 
reduced functionality under different names.

+/* FIELD_PREP and REG_FIELD_PREP require a compile time constant mask */
+static u32 hwm_field_prep(u32 mask, u32 val)
+{
+	return (val << __bf_shf(mask)) & mask;
+}
+
  static void
  hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
  				    i915_reg_t reg, u32 clear, u32 set)
@@ -112,7 +118,7 @@  hwm_field_scale_and_write(struct hwm_drvdata *ddat, 
i915_reg_t rgadr,
  	nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);

  	bits_to_clear = field_msk;
-	bits_to_set = FIELD_PREP(field_msk, nval);
+	bits_to_set = hwm_field_prep(field_msk, nval);

  	hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
  					    bits_to_clear, bits_to_set);


The patch 
(https://patchwork.freedesktop.org/patch/509248/?series=110094&rev=5) 
that fixed the build error in a simplified form was added as there is 
only one place that calls the hwm_field_scale_and_write() function at 
this time.

If more places that use the hwm_field_scale_and_write() function are 
added in the future, how about changing the interface that calls this 
function as Jani previously suggested?

Br,
G.G.

> IMO it would be a mistake to use REG_FIELD_PREP or FIELD_PREP here since
> here the mask comes in as a function argument whereas REG_FIELD_PREP and
> FIELD_PREP require that mask to be a compile time constant.
> 
> Thanks.
> --
> Ashutosh

  reply	other threads:[~2022-10-31  6:38 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-24 21:09 [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
2022-10-25  1:34 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2022-10-25  1:57 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-10-25  3:14 ` [Intel-gfx] [PATCH] " Dixit, Ashutosh
2022-10-25  9:25   ` Andi Shyti
2022-10-25 16:46     ` Nick Desaulniers
2022-10-25 18:45     ` Dixit, Ashutosh
2022-10-26  0:18       ` Andi Shyti
2022-10-27 16:35         ` Nick Desaulniers
2022-10-27 16:53           ` Dixit, Ashutosh
2022-10-27 17:16             ` Nick Desaulniers
2022-10-27 18:32               ` Dixit, Ashutosh
2022-10-28  6:26                 ` Gwan-gyeong Mun
2022-10-28  6:43                 ` Gwan-gyeong Mun
2022-10-28  8:46                   ` Jani Nikula
2022-11-02  6:32                     ` Joonas Lahtinen
2022-11-02 10:41                       ` Gwan-gyeong Mun
2022-10-25  9:15 ` Andi Shyti
2022-10-25 14:27 ` Jani Nikula
2022-10-25 14:30   ` Jani Nikula
2022-10-25 18:46     ` Dixit, Ashutosh
2022-10-27 17:54 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev2) Patchwork
2022-10-28  6:30 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev3) Patchwork
2022-10-28  6:48 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev4) Patchwork
2022-10-29  4:42 ` [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler Gwan-gyeong Mun
2022-10-31  5:19   ` Dixit, Ashutosh
2022-10-31  6:37     ` Gwan-gyeong Mun [this message]
2022-10-31 17:31       ` Dixit, Ashutosh
2022-11-01 10:35         ` Jani Nikula
2022-11-02  7:12   ` Dixit, Ashutosh
2022-11-02  8:50     ` Jani Nikula
2022-10-29  5:00 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/hwmon: Fix a build error used with clang compiler (rev5) Patchwork
2022-10-29  5:32 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-10-29 15:32 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

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=49a3db03-a62c-374d-76cd-8557c761f18b@intel.com \
    --to=gwan-gyeong.mun@intel.com \
    --cc=ashutosh.dixit@intel.com \
    --cc=intel-gfx@lists.freedesktop.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