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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 2/17/26 8:40 AM, 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:
>>>>>>>>> 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@oss.qualcomm.com>
>>>>>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>>>> 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.
> 
> AFAIK the video/iris firmware doesn't populates its version string into
> SMEM by default.
> 
> On venus, the version string appears in SMEM only once the driver
> explicitly writes it after receiving the version info from the firmware as
> part of an HFI response.
> https://elixir.bootlin.com/linux/v6.18-rc5/source/drivers/media/platform/qcom/venus/hfi_msgs.c#L289
> 
> 
> Iris does not implement this SMEM population path today, and the firmware
> itself does not publish its version into SMEM automatically. Because of
> that, reading the version from SMEM is not currently possible for iris.
> 
> Also, relying on HFI to retrieve the version is not viable for detection
> because we cannot issue a protocol‑specific HFI command until we already
> know which HFI generation (Gen1 or Gen2) the currently loaded firmware
> supports.
> 
> Due to these constraints, I think, the only possible way is to extract the
> version from the firmware binary blob itself.

Looks like both gens use the same iris_hfi_queue_write() logic for issuing
packets and they both use the largely common iris_hfi_queue_dbg_read() logic

So, knowing that e.g. HFI_CMD_SYS_INIT (0x10001) and HFI_CMD_INIT (0x01000001)
seem not to conflict, we should be able to issue say a gen1 command and check
if we get a timeout, no?

Konrad