intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Anusha Srivatsa <anusha.srivatsa@intel.com>,
	intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	Dave Airlie <airlied@redhat.com>
Subject: Re: [Intel-xe] [PATCH 2/3] drm/xe: Fix platform order
Date: Fri, 31 Mar 2023 13:47:20 -0700	[thread overview]
Message-ID: <20230331204720.GS4085390@mdroper-desk1.amr.corp.intel.com> (raw)
In-Reply-To: <20230331131955.qunxulyrz2ruddja@ldmartin-desk2>

On Fri, Mar 31, 2023 at 07:22:06AM -0600, Lucas De Marchi wrote:
> On Mon, Mar 27, 2023 at 10:02:38AM -0700, Matt Roper wrote:
> > On Thu, Mar 23, 2023 at 10:17:53PM -0700, Lucas De Marchi wrote:
> > > Platform order is important when looping through the list of guc
> > > firmware blobs since we use it to prevent loading a blob for a newer
> > > platform onto an older one. Move PVC after ADL.
> > 
> > Shouldn't we be moving the ADL platforms (graphics versions 12.0) higher
> > than DG1 (12.10) and DG2 (12.50) too?
> 
> question then would be:  would we be ordering them by gt
> version?  Or by when they were introduced?

Since all of the platforms here have the GuC inside the
graphics IP[*], then the graphics IP version seems natural to me.

"When they were introduced" would be identical for all of these
platforms for the Xe driver (since we just dumped a big megapatch that
contained all of these platforms at once).  But if you want to match
when they were introduced *in i915* that would be reasonable too,
although the ADLs would still need to come before DG2 in that case.


Matt

[*] MTL has a GuC in both the graphics IP and the media IP.  One of our
questions early on was whether the GuC IP itself would differ between
the two GTs (requiring different firmwares for each).  The response that
came back from the hardware team was that that's technically possible
with standalone media, but at least for MTL they'd keep them identical.
So for now, just basing 100% on the graphics IP version seems fine.  In
the future we may need to stop tying GuC to platform at all and instead
match on the appropriate IP version for whichever GT we're loading on.
But that's a problem for the future...


> 
> I think it makes more sense to be by when they were introduced as a
> platform in the driver.
> 
> 	1) what about media/display?
> 	2) allow us to always be appending in the enum and elsewhere in
> 	the driver.
> 
> Lucas De Marchi
> 
> > 
> > 
> > Matt
> > 
> > > 
> > > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > > ---
> > >  drivers/gpu/drm/xe/xe_platform_types.h | 3 +--
> > >  drivers/gpu/drm/xe/xe_uc_fw.c          | 2 +-
> > >  2 files changed, 2 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/xe/xe_platform_types.h b/drivers/gpu/drm/xe/xe_platform_types.h
> > > index 72612c832e88..10367f6cc75a 100644
> > > --- a/drivers/gpu/drm/xe/xe_platform_types.h
> > > +++ b/drivers/gpu/drm/xe/xe_platform_types.h
> > > @@ -9,14 +9,13 @@
> > >  /* Keep in gen based order, and chronological order within a gen */
> > >  enum xe_platform {
> > >  	XE_PLATFORM_UNINITIALIZED = 0,
> > > -	/* gen12 */
> > >  	XE_TIGERLAKE,
> > >  	XE_ROCKETLAKE,
> > >  	XE_DG1,
> > >  	XE_DG2,
> > > -	XE_PVC,
> > >  	XE_ALDERLAKE_S,
> > >  	XE_ALDERLAKE_P,
> > > +	XE_PVC,
> > >  	XE_METEORLAKE,
> > >  };
> > > 
> > > diff --git a/drivers/gpu/drm/xe/xe_uc_fw.c b/drivers/gpu/drm/xe/xe_uc_fw.c
> > > index e2c982b37e87..174c42873ebb 100644
> > > --- a/drivers/gpu/drm/xe/xe_uc_fw.c
> > > +++ b/drivers/gpu/drm/xe/xe_uc_fw.c
> > > @@ -43,9 +43,9 @@ static struct xe_device *uc_fw_to_xe(struct xe_uc_fw *uc_fw)
> > >   */
> > >  #define XE_GUC_FIRMWARE_DEFS(fw_def, guc_def) \
> > >  	fw_def(METEORLAKE,   guc_def(mtl,  70, 5, 2)) \
> > > +	fw_def(PVC,          guc_def(pvc,  70, 5, 2)) \
> > >  	fw_def(ALDERLAKE_P,  guc_def(adlp,  70, 5, 2)) \
> > >  	fw_def(ALDERLAKE_S,  guc_def(tgl,  70, 5, 2)) \
> > > -	fw_def(PVC,          guc_def(pvc,  70, 5, 2)) \
> > >  	fw_def(DG2,          guc_def(dg2,  70, 5, 2)) \
> > >  	fw_def(DG1,          guc_def(dg1,  70, 5, 2)) \
> > >  	fw_def(TIGERLAKE,    guc_def(tgl,  70, 5, 2))
> > > --
> > > 2.39.0
> > > 
> > 
> > -- 
> > Matt Roper
> > Graphics Software Engineer
> > Linux GPU Platform Enablement
> > Intel Corporation

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation

  reply	other threads:[~2023-03-31 20:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-24  5:17 [Intel-xe] [PATCH 0/3] drm/xe: Update GuC/HuC firmware autoselection Lucas De Marchi
2023-03-24  5:17 ` [Intel-xe] [PATCH 1/3] drm/xe: Remove unused revid from firmware name Lucas De Marchi
2023-03-27 16:59   ` Matt Roper
2023-03-31 21:35     ` Lucas De Marchi
2023-03-24  5:17 ` [Intel-xe] [PATCH 2/3] drm/xe: Fix platform order Lucas De Marchi
2023-03-27 17:02   ` Matt Roper
2023-03-31 13:22     ` Lucas De Marchi
2023-03-31 20:47       ` Matt Roper [this message]
2023-03-31 21:13         ` Lucas De Marchi
2023-03-24  5:17 ` [Intel-xe] [PATCH 3/3] drm/xe: Update GuC/HuC firmware autoselect logic Lucas De Marchi
2023-03-28 23:31   ` Srivatsa, Anusha
2023-03-30  3:46     ` Lucas De Marchi
2023-04-03 18:09       ` Srivatsa, Anusha
2023-04-04 18:59         ` Lucas De Marchi
2023-03-24  5:27 ` [Intel-xe] ✓ CI.Patch_applied: success for drm/xe: Update GuC/HuC firmware autoselection Patchwork
2023-03-24  5:28 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-03-24  5:32 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-03-24  5:54 ` [Intel-xe] ○ CI.BAT: info " 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=20230331204720.GS4085390@mdroper-desk1.amr.corp.intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=airlied@redhat.com \
    --cc=anusha.srivatsa@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@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;
as well as URLs for NNTP newsgroup(s).