[Intel-gfx] [PATCH v3 2/2] drm/i915/dmc: Prepare to use unversioned paths
Gustavo Sousa
gustavo.sousa at intel.com
Fri Dec 30 13:36:28 UTC 2022
On Fri, Dec 30, 2022 at 03:47:43AM -0500, Rodrigo Vivi wrote:
> On Thu, Dec 29, 2022 at 04:07:40PM -0300, Gustavo Sousa wrote:
> > New DMC releases in linux-firmware will stop using version number in
> > blob filenames. This new convention provides the following benefits:
> >
> > 1. It simplifies code maintenance, as new DMC releases for a platform
> > using the new convention will always use the same filename for the
> > blob.
> >
> > 2. It allows DMC to be loaded even if the target system does not have
> > the most recent firmware installed.
> >
> > Prepare the driver by:
> >
> > - Using the new convention for DMC_PATH() and renaming the currently
> > used one to make it clear it is for the legacy scheme.
> >
> > - Implementing a fallback mechanism for future transitions from
> > versioned to unversioned paths so that we do not cause a regression
> > for systems not having the most up-to-date linux-firmware files.
> >
> > v2:
> > - Keep using request_firmware() instead of firmware_request_nowarn().
> > (Jani)
> > v3:
> > - Keep current DMC paths instead of directly using unversioned ones,
> > so that we do not disturb initrd generation.
> > (Lucas, Rodrigo)
> >
> > References: https://lore.kernel.org/r/Y3081s7c5ksutpMW@intel.com
>
> I also don't believe this link is a good reference here...
Noted.
>
> Regarding the patch, I liked the approach in general.
>
> The patch is really neat, but I believe we will need to split it:
>
> 1. Add the new DMC_PATH and DMC_LEGACY_PATH only with the introduction
> of the mtl_dmc.bin
>
> 2. And the fallback function, add only if/when we get a real fallback.
Okay. For future reference, how should that be implemented with respect to the
organization of the patches? I see two ways of doing it and have a personal
preference for the first one:
a) The future series would have first a patch adding the necessary functionality
and a second one using it.
b) The addition of the functionality would be incorporated in the same patch
using it.
For example, for (2), (a) would be a series two patches, the first adding the
fallback mechanism and the second one changing ADLP to use unversioned paths;
and (b) would be all of that in a single patch.
I looks to me that approach (b) has a potential issue. For example, let's say we
in the future we decide to revert that specific firmware update but we already
have other platforms also using the fallback - a clean revert is not possible
there and we would need to make sure that the fallback mechanism is kept.
That's why I like (a) more and I think (b) would be more appropriate for cases
where the functionality and it's user(s) have almost like a "1:1" relationship
(not strictly speaking, read that as "having a somewhat static and restricted
set of users").
>
> Oh, and I just realized that when doing the new _dmc.bin path we also
> need to make sure that we read the fw_version from the header and
> print as a drm_info msg somewhere.
I think the version is already being read by parse_dmc_fw_css() and printed at
the end of dmc_load_work_fn() if the blob was loaded and parsed succesfully.
>
> > Signed-off-by: Gustavo Sousa <gustavo.sousa at intel.com>
> > Cc: Jani Nikula <jani.nikula at intel.com>
> > Cc: Lucas De Marchi <lucas.demarchi at intel.com>
> > Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_dmc.c | 62 ++++++++++++++++++------
> > 1 file changed, 46 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c b/drivers/gpu/drm/i915/display/intel_dmc.c
> > index 4124b3d37110..12f05b2d33a3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> > @@ -42,51 +42,59 @@
> > #define DMC_VERSION_MAJOR(version) ((version) >> 16)
> > #define DMC_VERSION_MINOR(version) ((version) & 0xffff)
> >
> > -#define DMC_PATH(platform, major, minor) \
> > - "i915/" \
> > - __stringify(platform) "_dmc_ver" \
> > - __stringify(major) "_" \
> > +#define DMC_PATH(platform) \
> > + "i915/" __stringify(platform) "_dmc.bin"
> > +
> > +/*
> > + * New DMC additions should not use this. This is used solely to remain
> > + * compatible with systems that have not yet updated DMC blobs to use
> > + * unversioned file names.
> > + */
> > +#define DMC_LEGACY_PATH(platform, major, minor) \
> > + "i915/" \
> > + __stringify(platform) "_dmc_ver" \
> > + __stringify(major) "_" \
> > __stringify(minor) ".bin"
> >
> > #define DISPLAY_VER13_DMC_MAX_FW_SIZE 0x20000
> >
> > #define DISPLAY_VER12_DMC_MAX_FW_SIZE ICL_DMC_MAX_FW_SIZE
> >
> > -#define DG2_DMC_PATH DMC_PATH(dg2, 2, 08)
> > +#define DG2_DMC_PATH DMC_LEGACY_PATH(dg2, 2, 08)
> > MODULE_FIRMWARE(DG2_DMC_PATH);
> >
> > -#define ADLP_DMC_PATH DMC_PATH(adlp, 2, 16)
> > +#define ADLP_DMC_PATH DMC_LEGACY_PATH(adlp, 2, 16)
> > MODULE_FIRMWARE(ADLP_DMC_PATH);
> >
> > -#define ADLS_DMC_PATH DMC_PATH(adls, 2, 01)
> > +#define ADLS_DMC_PATH DMC_LEGACY_PATH(adls, 2, 01)
> > MODULE_FIRMWARE(ADLS_DMC_PATH);
> >
> > -#define DG1_DMC_PATH DMC_PATH(dg1, 2, 02)
> > +#define DG1_DMC_PATH DMC_LEGACY_PATH(dg1, 2, 02)
> > MODULE_FIRMWARE(DG1_DMC_PATH);
> >
> > -#define RKL_DMC_PATH DMC_PATH(rkl, 2, 03)
> > +#define RKL_DMC_PATH DMC_LEGACY_PATH(rkl, 2, 03)
> > MODULE_FIRMWARE(RKL_DMC_PATH);
> >
> > -#define TGL_DMC_PATH DMC_PATH(tgl, 2, 12)
> > +#define TGL_DMC_PATH DMC_LEGACY_PATH(tgl, 2, 12)
> > MODULE_FIRMWARE(TGL_DMC_PATH);
> >
> > -#define ICL_DMC_PATH DMC_PATH(icl, 1, 09)
> > +#define ICL_DMC_PATH DMC_LEGACY_PATH(icl, 1, 09)
> > #define ICL_DMC_MAX_FW_SIZE 0x6000
> > MODULE_FIRMWARE(ICL_DMC_PATH);
> >
> > -#define GLK_DMC_PATH DMC_PATH(glk, 1, 04)
> > +#define GLK_DMC_PATH DMC_LEGACY_PATH(glk, 1, 04)
> > #define GLK_DMC_MAX_FW_SIZE 0x4000
> > MODULE_FIRMWARE(GLK_DMC_PATH);
> >
> > -#define KBL_DMC_PATH DMC_PATH(kbl, 1, 04)
> > +#define KBL_DMC_PATH DMC_LEGACY_PATH(kbl, 1, 04)
> > #define KBL_DMC_MAX_FW_SIZE BXT_DMC_MAX_FW_SIZE
> > MODULE_FIRMWARE(KBL_DMC_PATH);
> >
> > -#define SKL_DMC_PATH DMC_PATH(skl, 1, 27)
> > +#define SKL_DMC_PATH DMC_LEGACY_PATH(skl, 1, 27)
> > #define SKL_DMC_MAX_FW_SIZE BXT_DMC_MAX_FW_SIZE
> > MODULE_FIRMWARE(SKL_DMC_PATH);
> >
> > -#define BXT_DMC_PATH DMC_PATH(bxt, 1, 07)
> > +#define BXT_DMC_PATH DMC_LEGACY_PATH(bxt, 1, 07)
> > #define BXT_DMC_MAX_FW_SIZE 0x3000
> > MODULE_FIRMWARE(BXT_DMC_PATH);
> >
> > @@ -821,16 +829,38 @@ static void intel_dmc_runtime_pm_put(struct drm_i915_private *dev_priv)
> > intel_display_power_put(dev_priv, POWER_DOMAIN_INIT, wakeref);
> > }
> >
> > +static const char *dmc_fallback_path(struct drm_i915_private *i915)
> > +{
> > + /* No fallback paths for now. */
> > + return NULL;
> > +}
> > +
> > static void dmc_load_work_fn(struct work_struct *work)
> > {
> > struct drm_i915_private *dev_priv;
> > struct intel_dmc *dmc;
> > const struct firmware *fw = NULL;
> > + const char *fallback_path;
> > + int err;
> >
> > dev_priv = container_of(work, typeof(*dev_priv), display.dmc.work);
> > dmc = &dev_priv->display.dmc;
> >
> > - request_firmware(&fw, dev_priv->display.dmc.fw_path, dev_priv->drm.dev);
> > + err = request_firmware(&fw, dev_priv->display.dmc.fw_path, dev_priv->drm.dev);
> > +
> > + if (err == -ENOENT && !dev_priv->params.dmc_firmware_path) {
> > + fallback_path = dmc_fallback_path(dev_priv);
> > + if (fallback_path) {
> > + drm_dbg_kms(&dev_priv->drm,
> > + "%s not found, falling back to %s\n",
> > + dmc->fw_path,
> > + fallback_path);
> > + err = request_firmware(&fw, fallback_path, dev_priv->drm.dev);
> > + if (err == 0)
> > + dev_priv->display.dmc.fw_path = fallback_path;
> > + }
> > + }
> > +
> > parse_dmc_fw(dev_priv, fw);
> >
> > if (intel_dmc_has_payload(dev_priv)) {
> > --
> > 2.39.0
> >
More information about the Intel-gfx
mailing list