Re: [PATCH 2/2] media: iris: Enable Gen2 HFI on SC7280

[Dmitry Baryshkov]

On Thu, Feb 12, 2026 at 06:35:19PM +0530, Dikshita Agarwal wrote:
> 
> 
> On 2/12/2026 5:13 PM, Konrad Dybcio wrote:
> > On 2/12/26 12:16 PM, Dikshita Agarwal wrote:
> >>
> >>
> >> On 2/9/2026 6:05 PM, Dmitry Baryshkov wrote:
> >>> On Mon, Feb 09, 2026 at 05:04:48PM +0530, Dikshita Agarwal wrote:
> >>>>
> >>>>
> >>>> On 2/9/2026 3:32 PM, Konrad Dybcio wrote:
> >>>>> On 2/9/26 10:45 AM, Dikshita Agarwal wrote:
> >>>>>> SC7280 supports both Gen1 and Gen2 HFI firmware. The driver continues to
> >>>>>> use Gen1 by default, but boards that intend to use Gen2 firmware can
> >>>>>> opt‑in by specifying a Gen2 image through the Device Tree
> >>>>>> 'firmware-name' property.
> >>>>>>
> >>>>>> Based on this property and the availability of the referenced
> >>>>>> firmware binary, the driver selects the appropriate HFI generation and
> >>>>>> updates its platform data accordingly. Boards that do not
> >>>>>> specify a Gen2 firmware, or where the firmware is not present,
> >>>>>> automatically fall back to Gen1.
> >>>>>>
> >>>>>> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@xxxxxxxxxxxxxxxx>
> >>>>>> ---
> > 
> > [...]
> > 
> >>>> To avoid accidental matches, I can switch to an exact filename match
> >>>> instead. That way, only the specific Gen2 image (for example
> >>>> "qcom/vpu/vpu20_p1_gen2.mbn") will trigger the Gen2 path, and boards that
> >>>
> >>> How do you detect that for the OEM-signed firmware, which can have
> >>> random name?
> >>>
> >>>> want to use Gen2 can opt in by naming the firmware accordingly.
> >>
> >> I Explored on suggested alternative approaches and seeing some limitation
> >> with the both of them:
> >>
> >> 1. Detecting Gen1/Gen2 by scanning the firmware blob (fw->data)
> >> It is possible to parse QC_IMAGE_VERSION_STRING from the .mbn and  extract
> >> the version string. The issues with this approach :
> >>
> >> - the version string has no explicit marker that identifies Gen1 vs Gen2.
> >>
> >> - This prefix is not a formal ABI, and it is not consistent across SoCs.
> >> Each SoC family uses different naming patterns in the version string.
> >>
> >> Example : For SC7280 Gen1 we currently see:
> >> QC_IMAGE_VERSION_STRING=video-firmware.1.0-<hash> while SM8250 has
> >> QC_IMAGE_VERSION_STRING=VIDEO.VPU.1.0-00119-<>
> >>
> >> So the driver would need SoC‑specific string‑matching rules, which is hard
> >> to maintain if we are looking for a design to address all available SOCs.
> > 
> > The only SoC with such distinction today is kodiak. So we can simply check:
> > 
> > if (kodiak && strstr(fw->data, "VIDEO.VPU.1.0.")
> > 	hfi = gen2;
> 
> Agree, this works for Kodiak. However, Dmitry was also referring to other
> SoCs that may support both Gen1 and Gen2, and at the moment there isn’t a
> generic way to handle that check.
> 
> Also, please note that the Kodiak Gen1 firmware uses the string
> video-firmware.1.0, whereas Gen2 uses VIDEO.VPU.3.4.

This is not quite true. Kodiak Gen2 uses:

$ strings /lib/firmware/qcom/vpu/vpu20_p1_gen2.mbn | grep VERSION_S
QC_IMAGE_VERSION_STRING=video-firmware.2.4.2-d7a3d5386743efb16b828e08695bea7722cafadd

A collection of versions quickly captured from what I have here (for
different chips, but for the overall picture):

HFI Gen1:

[skipping prehistorical / museum data]
VIDEO.VE.5.2-00023-PROD-2
VIDEO.VE.5.4-00059-PROD-1
VIDEO.VE.6.0-00055-PROD-1
VIDEO.IR.1.0-00005-PROD-4
VIDEO.VPU.1.0-00119-PROD-2
video-firmware.1.0-6804c210603073037fb32640a3dd6a46fe04edd6
video-firmware.1.0-7da9db401e417a006ef915d6c4323f00cdbcf40a
video-firmware.1.0-ed457c183307eff1737608763ca0f23656c95b53
video-firmware.1.1-84a8080bf84fa9ab15b353bf03bea6e548d89d2f


HFI Gen2:
vfw-0:rel0095-d1a9e7c4a274aa13e4136500d19262f87ef2c921
vfw-3.1:rel0085-070fa3311d9ef968015fee7fea07198d7eb208a1
vfw-3.1:rel0093-7925621ff52ecb7b1565341042c4e5ffd4fc76ce
vfw-3.5:rel0040-1ded01d0e6dcaef08b8155fd5a02f5b57248d5ca
vfw-4.0:rel0045-25b39e81446baf48716df98dd37099a2103d36ee
video-firmware.2.4-48ec04082362ef1922fec5e20e22f7954b11d736
video-firmware.2.4.2-d7a3d5386743efb16b828e08695bea7722cafadd
video-firmware.3.1-e5aea20c64cb6df9a1c9be99e206053b36424939
video-firmware.3.4-e299f99ffcd086b43a2ccc7c3279ce5df404d693

It seems we can assume that Gen2 is:
- vfw-0
- vfw-N.M
- video-firmware.N.M where N >= 2

All other binaries are Gen1.

Also, we don't even have to query the binary firmware blob.
After the firmware is started, you can read the version string from
smem, saving us from strstr over the firmware image.

> 
> > 
> > 
> > Can we agree that VIDEO.VPU.x firmwares are hfigen2? If so, problem also
> > solved for <=8450
> > 
> 
> Nope. that's not true for all, SM8250 uses VIDEO.VPU.1.0 which is gen1.
> 
> Thanks,
> Dikshita
> 
> > Konrad

-- 
With best wishes
Dmitry