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

[Dmitry Baryshkov]

On Mon, 16 Feb 2026 at 14:24, Dikshita Agarwal
<dikshita.agarwal@xxxxxxxxxxxxxxxx> wrote:
>
>
>
> On 2/16/2026 5:33 PM, Dmitry Baryshkov wrote:
> > On Mon, Feb 16, 2026 at 01:53:28PM +0530, Dikshita Agarwal wrote:
> >>
> >>
> >> On 2/13/2026 5:34 PM, Dmitry Baryshkov wrote:
> >>> 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:
> >>>>>
> >>>>> 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
> >>
> >> This is not the correct firmware for gen2 to work with kodiak,
> >
> > Then what is that firmware file?
> >
> >     qcom: vpu: add video firmware binary for qcm6490
> >
> >     Add Host Firmware Interface (HFI) gen2 based video firmware binary for
> >     qcm6490.
> >
> > I cannot interpret it in any way other than "Kodiak firmware
> > implementing HFI Gen2". What does that commit message mean then?
>
> I agree. The intention was to target Kodiak Gen2 only; however, the
> firmware binary that was posted was incorrect and fails to load on Kodiak
> hardware. I had submitted the correct firmware [1] to resolve this issue,
> but it was not accepted.

And the discussion points out why it was not accepted. The commit
message was imprecise and misleading. You didn't provide any better
explanation.

Anyway, I've sent a removal for the broken firmware ([2]). In future,
please actually test the files before posting.

>
> [1]
> https://lore.kernel.org/linux-firmware/f5965570-9c49-860d-5de6-bc5a3056d9ad@xxxxxxxxxxx/

[2] https://lore.kernel.org/linux-firmware/20260216144056.524560-1-dmitry.baryshkov@xxxxxxxxxxxxxxxx/T/#u

>
> >
> >> the correct
> >> firmware (not posted yet) would have VIDEO.VPU.3.4.*
> >
> > I don't understand, why are you making your life harder than it is?
> > All firmware for HFI Gen2 uses different version strings (as outlined
> > below). Why all of sudden you want to change that for Kodiak?
> >
>
> Sorry, let me correct myself. The correct kodiak gen2 firmware (not yet
> posted) would have image string as video-firmware.3.4 or vfw‑3.4.

Good. Then you still have a path to implement gen1 vs gen2 checks.
Make sure that the driver first tries to load the gen2 filename, then
falls back to gen1, so that we don't have to forcefully encode
firmware-name (thus breaking venus).

>
> Thanks,
> Dikshita
> >>
> >> Thanks,
> >> Dikshita
> >>>
> >>> 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