From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Intel-GFX@lists.freedesktop.org, DRI-Devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [CI] drm/i915/mtl: Define GuC firmware version for MTL
Date: Fri, 7 Apr 2023 05:45:52 -0400 [thread overview]
Message-ID: <ZC/mUClubdajvFlf@intel.com> (raw)
In-Reply-To: <20230407003758.lbpvzisom3rw5erx@ldmartin-desk2.lan>
On Thu, Apr 06, 2023 at 05:37:58PM -0700, Lucas De Marchi wrote:
> On Fri, Mar 31, 2023 at 03:52:16PM -0700, John.C.Harrison@Intel.com wrote:
> > From: John Harrison <John.C.Harrison@Intel.com>
> >
> > First release of GuC for Meteorlake.
> >
> > NB: As this is still pre-release and likely to change, use explicit
> > versioning for now. The official, full release will use reduced
> > version naming.
> >
> > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>
> Applied to topic/core-for-CI with acks by Rodrigo and Tvrtko.
> Reference issue: https://gitlab.freedesktop.org/drm/intel/-/issues/8343
>
> Going forward we should plan to have these kind of patches in
> drm-intel-gt-next itself rather than using the CI branch. The CI branch
> is not the proper place.
>
> To be clear, since MTL is under force probe and not normally enabled,
> it's ok to bump the major version without retaining compabibility with
> the previous version, as per
> https://docs.kernel.org/driver-api/firmware/firmware-usage-guidelines.html
>
>
> I think the main blocker right now to use drm-intel-gt-next would be
> because MODULE_FIRMWARE() is unaware of force_probe. Then distros
> would start getting a warning when creating their initrd that they may
> have missed a firmware. But that firmware itself is not present in the
> upstream linux-firmware repo. We can think about a way to hide the fw
> def for *new* firmware (not the legacy ones) that are using the mmp
> version.
Maybe we should simply move to the final version path sooner than later?
Even if that means more updates in the blobs at linux-firmware.git, that
would allow the OSVs to have this final patch sooner in their trees.
>
> For now, let's keep this as is and use the CI branch to assess the
> driver health with GuC.
>
>
> thanks
> Lucas De Marchi
>
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> > index 264c952f777bb..1ac6f9f340e31 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> > @@ -79,6 +79,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
> > * security fixes, etc. to be enabled.
> > */
> > #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \
> > + fw_def(METEORLAKE, 0, guc_mmp(mtl, 70, 6, 5)) \
> > fw_def(DG2, 0, guc_maj(dg2, 70, 5)) \
> > fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5)) \
> > fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \
> > --
> > 2.39.1
> >
WARNING: multiple messages have this Message-ID (diff)
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Intel-GFX@lists.freedesktop.org,
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
DRI-Devel@lists.freedesktop.org, John.C.Harrison@intel.com
Subject: Re: [CI] drm/i915/mtl: Define GuC firmware version for MTL
Date: Fri, 7 Apr 2023 05:45:52 -0400 [thread overview]
Message-ID: <ZC/mUClubdajvFlf@intel.com> (raw)
In-Reply-To: <20230407003758.lbpvzisom3rw5erx@ldmartin-desk2.lan>
On Thu, Apr 06, 2023 at 05:37:58PM -0700, Lucas De Marchi wrote:
> On Fri, Mar 31, 2023 at 03:52:16PM -0700, John.C.Harrison@Intel.com wrote:
> > From: John Harrison <John.C.Harrison@Intel.com>
> >
> > First release of GuC for Meteorlake.
> >
> > NB: As this is still pre-release and likely to change, use explicit
> > versioning for now. The official, full release will use reduced
> > version naming.
> >
> > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>
> Applied to topic/core-for-CI with acks by Rodrigo and Tvrtko.
> Reference issue: https://gitlab.freedesktop.org/drm/intel/-/issues/8343
>
> Going forward we should plan to have these kind of patches in
> drm-intel-gt-next itself rather than using the CI branch. The CI branch
> is not the proper place.
>
> To be clear, since MTL is under force probe and not normally enabled,
> it's ok to bump the major version without retaining compabibility with
> the previous version, as per
> https://docs.kernel.org/driver-api/firmware/firmware-usage-guidelines.html
>
>
> I think the main blocker right now to use drm-intel-gt-next would be
> because MODULE_FIRMWARE() is unaware of force_probe. Then distros
> would start getting a warning when creating their initrd that they may
> have missed a firmware. But that firmware itself is not present in the
> upstream linux-firmware repo. We can think about a way to hide the fw
> def for *new* firmware (not the legacy ones) that are using the mmp
> version.
Maybe we should simply move to the final version path sooner than later?
Even if that means more updates in the blobs at linux-firmware.git, that
would allow the OSVs to have this final patch sooner in their trees.
>
> For now, let's keep this as is and use the CI branch to assess the
> driver health with GuC.
>
>
> thanks
> Lucas De Marchi
>
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> > index 264c952f777bb..1ac6f9f340e31 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> > @@ -79,6 +79,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
> > * security fixes, etc. to be enabled.
> > */
> > #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \
> > + fw_def(METEORLAKE, 0, guc_mmp(mtl, 70, 6, 5)) \
> > fw_def(DG2, 0, guc_maj(dg2, 70, 5)) \
> > fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5)) \
> > fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \
> > --
> > 2.39.1
> >
next prev parent reply other threads:[~2023-04-07 9:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-31 22:52 [Intel-gfx] [CI] drm/i915/mtl: Define GuC firmware version for MTL John.C.Harrison
2023-03-31 22:52 ` John.C.Harrison
2023-03-31 23:24 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Define GuC firmware version for MTL (rev2) Patchwork
2023-04-01 23:06 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-04-07 0:37 ` [Intel-gfx] [CI] drm/i915/mtl: Define GuC firmware version for MTL Lucas De Marchi
2023-04-07 0:37 ` Lucas De Marchi
2023-04-07 9:45 ` Rodrigo Vivi [this message]
2023-04-07 9:45 ` Rodrigo Vivi
2023-04-07 13:47 ` [Intel-gfx] " Lucas De Marchi
2023-04-07 13:47 ` Lucas De Marchi
-- strict thread matches above, loose matches on Subject: below --
2023-03-31 22:20 [Intel-gfx] " John.C.Harrison
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=ZC/mUClubdajvFlf@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=DRI-Devel@lists.freedesktop.org \
--cc=Intel-GFX@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 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.