From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Use functions common with sysfs to read actual freq
Date: Thu, 09 Mar 2023 17:03:12 -0800 [thread overview]
Message-ID: <877cvpmn8v.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <f7508e19-3d66-d72c-f2cf-f5810ec48c94@linux.intel.com>
On Thu, 09 Mar 2023 01:20:09 -0800, Tvrtko Ursulin wrote:
>
Hi Tvrtko,
> On 09/03/2023 03:46, Ashutosh Dixit wrote:
> > Expose intel_rps_read_actual_frequency_fw to read the actual freq without
> > taking forcewake for use by PMU. The code is refactored to use a common set
> > of functions across sysfs and PMU. Using common functions with sysfs in PMU
> > solves the issues of missing support for MTL and missing support for older
> > generations (prior to Gen6). It also future proofs the PMU where sometimes
> > code has been updated for sysfs and PMU has been missed.
> >
> > Fixes: 22009b6dad66 ("drm/i915/mtl: Modify CAGF functions for MTL")
>
> So not DG1 and above?
The issue for DG1+ happens if non-freq bits are non-zero but freq bits are
zero. But we've already seen that during PMU freq sampling gt is unparked
so freq bits being 0 is rare. Therefore IMO there is 0 practical impact of
that bug, I don't think it's worth fixing it and Cc'ing stable etc. (also
those platforms are under force probe).
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8280
> > Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > ---
> > drivers/gpu/drm/i915/gt/intel_rps.c | 46 +++++++++++++++++++----------
> > drivers/gpu/drm/i915/gt/intel_rps.h | 2 +-
> > drivers/gpu/drm/i915/i915_pmu.c | 10 +++----
> > 3 files changed, 36 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
> > index 4d0dc9de23f9..3957c5ee5cba 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> > @@ -2046,16 +2046,6 @@ void intel_rps_sanitize(struct intel_rps *rps)
> > rps_disable_interrupts(rps);
> > }
> > -u32 intel_rps_read_rpstat_fw(struct intel_rps *rps)
> > -{
> > - struct drm_i915_private *i915 = rps_to_i915(rps);
> > - i915_reg_t rpstat;
> > -
> > - rpstat = (GRAPHICS_VER(i915) >= 12) ? GEN12_RPSTAT1 : GEN6_RPSTAT1;
> > -
> > - return intel_uncore_read_fw(rps_to_gt(rps)->uncore, rpstat);
> > -}
> > -
> > u32 intel_rps_read_rpstat(struct intel_rps *rps)
> > {
> > struct drm_i915_private *i915 = rps_to_i915(rps);
> > @@ -2089,10 +2079,11 @@ u32 intel_rps_get_cagf(struct intel_rps *rps, u32 rpstat)
> > return cagf;
> > }
> > -static u32 read_cagf(struct intel_rps *rps)
> > +static u32 __read_cagf(struct intel_rps *rps, bool take_fw)
> > {
> > struct drm_i915_private *i915 = rps_to_i915(rps);
> > struct intel_uncore *uncore = rps_to_uncore(rps);
> > + i915_reg_t r = INVALID_MMIO_REG;
> > u32 freq;
> > /*
> > @@ -2100,22 +2091,30 @@ static u32 read_cagf(struct intel_rps *rps)
> > * registers will return 0 freq when GT is in RC6
> > */
> > if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
> > - freq = intel_uncore_read(uncore, MTL_MIRROR_TARGET_WP1);
> > + r = MTL_MIRROR_TARGET_WP1;
> > } else if (GRAPHICS_VER(i915) >= 12) {
> > - freq = intel_uncore_read(uncore, GEN12_RPSTAT1);
> > + r = GEN12_RPSTAT1;
> > } else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
> > vlv_punit_get(i915);
> > freq = vlv_punit_read(i915, PUNIT_REG_GPU_FREQ_STS);
> > vlv_punit_put(i915);
> > + goto exit;
> > } else if (GRAPHICS_VER(i915) >= 6) {
> > - freq = intel_uncore_read(uncore, GEN6_RPSTAT1);
> > + r = GEN6_RPSTAT1;
> > } else {
> > - freq = intel_uncore_read(uncore, MEMSTAT_ILK);
> > + r = MEMSTAT_ILK;
> > }
> > + freq = take_fw ? intel_uncore_read(uncore, r) :
> > intel_uncore_read_fw(uncore, r);
> > +exit:
> > return intel_rps_get_cagf(rps, freq);
> > }
> > +static u32 read_cagf(struct intel_rps *rps)
> > +{
> > + return __read_cagf(rps, true);
> > +}
> > +
> > u32 intel_rps_read_actual_frequency(struct intel_rps *rps)
> > {
> > struct intel_runtime_pm *rpm = rps_to_uncore(rps)->rpm;
> > @@ -2128,6 +2127,23 @@ u32 intel_rps_read_actual_frequency(struct intel_rps *rps)
> > return freq;
> > }
> > +static u32 read_cagf_fw(struct intel_rps *rps)
> > +{
> > + return __read_cagf(rps, false);
> > +}
> > +
> > +u32 intel_rps_read_actual_frequency_fw(struct intel_rps *rps)
> > +{
> > + struct intel_runtime_pm *rpm = rps_to_uncore(rps)->rpm;
> > + intel_wakeref_t wakeref;
> > + u32 freq = 0;
> > +
> > + with_intel_runtime_pm_if_in_use(rpm, wakeref)
>
> When called from i915_pmu.c::frequency sample() above seems redundant since
> there we already are under intel_gt_pm_get_if_awake. Perhaps it is not a
> huge deal but it is nevertheless wasteful.
>
> Also, maybe I am a bit rusty, but more fundamentally, wouldn't this be
> adding a _very_ atypical pattern of a _fw function which grabs rpm? I'd
> expect they all assume it's already held since the forcewake is already
> held.
>
> Am I missing the reason why it is needed?
Thanks for catching this, you are right, it was just mindless copy paste,
I've dropped it in the next version.
Thanks.
--
Ashutosh
WARNING: multiple messages have this Message-ID (diff)
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>,
intel-gfx@lists.freedesktop.org,
Badal Nilawar <badal.nilawar@intel.com>,
dri-devel@lists.freedesktop.org,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH 1/2] drm/i915/pmu: Use functions common with sysfs to read actual freq
Date: Thu, 09 Mar 2023 17:03:12 -0800 [thread overview]
Message-ID: <877cvpmn8v.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <f7508e19-3d66-d72c-f2cf-f5810ec48c94@linux.intel.com>
On Thu, 09 Mar 2023 01:20:09 -0800, Tvrtko Ursulin wrote:
>
Hi Tvrtko,
> On 09/03/2023 03:46, Ashutosh Dixit wrote:
> > Expose intel_rps_read_actual_frequency_fw to read the actual freq without
> > taking forcewake for use by PMU. The code is refactored to use a common set
> > of functions across sysfs and PMU. Using common functions with sysfs in PMU
> > solves the issues of missing support for MTL and missing support for older
> > generations (prior to Gen6). It also future proofs the PMU where sometimes
> > code has been updated for sysfs and PMU has been missed.
> >
> > Fixes: 22009b6dad66 ("drm/i915/mtl: Modify CAGF functions for MTL")
>
> So not DG1 and above?
The issue for DG1+ happens if non-freq bits are non-zero but freq bits are
zero. But we've already seen that during PMU freq sampling gt is unparked
so freq bits being 0 is rare. Therefore IMO there is 0 practical impact of
that bug, I don't think it's worth fixing it and Cc'ing stable etc. (also
those platforms are under force probe).
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8280
> > Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > ---
> > drivers/gpu/drm/i915/gt/intel_rps.c | 46 +++++++++++++++++++----------
> > drivers/gpu/drm/i915/gt/intel_rps.h | 2 +-
> > drivers/gpu/drm/i915/i915_pmu.c | 10 +++----
> > 3 files changed, 36 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
> > index 4d0dc9de23f9..3957c5ee5cba 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> > @@ -2046,16 +2046,6 @@ void intel_rps_sanitize(struct intel_rps *rps)
> > rps_disable_interrupts(rps);
> > }
> > -u32 intel_rps_read_rpstat_fw(struct intel_rps *rps)
> > -{
> > - struct drm_i915_private *i915 = rps_to_i915(rps);
> > - i915_reg_t rpstat;
> > -
> > - rpstat = (GRAPHICS_VER(i915) >= 12) ? GEN12_RPSTAT1 : GEN6_RPSTAT1;
> > -
> > - return intel_uncore_read_fw(rps_to_gt(rps)->uncore, rpstat);
> > -}
> > -
> > u32 intel_rps_read_rpstat(struct intel_rps *rps)
> > {
> > struct drm_i915_private *i915 = rps_to_i915(rps);
> > @@ -2089,10 +2079,11 @@ u32 intel_rps_get_cagf(struct intel_rps *rps, u32 rpstat)
> > return cagf;
> > }
> > -static u32 read_cagf(struct intel_rps *rps)
> > +static u32 __read_cagf(struct intel_rps *rps, bool take_fw)
> > {
> > struct drm_i915_private *i915 = rps_to_i915(rps);
> > struct intel_uncore *uncore = rps_to_uncore(rps);
> > + i915_reg_t r = INVALID_MMIO_REG;
> > u32 freq;
> > /*
> > @@ -2100,22 +2091,30 @@ static u32 read_cagf(struct intel_rps *rps)
> > * registers will return 0 freq when GT is in RC6
> > */
> > if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
> > - freq = intel_uncore_read(uncore, MTL_MIRROR_TARGET_WP1);
> > + r = MTL_MIRROR_TARGET_WP1;
> > } else if (GRAPHICS_VER(i915) >= 12) {
> > - freq = intel_uncore_read(uncore, GEN12_RPSTAT1);
> > + r = GEN12_RPSTAT1;
> > } else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
> > vlv_punit_get(i915);
> > freq = vlv_punit_read(i915, PUNIT_REG_GPU_FREQ_STS);
> > vlv_punit_put(i915);
> > + goto exit;
> > } else if (GRAPHICS_VER(i915) >= 6) {
> > - freq = intel_uncore_read(uncore, GEN6_RPSTAT1);
> > + r = GEN6_RPSTAT1;
> > } else {
> > - freq = intel_uncore_read(uncore, MEMSTAT_ILK);
> > + r = MEMSTAT_ILK;
> > }
> > + freq = take_fw ? intel_uncore_read(uncore, r) :
> > intel_uncore_read_fw(uncore, r);
> > +exit:
> > return intel_rps_get_cagf(rps, freq);
> > }
> > +static u32 read_cagf(struct intel_rps *rps)
> > +{
> > + return __read_cagf(rps, true);
> > +}
> > +
> > u32 intel_rps_read_actual_frequency(struct intel_rps *rps)
> > {
> > struct intel_runtime_pm *rpm = rps_to_uncore(rps)->rpm;
> > @@ -2128,6 +2127,23 @@ u32 intel_rps_read_actual_frequency(struct intel_rps *rps)
> > return freq;
> > }
> > +static u32 read_cagf_fw(struct intel_rps *rps)
> > +{
> > + return __read_cagf(rps, false);
> > +}
> > +
> > +u32 intel_rps_read_actual_frequency_fw(struct intel_rps *rps)
> > +{
> > + struct intel_runtime_pm *rpm = rps_to_uncore(rps)->rpm;
> > + intel_wakeref_t wakeref;
> > + u32 freq = 0;
> > +
> > + with_intel_runtime_pm_if_in_use(rpm, wakeref)
>
> When called from i915_pmu.c::frequency sample() above seems redundant since
> there we already are under intel_gt_pm_get_if_awake. Perhaps it is not a
> huge deal but it is nevertheless wasteful.
>
> Also, maybe I am a bit rusty, but more fundamentally, wouldn't this be
> adding a _very_ atypical pattern of a _fw function which grabs rpm? I'd
> expect they all assume it's already held since the forcewake is already
> held.
>
> Am I missing the reason why it is needed?
Thanks for catching this, you are right, it was just mindless copy paste,
I've dropped it in the next version.
Thanks.
--
Ashutosh
next prev parent reply other threads:[~2023-03-10 1:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-09 3:46 [Intel-gfx] [PATCH 0/2] drm/i915/pmu: Use common freq functions with sysfs Ashutosh Dixit
2023-03-09 3:46 ` Ashutosh Dixit
2023-03-09 3:46 ` [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Use functions common with sysfs to read actual freq Ashutosh Dixit
2023-03-09 3:46 ` Ashutosh Dixit
2023-03-09 9:20 ` [Intel-gfx] " Tvrtko Ursulin
2023-03-09 9:20 ` Tvrtko Ursulin
2023-03-10 1:03 ` Dixit, Ashutosh [this message]
2023-03-10 1:03 ` Dixit, Ashutosh
2023-03-09 3:46 ` [Intel-gfx] [PATCH 2/2] drm/i915/pmu: Remove fallback to requested freq for SLPC Ashutosh Dixit
2023-03-09 3:46 ` Ashutosh Dixit
2023-03-09 4:03 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pmu: Use common freq functions with sysfs (rev2) Patchwork
2023-03-09 4:27 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-03-10 18:01 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2023-03-10 0:59 [Intel-gfx] [PATCH 0/2] drm/i915/pmu: Use common freq functions with sysfs Ashutosh Dixit
2023-03-10 0:59 ` [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Use functions common with sysfs to read actual freq Ashutosh Dixit
2023-03-15 9:43 ` Tvrtko Ursulin
2023-03-16 0:53 ` Dixit, Ashutosh
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=877cvpmn8v.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rodrigo.vivi@intel.com \
--cc=tvrtko.ursulin@linux.intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.