Re: [PATCH] drm/xe/uc: Add missing HuC firmware entry for Alderlake-N

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Fri, Oct 09, 2026 at 11:26:00AM -0700, Daniele Ceraolo Spurio wrote:
> 
> 
> On 10/5/2026 1:15 AM, Kumar, Sachin wrote:
> > ALDERLAKE_N is listed in XE_GUC_FIRMWARE_DEFS but was missing from
> > XE_HUC_FIRMWARE_DEFS, so uc_fw_auto_select() never finds a HuC blob
> > for this platform. xe_huc_init() then silently treats HuC as
> > XE_UC_FIRMWARE_NOT_SUPPORTED and returns early with no log output,
> > so the gap is invisible in dmesg.
> > 
> > Media encode that depend on HuC (e.g. VP9 VDEnc BRC/header
> > probability update) assume HuC is available and still program
> > HuC-dependent HCP/VDEnc commands for the VDBOX engine. With HuC
> > firmware never loaded/authenticated, the first such command stalls
> > the only VCS engine on this single-VDBOX GT1 part, which shows up as:
> > 
> > xe 0000:00:02.0: [drm] Tile0: GT0: Engine memory CAT error: class=vcs ...
> > xe 0000:00:02.0: [drm] *ERROR* Tile0: GT0: GuC engine reset request failed
> 
> I noticed that we don't expose whether the HuC is loaded via the query ioctl
> for UMD to check like we did in i915. However, AFAIK there is also a way to
> check if the HuC is loaded or not from within the batch, so maybe that's
> missing from the UMD side? Might be worth asking.

good question...

> 
> > 
> > reproducing on every run, on the very first VP9 keyframe, at both
> > 1080p and 4K. H264 encode is unaffected since this driver's AVC VDEnc
> > path does not depend on HuC. ADL-P/ADL-S/RKL/TGL are unaffected since
> > they already have a HuC table entry.
> > 
> > Note i915 never hit this: i915 has no distinct ALDERLAKE_N platform
> > at the GT/firmware level (ADL-N is only a display subplatform of
> > ALDERLAKE_P there), so it inherits TIGERLAKE's HuC blob automatically.
> > xe gives ALDERLAKE_N its own top-level platform enum, so it needs its
> > own explicit table row.
> > 
> > Fix by adding ALDERLAKE_N to XE_HUC_FIRMWARE_DEFS, reusing the same
> > "tgl" HuC blob already used by ALDERLAKE_P/ALDERLAKE_S/ROCKETLAKE/
> > TIGERLAKE, which share the identical Gen12/TGL-LP media IP block.
> > 
> > Fixes: 500f90620cce ("drm/xe/adln: Enable ADL-N")
> 
> not sure if we want the fixes tag, as IMO turning HuC from off to on by
> default is not something that should happen in a point release. I'll leave
> it to a maintainer to ack or nack it.

because we have the doubt above and because it is a platform under the
force probe and because it is kind of a enablement, I removed it while
pushing the patch.

Thanks for the patch and review.

> 
> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> 
> Daniele
> 
> > 
> > Signed-off-by: Kumar, Sachin <sachin.kumar@intel.com>
> > ---
> >   drivers/gpu/drm/xe/xe_uc_fw.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/xe/xe_uc_fw.c b/drivers/gpu/drm/xe/xe_uc_fw.c
> > index a8e6f18cc9b4..80f657ada0ac 100644
> > --- a/drivers/gpu/drm/xe/xe_uc_fw.c
> > +++ b/drivers/gpu/drm/xe/xe_uc_fw.c
> > @@ -134,6 +134,7 @@ struct fw_blobs_by_type {
> >   	fw_def(LUNARLAKE,	GT_TYPE_ANY,	no_ver(xe,	huc,		lnl))		\
> >   	fw_def(METEORLAKE,	GT_TYPE_ANY,	no_ver(i915,	huc_gsc,	mtl))		\
> >   	fw_def(DG1,		GT_TYPE_ANY,	no_ver(i915,	huc,		dg1))		\
> > +	fw_def(ALDERLAKE_N,	GT_TYPE_ANY,	no_ver(i915,	huc,		tgl))		\
> >   	fw_def(ALDERLAKE_P,	GT_TYPE_ANY,	no_ver(i915,	huc,		tgl))		\
> >   	fw_def(ALDERLAKE_S,	GT_TYPE_ANY,	no_ver(i915,	huc,		tgl))		\
> >   	fw_def(ROCKETLAKE,	GT_TYPE_ANY,	no_ver(i915,	huc,		tgl))		\
>