From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Gwan-gyeong Mun <gwan-gyeong.mun@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 10:31:22 -0700 [thread overview]
Message-ID: <871qqnew7p.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <49a3db03-a62c-374d-76cd-8557c761f18b@intel.com>
On Sun, 30 Oct 2022 23:37:59 -0700, Gwan-gyeong Mun wrote:
>
Hi GG,
> 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.
See if you like v2 better :-)
> +/* 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?
Sorry, which interface change which Jani suggested are you referring to? I
don't recall seeing anything but maybe I am mistaken.
Thanks.
--
Ashutosh
> > 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.
next prev parent reply other threads:[~2022-10-31 17:31 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
2022-10-31 17:31 ` Dixit, Ashutosh [this message]
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=871qqnew7p.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=gwan-gyeong.mun@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