Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Summers, Stuart" <stuart.summers@intel.com>
To: "De Marchi, Lucas" <lucas.demarchi@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"Vivi,  Rodrigo" <rodrigo.vivi@intel.com>,
	"Roper, Matthew D" <matthew.d.roper@intel.com>,
	"Belgaumkar, Vinay" <vinay.belgaumkar@intel.com>
Subject: Re: [PATCH v3 1/4] drm/xe/bmg: Update Wa_14022085890
Date: Wed, 11 Jun 2025 22:44:05 +0000	[thread overview]
Message-ID: <b6bf6cfe1dfdb08dc6992c6ab01f5035922d5e7e.camel@intel.com> (raw)
In-Reply-To: <c2dg4jybyfkmxgwpydvchso5bdpv46gpqat7zcjdrwcrjwjx7x@zxdu4py4iyki>

On Fri, 2025-06-06 at 19:09 -0500, Lucas De Marchi wrote:
> On Wed, Jun 04, 2025 at 12:06:52AM +0000, Stuart Summers wrote:
> > On Tue, 2025-06-03 at 13:31 -0700, Belgaumkar, Vinay wrote:
> > > 
> > > On 6/3/2025 12:31 PM, Summers, Stuart wrote:
> > > > On Tue, 2025-06-03 at 11:41 -0700, Belgaumkar, Vinay wrote:
> > > > > On 6/3/2025 10:36 AM, Summers, Stuart wrote:
> > > > > > On Mon, 2025-06-02 at 16:44 -0700, Vinay Belgaumkar wrote:
> > > > > > > Set GT min frequency to 1200Mhz once driver load is
> > > > > > > complete.
> > > > > > > 
> > > > > > > v2: Review comments (Rodrigo)
> > > > > > > v3: Apply Wa earlier so user_req_min is not clobbered.
> > > > > > > 
> > > > > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > Signed-off-by: Vinay Belgaumkar
> > > > > > > <vinay.belgaumkar@intel.com>
> > > > > > > ---
> > > > > > >    drivers/gpu/drm/xe/xe_guc_pc.c     | 5 +++++
> > > > > > >    drivers/gpu/drm/xe/xe_wa_oob.rules | 1 +
> > > > > > >    2 files changed, 6 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/xe/xe_guc_pc.c
> > > > > > > b/drivers/gpu/drm/xe/xe_guc_pc.c
> > > > > > > index 18c623992035..cb0563494fcc 100644
> > > > > > > --- a/drivers/gpu/drm/xe/xe_guc_pc.c
> > > > > > > +++ b/drivers/gpu/drm/xe/xe_guc_pc.c
> > > > > > > @@ -51,6 +51,7 @@
> > > > > > >   
> > > > > > >    #define LNL_MERT_FREQ_CAP      800
> > > > > > >    #define BMG_MERT_FREQ_CAP      2133
> > > > > > > +#define BMG_MIN_FREQ           1200
> > > > > > >   
> > > > > > >    #define SLPC_RESET_TIMEOUT_MS 5 /* roughly 5ms, but no
> > > > > > > need for
> > > > > > > precision */
> > > > > > >    #define SLPC_RESET_EXTENDED_TIMEOUT_MS 1000 /* To be
> > > > > > > used
> > > > > > > only
> > > > > > > at
> > > > > > > pc_start */
> > > > > > > @@ -843,6 +844,9 @@ static int
> > > > > > > pc_adjust_freq_bounds(struct
> > > > > > > xe_guc_pc
> > > > > > > *pc)
> > > > > > >           if (pc_get_min_freq(pc) > pc->rp0_freq)
> > > > > > >                   ret = pc_set_min_freq(pc, pc-
> > > > > > > >rp0_freq);
> > > > > > >   
> > > > > > > +       if (XE_WA(pc_to_gt(pc), 14022085890))
> > > > > > > +               ret = pc_set_min_freq(pc,
> > > > > > > max(BMG_MIN_FREQ,
> > > > > > > pc_get_min_freq(pc)));
> > > > > > Do we want this above the get_min_freq() call above? Seems
> > > > > > like
> > > > > > that
> > > > > > would further limit which is what we'd want in that case
> > > > > > right?
> > > > > No, this is during SLPC init, we don't need to read the min
> > > > > freq
> > > > > at
> > > > > this
> > > > > point. We will adjust it later in the flow if there was a
> > > > > user
> > > > > request.
> > > 
> > > This ensures min frequency is set to 1200. That is required by
> > > the
> > > WA.
> > > If there was no previous user request (like before a GT reset),
> > > the
> > > min
> > > will be set to 1200 instead of the usual RPe (which is around
> > > 500).
> > 
> > Ok makes sense to me. I did confirm the workaround frequency called
> > out
> > in bspec matches here:
> > Reviewed-by: Stuart Summers <stuart.summers@intel.com>
> 
> but why do we do 2 rmw instead of 1? Something like this
> 
>         u32 min_freq;
>         ...
> 
>         /*
>          * Same thing happens for Server platforms where min is
> listed as
>          * RPMax
>          */
>         min_freq = min(pc_get_min_freq(pc), pc->rp0_freq);
> 
>         /* But shouldn't go to less than BMG_MIN_FREQ on affected
> platforms */
>         if (XE_WA(pc_to_gt(pc), 14022085890))
>                 min_freq = max(BMG_MIN_FREQ, min_freq);
> 
>         ret = pc_set_min_freq(pc, min_freq);

I agree this is much cleaner. Vinay can you comment here?

Thanks,
Stuart

> 
> > 
> > > 
> > > Thanks,
> > > 
> > > Vinay.
> > > 
> > > > So then what is the purpose of the code just above this?
> > > > 
> > > > -Stuart
> > > > 
> > > > > Thanks,
> > > > > 
> > > > > Vinay.
> > > > > 
> > > > > > Thanks,
> > > > > > Stuart
> > > > > > 
> > > > > > > +
> > > > > > >    out:
> > > > > > >           return ret;
> > > > > > >    }
> > > > > > > @@ -879,6 +883,7 @@ static int
> > > > > > > pc_set_mert_freq_cap(struct
> > > > > > > xe_guc_pc
> > > > > > > *pc)
> > > > > > >                   ret = xe_guc_pc_get_min_freq(pc, &pc-
> > > > > > > > stashed_min_freq);
> > > > > > >                   if (!ret)
> > > > > > >                           ret =
> > > > > > > xe_guc_pc_get_max_freq(pc,
> > > > > > > &pc-
> > > > > > > > stashed_max_freq);
> > > > > > > +
> 
> nit: spurious newline added in unrelated function?
> 
> I have the local changes locally and can create a new rev later.
> Stuart,
> since you reviewed this... do you agree?
> 
> Lucas De Marchi
> 
> > > > > > >                   if (ret)
> > > > > > >                           return ret;
> > > > > > >   
> > > > > > > diff --git a/drivers/gpu/drm/xe/xe_wa_oob.rules
> > > > > > > b/drivers/gpu/drm/xe/xe_wa_oob.rules
> > > > > > > index 9efc5accd43d..75fbdab68d44 100644
> > > > > > > --- a/drivers/gpu/drm/xe/xe_wa_oob.rules
> > > > > > > +++ b/drivers/gpu/drm/xe/xe_wa_oob.rules
> > > > > > > @@ -59,3 +59,4 @@ no_media_l3   MEDIA_VERSION(3000)
> > > > > > >                   MEDIA_VERSION_RANGE(1301, 3000)
> > > > > > >    16026508708    GRAPHICS_VERSION_RANGE(1200, 3001)
> > > > > > >                   MEDIA_VERSION_RANGE(1300, 3000)
> > > > > > > +14022085890    GRAPHICS_VERSION(2001)
> > 


  reply	other threads:[~2025-06-11 22:44 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-02 23:44 [PATCH v3 0/4] drm/xe/bmg: Update some WAs Vinay Belgaumkar
2025-06-02 23:44 ` [PATCH v3 1/4] drm/xe/bmg: Update Wa_14022085890 Vinay Belgaumkar
2025-06-03 17:36   ` Summers, Stuart
2025-06-03 18:41     ` Belgaumkar, Vinay
2025-06-03 19:31       ` Summers, Stuart
2025-06-03 20:31         ` Belgaumkar, Vinay
2025-06-04  0:06           ` Summers, Stuart
2025-06-07  0:09             ` Lucas De Marchi
2025-06-11 22:44               ` Summers, Stuart [this message]
2025-06-11 23:02               ` Lucas De Marchi
2025-06-11 23:31                 ` Summers, Stuart
2025-06-12  6:49                   ` Lucas De Marchi
2025-06-02 23:44 ` [PATCH v3 2/4] drm/xe/guc: Ignore GuC CT errors when wedged Vinay Belgaumkar
2025-06-03 17:34   ` Summers, Stuart
2025-06-03 18:42     ` Belgaumkar, Vinay
2025-06-04  0:09       ` Summers, Stuart
2025-06-07  0:10       ` Lucas De Marchi
2025-06-02 23:44 ` [PATCH v3 3/4] drm/xe/bmg: Update Wa_22019338487 Vinay Belgaumkar
2025-06-05  4:18   ` Nilawar, Badal
2025-06-07  0:09   ` Lucas De Marchi
2025-06-02 23:44 ` [PATCH v3 4/4] drm/xe/bmg: Update Wa_16023588340 Vinay Belgaumkar
2025-06-02 23:53 ` ✓ CI.Patch_applied: success for drm/xe/bmg: Update some WAs (rev3) Patchwork
2025-06-02 23:53 ` ✓ CI.checkpatch: " Patchwork
2025-06-02 23:54 ` ✓ CI.KUnit: " Patchwork
2025-06-03  0:05 ` ✓ CI.Build: " Patchwork
2025-06-03  0:07 ` ✓ CI.Hooks: " Patchwork
2025-06-03  0:08 ` ✓ CI.checksparse: " Patchwork
2025-06-03  0:42 ` ✓ Xe.CI.BAT: " Patchwork
2025-06-04  3:36 ` ✗ Xe.CI.Full: failure " 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=b6bf6cfe1dfdb08dc6992c6ab01f5035922d5e7e.camel@intel.com \
    --to=stuart.summers@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=vinay.belgaumkar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox