[PATCH 0/2] media: qcom: iris: Add Gen2 HFI support for SC7280

[PATCH 0/2] media: qcom: iris: Add Gen2 HFI support for SC7280

[Dikshita Agarwal]

This series adds support for running the Iris driver on SC7280 with Gen2 
HFI-based firmware. SC7280 can operate with either Gen1 or Gen2 HFI, but 
the driver has so far only enabled Gen1 by default.

Some platforms may choose to deploy the newer Gen2 firmware. To enable 
this, boards can now advertise a Gen2 firmware image through Device 
Tree using the 'firmware-name' property. When such a firmware is 
declared and available at runtime, the driver updates its platform 
data to use the Gen2 HFI configuration. Boards that do not specify a 
Gen2 firmware, or where the firmware is not present, will continue to 
use Gen1 with no change in behavior.

The series has been validated with both Gen1 and Gen2 firmware paths.
Gen2 firmware is yet to be posted to linux-firmware.

v4l2-compliance results on SC7280 with Gen2 firmware:

$ v4l2-compliance -d /dev/video1 -s
v4l2-compliance 1.28.1-5233, 64 bits, 64-bit time_t
v4l2-compliance SHA: fc15e229d9d3 2024-07-23 19:22:15

compliance test for iris_driver device /dev/video1:
Driver Info:
        Driver name      : iris_driver
        Card type        : Iris Encoder
        Bus info         : platform:aa00000.video-codec
        Driver version   : 6.19.0
        Capabilities     : 0x84204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps      : 0x04204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
        Detected Stateful Encoder

Required ioctls:
        test VIDIOC_QUERYCAP: OK
        test invalid ioctls: OK

Allow for multiple opens:
        test second /dev/video1 open: OK
        test VIDIOC_QUERYCAP: OK
        test VIDIOC_G/S_PRIORITY: OK
        test for unlimited opens: OK

Debug ioctls:
        test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
        test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
        test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
        test VIDIOC_ENUMAUDIO: OK (Not Supported)
        test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDIO: OK (Not Supported)
        Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
        test VIDIOC_G/S_MODULATOR: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_ENUMAUDOUT: OK (Not Supported)
        test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDOUT: OK (Not Supported)
        Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
        test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
        test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
        test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
        test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
        test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
        test VIDIOC_QUERYCTRL: OK
        test VIDIOC_G/S_CTRL: OK
        test VIDIOC_G/S/TRY_EXT_CTRLS: OK
        test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
        test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
        Standard Controls: 38 Private Controls: 0

Format ioctls:
        test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
        test VIDIOC_G/S_PARM: OK
        test VIDIOC_G_FBUF: OK (Not Supported)
        test VIDIOC_G_FMT: OK
        test VIDIOC_TRY_FMT: OK
        test VIDIOC_S_FMT: OK
        test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
        test Cropping: OK
        test Composing: OK (Not Supported)
        test Scaling: OK (Not Supported)

Codec ioctls:
        test VIDIOC_(TRY_)ENCODER_CMD: OK
        test VIDIOC_G_ENC_INDEX: OK (Not Supported)
        test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
        test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
        test CREATE_BUFS maximum buffers: OK
        test VIDIOC_REMOVE_BUFS: OK
        test VIDIOC_EXPBUF: OK
        test Requests: OK (Not Supported)

Test input 0:
Streaming ioctls:
        test read/write: OK (Not Supported)
        test blocking wait: OK
        Video Capture Multiplanar: Captured 61 buffers
        test MMAP (select): OK
        Video Capture Multiplanar: Captured 61 buffers
        test MMAP (epoll): OK
        test USERPTR (select): OK (Not Supported)
        test DMABUF: Cannot test, specify --expbuf-device

Total for iris_driver device /dev/video1: 52, Succeeded: 52, Failed: 0, Warnings: 0

$ v4l2-compliance -d /dev/video0 -s5 --stream-from=/media/FVDO_Freeway_720p.264
v4l2-compliance 1.28.1-5233, 64 bits, 64-bit time_t
v4l2-compliance SHA: fc15e229d9d3 2024-07-23 19:22:15

Compliance test for iris_driver device /dev/video0:

Driver Info:
        Driver name      : iris_driver
        Card type        : Iris Decoder
        Bus info         : platform:aa00000.video-codec
        Driver version   : 6.19.0
        Capabilities     : 0x84204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps      : 0x04204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
        Detected Stateful Decoder

Required ioctls:
        test VIDIOC_QUERYCAP: OK
        test invalid ioctls: OK

Allow for multiple opens:
        test second /dev/video0 open: OK
        test VIDIOC_QUERYCAP: OK
        test VIDIOC_G/S_PRIORITY: OK
        test for unlimited opens: OK

Debug ioctls:
        test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
        test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
        test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
        test VIDIOC_ENUMAUDIO: OK (Not Supported)
        test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDIO: OK (Not Supported)
        Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
        test VIDIOC_G/S_MODULATOR: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_ENUMAUDOUT: OK (Not Supported)
        test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDOUT: OK (Not Supported)
        Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
        test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
        test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
        test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
        test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
        test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
        test VIDIOC_QUERYCTRL: OK
        test VIDIOC_G/S_CTRL: OK
        test VIDIOC_G/S/TRY_EXT_CTRLS: OK
        test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
        test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
        Standard Controls: 12 Private Controls: 0

Format ioctls:
        test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
        test VIDIOC_G/S_PARM: OK (Not Supported)
        test VIDIOC_G_FBUF: OK (Not Supported)
        test VIDIOC_G_FMT: OK
        test VIDIOC_TRY_FMT: OK
        test VIDIOC_S_FMT: OK
        test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
        test Cropping: OK
        test Composing: OK
        test Scaling: OK (Not Supported)

Codec ioctls:
        test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
        test VIDIOC_G_ENC_INDEX: OK (Not Supported)
        test VIDIOC_(TRY_)DECODER_CMD: OK

Buffer ioctls:
        test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
        test CREATE_BUFS maximum buffers: OK
        test VIDIOC_REMOVE_BUFS: OK
        test VIDIOC_EXPBUF: OK
        test Requests: OK (Not Supported)

Test input 0:

Streaming ioctls:
        test read/write: OK (Not Supported)
        test blocking wait: OK
        Video Capture Multiplanar: Captured 65 buffers
        test MMAP (select): OK
        Video Capture Multiplanar: Captured 65 buffers
        test MMAP (epoll): OK
        test USERPTR (select): OK (Not Supported)
        test DMABUF: Cannot test, specify --expbuf-device

Total for iris_driver device /dev/video0: 52, Succeeded: 52, Failed: 0, Warnings: 0

Fluster results on SC7280 with Gen2 Firmware:

./fluster.py run -ts JVT-AVC_V1 -d GStreamer-H.264-V4L2-Gst1.0 - 77/135
The failing test case:
- Unsupported profile: H.264 Extended profile is deprecated.
	- BA3_SVA_C
- Interlaced content is not supported yet.
	- CABREF3_Sand_D
	- CAFI1_SVA_C
	- CAMA1_Sony_C
	- CAMA1_TOSHIBA_B
	- CAMA3_Sand_E
	- CAMACI3_Sony_C
	- CAMANL1_TOSHIBA_B
	- CAMANL2_TOSHIBA_B
	- CAMANL3_Sand_E
	- CAMASL3_Sony_B
	- CAMP_MOT_MBAFF_L30
	- CAMP_MOT_MBAFF_L31
	- CANLMA2_Sony_C
	- CANLMA3_Sony_C
	- CAPA1_TOSHIBA_B
	- CAPAMA3_Sand_F
	- CVCANLMA2_Sony_C
	- CVFI1_SVA_C 
	- CVFI1_Sony_D
	- CVFI2_SVA_C
	- CVFI2_Sony_H 
	- CVMA1_Sony_D
	- CVMA1_TOSHIBA_B
	- CVMANL1_TOSHIBA_B
	- CVMANL2_TOSHIBA_B
	- CVMAPAQP3_Sony_E
	- CVMAQP2_Sony_G
	- CVMAQP3_Sony_D
	- CVMP_MOT_FLD_L30_B
	- CVMP_MOT_FRM_L31
	- CVNLFI1_Sony_C
	- CVNLFI2_Sony_H
	- CVPA1_TOSHIBA_B
	- FI1_Sony_E
	- MR6_BT_B 
	- MR7_BT_B
	- MR8_BT_B 
	- MR9_BT_B
	- Sharp_MP_Field_1_B
	- Sharp_MP_Field_2_B
	- Sharp_MP_Field_3_B
	- Sharp_MP_PAFF_1r2
	- Sharp_MP_PAFF_2r
	- cabac_mot_fld0_full
	- cabac_mot_mbaff0_full
	- cabac_mot_picaff0_full
	- cama1_vtc_c
	- cama2_vtc_b
	- cama3_vtc_b
	- cavlc_mot_fld0_full_B
	- cavlc_mot_mbaff0_full_B
	- cavlc_mot_picaff0_full_B
- Unsupported bitstream: num_slice_group_minus1 > 0 (slice groups not supported by hardware).
	- FM1_BT_B
	- FM1_FT_E
	- FM2_SVA_C
- Unsupported bitstream: SP slice type is not supported by hardware.
	- SP1_BT_A
	- sp2_bt_b
	
./fluster.py run -ts JCT-VC-HEVC_V1 -d GStreamer-H.265-V4L2-Gst1.0 - 131/147
The failing test case:
- 10bit content not supported yet
	- DBLK_A_MAIN10_VIXS_4
	- INITQP_B_Main10_Sony_1
	- TSUNEQBD_A_MAIN10_Technicolor_2
	-  WPP_A_ericsson_MAIN10_2
	-  WPP_B_ericsson_MAIN10_2
	- WPP_C_ericsson_MAIN10_2
	- WPP_D_ericsson_MAIN10_2
	- WPP_E_ericsson_MAIN10_2
	- WPP_F_ericsson_MAIN10_2 
	- WP_A_MAIN10_Toshiba_3
	- WP_MAIN10_B_Toshiba_3
- Unsupported resolution
	- PICSIZE_A_Bossen_1 - resolution is higher than max supported
	- PICSIZE_B_Bossen_1 - resolution is higher than max supported
	- WPP_D_ericsson_MAIN_2 - resolution is lower than min supported
- CRC mismatch
	- RAP_A_docomo_6
- CRC mismatch - bitstream issue - fails with ffmpeg sw decoder as well
	- VPSSPSPPS_A_MainConcept_1

./fluster.py run -ts VP9-TEST-VECTORS -d GStreamer-VP9-V4L2-Gst1.0 -j1 - 235/305
The failing test case:
- Unsupported resolution
	- vp90-2-02-size-08x08.webm
	- vp90-2-02-size-08x10.webm
	- vp90-2-02-size-08x16.webm
	- vp90-2-02-size-08x18.webm
	- vp90-2-02-size-08x32.webm
	- vp90-2-02-size-08x34.webm
	- vp90-2-02-size-08x64.webm
	- vp90-2-02-size-08x66.webm
	- vp90-2-02-size-10x08.webm
	- vp90-2-02-size-10x10.webm
	- vp90-2-02-size-10x16.webm
	- vp90-2-02-size-10x18.webm
	- vp90-2-02-size-10x32.webm
	- vp90-2-02-size-10x34.webm
	- vp90-2-02-size-10x64.webm
	- vp90-2-02-size-10x66.webm
	- vp90-2-02-size-16x08.webm
	- vp90-2-02-size-16x10.webm
	- vp90-2-02-size-16x16.webm
	- vp90-2-02-size-16x18.webm
	- vp90-2-02-size-16x32.webm
	- vp90-2-02-size-16x34.webm
	- vp90-2-02-size-16x64.webm
	- vp90-2-02-size-16x66.webm
	- vp90-2-02-size-18x08.webm
	- vp90-2-02-size-18x10.webm
	- vp90-2-02-size-18x16.webm
	- vp90-2-02-size-18x18.webm
	- vp90-2-02-size-18x32.webm
	- vp90-2-02-size-18x34.webm
	- vp90-2-02-size-18x64.webm
	- vp90-2-02-size-18x66.webm
	- vp90-2-02-size-32x08.webm
	- vp90-2-02-size-32x10.webm
	- vp90-2-02-size-32x16.webm
	- vp90-2-02-size-32x18.webm
	- vp90-2-02-size-32x32.webm
	- vp90-2-02-size-32x34.webm
	- vp90-2-02-size-32x64.webm
	- vp90-2-02-size-32x66.webm
	- vp90-2-02-size-34x08.webm
	- vp90-2-02-size-34x10.webm
	- vp90-2-02-size-34x16.webm
	- vp90-2-02-size-34x18.webm
	- vp90-2-02-size-34x32.webm
	- vp90-2-02-size-34x34.webm
	- vp90-2-02-size-34x64.webm
	- vp90-2-02-size-34x66.webm
	- vp90-2-02-size-64x08.webm	
	- vp90-2-02-size-64x10.webm
	- vp90-2-02-size-64x16.webm
	- vp90-2-02-size-64x18.webm
	- vp90-2-02-size-64x32.webm
	- vp90-2-02-size-64x34.webm	
	- vp90-2-02-size-64x64.webm
	- vp90-2-02-size-64x66.webm
	- vp90-2-02-size-66x08.webm
	- vp90-2-02-size-66x10.webm
	- vp90-2-02-size-66x16.webm
	- vp90-2-02-size-66x18.webm
	- vp90-2-02-size-66x32.webm
	- vp90-2-02-size-66x34.webm
	- vp90-2-02-size-66x64.webm
	- vp90-2-02-size-66x66.webm
- Unsupported format
	- vp91-2-04-yuv422.webm
	- vp91-2-04-yuv444.webm
- CRC mismatch
	- vp90-2-22-svc_1280x720_3.ivf
- Unsupported resolution after sequence change
	- vp90-2-21-resize_inter_320x180_5_1-2.webm
	- vp90-2-21-resize_inter_320x180_7_1-2.webm
- Unsupported stream
	- vp90-2-16-intra-only.webm

Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
---
Dikshita Agarwal (2):
      media: iris: Initialize HFI ops after firmware load in core init
      media: iris: Enable Gen2 HFI on SC7280

 drivers/media/platform/qcom/iris/iris_core.c       | 32 +++++++++
 drivers/media/platform/qcom/iris/iris_core.h       |  1 +
 drivers/media/platform/qcom/iris/iris_hfi_common.c |  6 ++
 drivers/media/platform/qcom/iris/iris_hfi_common.h |  1 +
 .../platform/qcom/iris/iris_platform_common.h      |  1 +
 .../media/platform/qcom/iris/iris_platform_gen1.c  |  4 +-
 .../media/platform/qcom/iris/iris_platform_gen2.c  | 83 ++++++++++++++++++++++
 .../platform/qcom/iris/iris_platform_sc7280.h      | 15 ++++
 drivers/media/platform/qcom/iris/iris_probe.c      |  5 --
 drivers/media/platform/qcom/iris/iris_vidc.c       |  3 +
 10 files changed, 144 insertions(+), 7 deletions(-)
---
base-commit: c824345288d11e269ce41b36c105715bc2286050
change-id: 20260209-iris_sc7280_gen2_support-cb34465ed4e7

Best regards,
-- 
Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>

[PATCH 1/2] media: iris: Initialize HFI ops after firmware load in core init

[Dikshita Agarwal]

The HFI command/response ops were previously initialized in probe(), but
we don't have firmware loaded at probe time. Since HFI is tightly
coupled to firmware, initialize the HFI ops after firmware has been
successfully loaded and booted.

Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
---
 drivers/media/platform/qcom/iris/iris_core.c       | 2 ++
 drivers/media/platform/qcom/iris/iris_hfi_common.c | 6 ++++++
 drivers/media/platform/qcom/iris/iris_hfi_common.h | 1 +
 drivers/media/platform/qcom/iris/iris_probe.c      | 2 --
 4 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/qcom/iris/iris_core.c b/drivers/media/platform/qcom/iris/iris_core.c
index 8406c48d635b6eba0879396ce9f9ae2292743f09..8e4cc6d6123069dea860062f0172f1e4b90cfc13 100644
--- a/drivers/media/platform/qcom/iris/iris_core.c
+++ b/drivers/media/platform/qcom/iris/iris_core.c
@@ -75,6 +75,8 @@ int iris_core_init(struct iris_core *core)
 	if (ret)
 		goto error_unload_fw;
 
+	iris_init_hfi_ops(core);
+
 	ret = iris_hfi_core_init(core);
 	if (ret)
 		goto error_unload_fw;
diff --git a/drivers/media/platform/qcom/iris/iris_hfi_common.c b/drivers/media/platform/qcom/iris/iris_hfi_common.c
index 92112eb16c11048e28230a2926dfb46e3163aada..bbca17edf281a11142d7582178cd7562be053b45 100644
--- a/drivers/media/platform/qcom/iris/iris_hfi_common.c
+++ b/drivers/media/platform/qcom/iris/iris_hfi_common.c
@@ -74,6 +74,12 @@ u32 iris_hfi_get_v4l2_matrix_coefficients(u32 hfi_coefficients)
 	}
 }
 
+void iris_init_hfi_ops(struct iris_core *core)
+{
+	core->iris_platform_data->init_hfi_command_ops(core);
+	core->iris_platform_data->init_hfi_response_ops(core);
+}
+
 int iris_hfi_core_init(struct iris_core *core)
 {
 	const struct iris_hfi_command_ops *hfi_ops = core->hfi_ops;
diff --git a/drivers/media/platform/qcom/iris/iris_hfi_common.h b/drivers/media/platform/qcom/iris/iris_hfi_common.h
index 3edb5ae582b49bea2e2408c4a5cfc0a742adc05f..498a08314cdeb65b4b621e2200aae8685f4a025b 100644
--- a/drivers/media/platform/qcom/iris/iris_hfi_common.h
+++ b/drivers/media/platform/qcom/iris/iris_hfi_common.h
@@ -149,6 +149,7 @@ struct hfi_subscription_params {
 u32 iris_hfi_get_v4l2_color_primaries(u32 hfi_primaries);
 u32 iris_hfi_get_v4l2_transfer_char(u32 hfi_characterstics);
 u32 iris_hfi_get_v4l2_matrix_coefficients(u32 hfi_coefficients);
+void iris_init_hfi_ops(struct iris_core *core);
 int iris_hfi_core_init(struct iris_core *core);
 int iris_hfi_pm_suspend(struct iris_core *core);
 int iris_hfi_pm_resume(struct iris_core *core);
diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
index ddaacda523ecb9990af0dd0640196223fbcc2cab..22c7b3410710328b900fc49459cd399aa0e89b02 100644
--- a/drivers/media/platform/qcom/iris/iris_probe.c
+++ b/drivers/media/platform/qcom/iris/iris_probe.c
@@ -252,8 +252,6 @@ static int iris_probe(struct platform_device *pdev)
 	disable_irq_nosync(core->irq);
 
 	iris_init_ops(core);
-	core->iris_platform_data->init_hfi_command_ops(core);
-	core->iris_platform_data->init_hfi_response_ops(core);
 
 	ret = iris_init_resources(core);
 	if (ret)

-- 
2.34.1

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

[Dikshita Agarwal]

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>
---
 drivers/media/platform/qcom/iris/iris_core.c       | 30 ++++++++
 drivers/media/platform/qcom/iris/iris_core.h       |  1 +
 .../platform/qcom/iris/iris_platform_common.h      |  1 +
 .../media/platform/qcom/iris/iris_platform_gen1.c  |  4 +-
 .../media/platform/qcom/iris/iris_platform_gen2.c  | 83 ++++++++++++++++++++++
 .../platform/qcom/iris/iris_platform_sc7280.h      | 15 ++++
 drivers/media/platform/qcom/iris/iris_probe.c      |  3 -
 drivers/media/platform/qcom/iris/iris_vidc.c       |  3 +
 8 files changed, 135 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/qcom/iris/iris_core.c b/drivers/media/platform/qcom/iris/iris_core.c
index 8e4cc6d6123069dea860062f0172f1e4b90cfc13..b14b04b32b62e324a70a558063dc673f7b9c2981 100644
--- a/drivers/media/platform/qcom/iris/iris_core.c
+++ b/drivers/media/platform/qcom/iris/iris_core.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2022-2024 Qualcomm Innovation Center, Inc. All rights reserved.
  */
 
+#include <linux/firmware.h>
 #include <linux/pm_runtime.h>
 
 #include "iris_core.h"
@@ -10,6 +11,31 @@
 #include "iris_state.h"
 #include "iris_vpu_common.h"
 
+int iris_update_platform_data(struct iris_core *core)
+{
+	const char *fwname = NULL;
+	const struct firmware *fw;
+	int ret;
+
+	if (of_device_is_compatible(core->dev->of_node, "qcom,sc7280-venus")) {
+		ret = of_property_read_string_index(core->dev->of_node, "firmware-name", 0,
+					    &fwname);
+		if (ret)
+			return 0;
+
+		if (strstr(fwname, "gen2")) {
+			ret = request_firmware(&fw, fwname, core->dev);
+			if (ret) {
+				dev_err(core->dev, "Specified firmware is not present\n");
+				return ret;
+			}
+			release_firmware(fw);
+			core->iris_platform_data = &sc7280_gen2_data;
+		}
+	}
+	return 0;
+}
+
 void iris_core_deinit(struct iris_core *core)
 {
 	pm_runtime_resume_and_get(core->dev);
@@ -67,6 +93,10 @@ int iris_core_init(struct iris_core *core)
 	if (ret)
 		goto error_queue_deinit;
 
+	ret = iris_update_platform_data(core);
+	if (ret)
+		goto error_queue_deinit;
+
 	ret = iris_fw_load(core);
 	if (ret)
 		goto error_power_off;
diff --git a/drivers/media/platform/qcom/iris/iris_core.h b/drivers/media/platform/qcom/iris/iris_core.h
index fb194c967ad4f9b5e00cd74f0d41e0b827ef14db..3b6ff3405f504359a094ad65d5a3252f20adba4b 100644
--- a/drivers/media/platform/qcom/iris/iris_core.h
+++ b/drivers/media/platform/qcom/iris/iris_core.h
@@ -121,5 +121,6 @@ struct iris_core {
 
 int iris_core_init(struct iris_core *core);
 void iris_core_deinit(struct iris_core *core);
+int iris_update_platform_data(struct iris_core *core);
 
 #endif
diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
index 5a489917580eb10022fdcb52f7321a915e8b239d..f1bbbe043e3a3ccc5eebf67091162678eb83bf45 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_common.h
+++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
@@ -43,6 +43,7 @@ enum pipe_type {
 
 extern const struct iris_platform_data qcs8300_data;
 extern const struct iris_platform_data sc7280_data;
+extern const struct iris_platform_data sc7280_gen2_data;
 extern const struct iris_platform_data sm8250_data;
 extern const struct iris_platform_data sm8550_data;
 extern const struct iris_platform_data sm8650_data;
diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen1.c b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
index df8e6bf9430ed2a070e092edae9ef998d092cb5e..6dbdd0833dcdc7dfac6d7b35f99837c883e188e7 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_gen1.c
+++ b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
@@ -414,8 +414,8 @@ const struct iris_platform_data sc7280_data = {
 	.dma_mask = 0xe0000000 - 1,
 	.fwname = "qcom/vpu/vpu20_p1.mbn",
 	.pas_id = IRIS_PAS_ID,
-	.inst_iris_fmts = platform_fmts_sm8250_dec,
-	.inst_iris_fmts_size = ARRAY_SIZE(platform_fmts_sm8250_dec),
+	.inst_iris_fmts = platform_fmts_sc7280_dec,
+	.inst_iris_fmts_size = ARRAY_SIZE(platform_fmts_sc7280_dec),
 	.inst_caps = &platform_inst_cap_sm8250,
 	.inst_fw_caps_dec = inst_fw_cap_sm8250_dec,
 	.inst_fw_caps_dec_size = ARRAY_SIZE(inst_fw_cap_sm8250_dec),
diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen2.c b/drivers/media/platform/qcom/iris/iris_platform_gen2.c
index 5da90d47f9c6eab4a7e6b17841fdc0e599397bf7..8987fcc0cceb8632424e1d686ad04ca310d180bb 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_gen2.c
+++ b/drivers/media/platform/qcom/iris/iris_platform_gen2.c
@@ -15,6 +15,7 @@
 #include "iris_platform_qcs8300.h"
 #include "iris_platform_sm8650.h"
 #include "iris_platform_sm8750.h"
+#include "iris_platform_sc7280.h"
 
 #define VIDEO_ARCH_LX 1
 #define BITRATE_MAX				245000000
@@ -1317,3 +1318,85 @@ const struct iris_platform_data qcs8300_data = {
 	.enc_op_int_buf_tbl = sm8550_enc_op_int_buf_tbl,
 	.enc_op_int_buf_tbl_size = ARRAY_SIZE(sm8550_enc_op_int_buf_tbl),
 };
+
+const struct iris_platform_data sc7280_gen2_data = {
+	.get_instance = iris_hfi_gen2_get_instance,
+	.init_hfi_command_ops = iris_hfi_gen2_command_ops_init,
+	.init_hfi_response_ops = iris_hfi_gen2_response_ops_init,
+	/* Gen2 FW for SC7280 requires bigger size for line buffer for encoder */
+	.get_vpu_buffer_size = iris_vpu33_buf_size,
+	.vpu_ops = &iris_vpu2_ops,
+	.set_preset_registers = iris_set_sm8550_preset_registers,
+	.icc_tbl = sm8550_icc_table,
+	.icc_tbl_size = ARRAY_SIZE(sm8550_icc_table),
+	.bw_tbl_dec = sc7280_bw_table_dec,
+	.bw_tbl_dec_size = ARRAY_SIZE(sc7280_bw_table_dec),
+	.pmdomain_tbl = sm8550_pmdomain_table,
+	.pmdomain_tbl_size = ARRAY_SIZE(sm8550_pmdomain_table),
+	.opp_pd_tbl = sc7280_opp_pd_table,
+	.opp_pd_tbl_size = ARRAY_SIZE(sc7280_opp_pd_table),
+	.clk_tbl = sc7280_clk_table,
+	.clk_tbl_size = ARRAY_SIZE(sc7280_clk_table),
+	.opp_clk_tbl = sc7280_opp_clk_table,
+	/* Upper bound of DMA address range */
+	.dma_mask = 0xe0000000 - 1,
+	.fwname = "qcom/vpu/vpu20_p1_gen2.mbn",
+	.pas_id = IRIS_PAS_ID,
+	.inst_iris_fmts = platform_fmts_sc7280_dec,
+	.inst_iris_fmts_size = ARRAY_SIZE(platform_fmts_sc7280_dec),
+	.inst_caps = &platform_inst_cap_sm8550,
+	.inst_fw_caps_dec = inst_fw_cap_sm8550_dec,
+	.inst_fw_caps_dec_size = ARRAY_SIZE(inst_fw_cap_sm8550_dec),
+	.inst_fw_caps_enc = inst_fw_cap_sm8550_enc,
+	.inst_fw_caps_enc_size = ARRAY_SIZE(inst_fw_cap_sm8550_enc),
+	.tz_cp_config_data = tz_cp_config_sm8550,
+	.tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_sm8550),
+	.hw_response_timeout = HW_RESPONSE_TIMEOUT_VALUE,
+	.ubwc_config = &ubwc_config_sm8550,
+	.core_arch = VIDEO_ARCH_LX,
+	.num_vpp_pipe = 1,
+	.no_aon = true,
+	.max_session_count = 16,
+	.max_core_mbpf = 4096 * 2176 / 256 * 2 + 1920 * 1088 / 256,
+	/* max spec for SC7280 is 4096x2176@60fps */
+	.max_core_mbps = 4096 * 2176 / 256 * 60,
+	.dec_input_config_params_default =
+		sm8550_vdec_input_config_params_default,
+	.dec_input_config_params_default_size =
+		ARRAY_SIZE(sm8550_vdec_input_config_params_default),
+	.dec_input_config_params_hevc =
+		sm8550_vdec_input_config_param_hevc,
+	.dec_input_config_params_hevc_size =
+		ARRAY_SIZE(sm8550_vdec_input_config_param_hevc),
+	.dec_input_config_params_vp9 =
+		sm8550_vdec_input_config_param_vp9,
+	.dec_input_config_params_vp9_size =
+		ARRAY_SIZE(sm8550_vdec_input_config_param_vp9),
+	.enc_input_config_params = sm8550_venc_input_config_params,
+	.enc_input_config_params_size =
+		ARRAY_SIZE(sm8550_venc_input_config_params),
+	.dec_output_config_params = sm8550_vdec_output_config_params,
+	.dec_output_config_params_size = ARRAY_SIZE(sm8550_vdec_output_config_params),
+	.enc_output_config_params = sm8550_venc_output_config_params,
+	.enc_output_config_params_size = ARRAY_SIZE(sm8550_venc_output_config_params),
+
+	.dec_ip_int_buf_tbl = sm8550_dec_ip_int_buf_tbl,
+	.dec_ip_int_buf_tbl_size = ARRAY_SIZE(sm8550_dec_ip_int_buf_tbl),
+	.dec_op_int_buf_tbl = sm8550_dec_op_int_buf_tbl,
+	.dec_op_int_buf_tbl_size = ARRAY_SIZE(sm8550_dec_op_int_buf_tbl),
+
+	.enc_op_int_buf_tbl = sm8550_enc_op_int_buf_tbl,
+	.enc_op_int_buf_tbl_size = ARRAY_SIZE(sm8550_enc_op_int_buf_tbl),
+
+	.dec_input_prop = sm8550_vdec_subscribe_input_properties,
+	.dec_input_prop_size = ARRAY_SIZE(sm8550_vdec_subscribe_input_properties),
+	.dec_output_prop_avc = sm8550_vdec_subscribe_output_properties_avc,
+	.dec_output_prop_avc_size =
+		ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_avc),
+	.dec_output_prop_hevc = sm8550_vdec_subscribe_output_properties_hevc,
+	.dec_output_prop_hevc_size =
+		ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_hevc),
+	.dec_output_prop_vp9 = sm8550_vdec_subscribe_output_properties_vp9,
+	.dec_output_prop_vp9_size =
+		ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_vp9),
+};
diff --git a/drivers/media/platform/qcom/iris/iris_platform_sc7280.h b/drivers/media/platform/qcom/iris/iris_platform_sc7280.h
index 0ec8f334df670c3c1548a5ee3b8907b333e34db3..6e05f2542a5457bd0b3b6acced3bd54d166b2023 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_sc7280.h
+++ b/drivers/media/platform/qcom/iris/iris_platform_sc7280.h
@@ -6,6 +6,21 @@
 #ifndef __IRIS_PLATFORM_SC7280_H__
 #define __IRIS_PLATFORM_SC7280_H__
 
+static struct iris_fmt platform_fmts_sc7280_dec[] = {
+	[IRIS_FMT_H264] = {
+		.pixfmt = V4L2_PIX_FMT_H264,
+		.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+	},
+	[IRIS_FMT_HEVC] = {
+		.pixfmt = V4L2_PIX_FMT_HEVC,
+		.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+	},
+	[IRIS_FMT_VP9] = {
+		.pixfmt = V4L2_PIX_FMT_VP9,
+		.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+	},
+};
+
 static const struct bw_info sc7280_bw_table_dec[] = {
 	{ ((3840 * 2160) / 256) * 60, 1896000, },
 	{ ((3840 * 2160) / 256) * 30,  968000, },
diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
index 22c7b3410710328b900fc49459cd399aa0e89b02..1f44d3ea337df63fbf5317b9b99139a0867267c3 100644
--- a/drivers/media/platform/qcom/iris/iris_probe.c
+++ b/drivers/media/platform/qcom/iris/iris_probe.c
@@ -12,7 +12,6 @@
 #include <linux/reset.h>
 
 #include "iris_core.h"
-#include "iris_ctrls.h"
 #include "iris_vidc.h"
 
 static int iris_init_icc(struct iris_core *core)
@@ -257,8 +256,6 @@ static int iris_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	iris_session_init_caps(core);
-
 	ret = v4l2_device_register(dev, &core->v4l2_dev);
 	if (ret)
 		return ret;
diff --git a/drivers/media/platform/qcom/iris/iris_vidc.c b/drivers/media/platform/qcom/iris/iris_vidc.c
index bd38d84c9cc79d15585ed5dd5f905a37521cb6dc..0727d5d19cb9b7ed1f72ab840ae5dfda0162e23d 100644
--- a/drivers/media/platform/qcom/iris/iris_vidc.c
+++ b/drivers/media/platform/qcom/iris/iris_vidc.c
@@ -9,6 +9,7 @@
 #include <media/v4l2-mem2mem.h>
 #include <media/videobuf2-dma-contig.h>
 
+#include "iris_ctrls.h"
 #include "iris_vidc.h"
 #include "iris_instance.h"
 #include "iris_vdec.h"
@@ -196,6 +197,8 @@ int iris_open(struct file *filp)
 		goto fail_m2m_release;
 	}
 
+	iris_session_init_caps(core);
+
 	if (inst->domain == DECODER)
 		ret = iris_vdec_inst_init(inst);
 	else if (inst->domain == ENCODER)

-- 
2.34.1

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

[Konrad Dybcio]

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>
> ---

[...]

> +int iris_update_platform_data(struct iris_core *core)
> +{
> +	const char *fwname = NULL;
> +	const struct firmware *fw;
> +	int ret;
> +
> +	if (of_device_is_compatible(core->dev->of_node, "qcom,sc7280-venus")) {
> +		ret = of_property_read_string_index(core->dev->of_node, "firmware-name", 0,
> +					    &fwname);
> +		if (ret)
> +			return 0;
> +
> +		if (strstr(fwname, "gen2")) {
> +			ret = request_firmware(&fw, fwname, core->dev);
> +			if (ret) {
> +				dev_err(core->dev, "Specified firmware is not present\n");
> +				return ret;

This is fragile - if someone names names their gen1 firmware something like
"myproduct_gen2_vidfw.mbn", it's going to match..

Could we instead do something like the explicit format checks in
venus/hfi_msgs.c : sys_get_prop_image_version(), based on the **contents**
of the binary?

Konrad

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

[Dikshita Agarwal]

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>
>> ---
> 
> [...]
> 
>> +int iris_update_platform_data(struct iris_core *core)
>> +{
>> +	const char *fwname = NULL;
>> +	const struct firmware *fw;
>> +	int ret;
>> +
>> +	if (of_device_is_compatible(core->dev->of_node, "qcom,sc7280-venus")) {
>> +		ret = of_property_read_string_index(core->dev->of_node, "firmware-name", 0,
>> +					    &fwname);
>> +		if (ret)
>> +			return 0;
>> +
>> +		if (strstr(fwname, "gen2")) {
>> +			ret = request_firmware(&fw, fwname, core->dev);
>> +			if (ret) {
>> +				dev_err(core->dev, "Specified firmware is not present\n");
>> +				return ret;
> 
> This is fragile - if someone names names their gen1 firmware something like
> "myproduct_gen2_vidfw.mbn", it's going to match..
> 
> Could we instead do something like the explicit format checks in
> venus/hfi_msgs.c : sys_get_prop_image_version(), based on the **contents**
> of the binary?
> 

I agree that checking for "gen2" as a substring in the firmware name is not
reliable. Unfortunately, we cannot
usevenus/hfi_msgs.c:sys_get_prop_image_version() (or any Gen1 HFI query) to
probe the contents of the binary here, because Gen1 vs Gen2 have
incompatible HFI protocols—probing a Gen2 image with Gen1 HFI (or
vice‑versa) isn’t viable in this path.

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
want to use Gen2 can opt in by naming the firmware accordingly.

Thanks,
Dikshita

> Konrad

Re: [PATCH 1/2] media: iris: Initialize HFI ops after firmware load in core init

[Bryan O'Donoghue]

On 09/02/2026 09:45, Dikshita Agarwal wrote:
> The HFI command/response ops were previously initialized in probe(), but
> we don't have firmware loaded at probe time. Since HFI is tightly
> coupled to firmware, initialize the HFI ops after firmware has been
> successfully loaded and booted.

"but," not ", but"

I'll fix that for you on application.

> 
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> ---
>   drivers/media/platform/qcom/iris/iris_core.c       | 2 ++
>   drivers/media/platform/qcom/iris/iris_hfi_common.c | 6 ++++++
>   drivers/media/platform/qcom/iris/iris_hfi_common.h | 1 +
>   drivers/media/platform/qcom/iris/iris_probe.c      | 2 --
>   4 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/iris/iris_core.c b/drivers/media/platform/qcom/iris/iris_core.c
> index 8406c48d635b6eba0879396ce9f9ae2292743f09..8e4cc6d6123069dea860062f0172f1e4b90cfc13 100644
> --- a/drivers/media/platform/qcom/iris/iris_core.c
> +++ b/drivers/media/platform/qcom/iris/iris_core.c
> @@ -75,6 +75,8 @@ int iris_core_init(struct iris_core *core)
>   	if (ret)
>   		goto error_unload_fw;
> 
> +	iris_init_hfi_ops(core);
> +
>   	ret = iris_hfi_core_init(core);
>   	if (ret)
>   		goto error_unload_fw;
> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_common.c b/drivers/media/platform/qcom/iris/iris_hfi_common.c
> index 92112eb16c11048e28230a2926dfb46e3163aada..bbca17edf281a11142d7582178cd7562be053b45 100644
> --- a/drivers/media/platform/qcom/iris/iris_hfi_common.c
> +++ b/drivers/media/platform/qcom/iris/iris_hfi_common.c
> @@ -74,6 +74,12 @@ u32 iris_hfi_get_v4l2_matrix_coefficients(u32 hfi_coefficients)
>   	}
>   }
> 
> +void iris_init_hfi_ops(struct iris_core *core)
> +{
> +	core->iris_platform_data->init_hfi_command_ops(core);
> +	core->iris_platform_data->init_hfi_response_ops(core);
> +}
> +
>   int iris_hfi_core_init(struct iris_core *core)
>   {
>   	const struct iris_hfi_command_ops *hfi_ops = core->hfi_ops;
> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_common.h b/drivers/media/platform/qcom/iris/iris_hfi_common.h
> index 3edb5ae582b49bea2e2408c4a5cfc0a742adc05f..498a08314cdeb65b4b621e2200aae8685f4a025b 100644
> --- a/drivers/media/platform/qcom/iris/iris_hfi_common.h
> +++ b/drivers/media/platform/qcom/iris/iris_hfi_common.h
> @@ -149,6 +149,7 @@ struct hfi_subscription_params {
>   u32 iris_hfi_get_v4l2_color_primaries(u32 hfi_primaries);
>   u32 iris_hfi_get_v4l2_transfer_char(u32 hfi_characterstics);
>   u32 iris_hfi_get_v4l2_matrix_coefficients(u32 hfi_coefficients);
> +void iris_init_hfi_ops(struct iris_core *core);
>   int iris_hfi_core_init(struct iris_core *core);
>   int iris_hfi_pm_suspend(struct iris_core *core);
>   int iris_hfi_pm_resume(struct iris_core *core);
> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
> index ddaacda523ecb9990af0dd0640196223fbcc2cab..22c7b3410710328b900fc49459cd399aa0e89b02 100644
> --- a/drivers/media/platform/qcom/iris/iris_probe.c
> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
> @@ -252,8 +252,6 @@ static int iris_probe(struct platform_device *pdev)
>   	disable_irq_nosync(core->irq);
> 
>   	iris_init_ops(core);
> -	core->iris_platform_data->init_hfi_command_ops(core);
> -	core->iris_platform_data->init_hfi_response_ops(core);
> 
>   	ret = iris_init_resources(core);
>   	if (ret)
> 
> --
> 2.34.1
> 
> 
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>

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

[Bryan O'Donoghue]

On 09/02/2026 11:34, 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>
>>> ---
>>
>> [...]
>>
>>> +int iris_update_platform_data(struct iris_core *core)
>>> +{
>>> +	const char *fwname = NULL;
>>> +	const struct firmware *fw;
>>> +	int ret;
>>> +
>>> +	if (of_device_is_compatible(core->dev->of_node, "qcom,sc7280-venus")) {
>>> +		ret = of_property_read_string_index(core->dev->of_node, "firmware-name", 0,
>>> +					    &fwname);
>>> +		if (ret)
>>> +			return 0;
>>> +
>>> +		if (strstr(fwname, "gen2")) {
>>> +			ret = request_firmware(&fw, fwname, core->dev);
>>> +			if (ret) {
>>> +				dev_err(core->dev, "Specified firmware is not present\n");
>>> +				return ret;
>>
>> This is fragile - if someone names names their gen1 firmware something like
>> "myproduct_gen2_vidfw.mbn", it's going to match..
>>
>> Could we instead do something like the explicit format checks in
>> venus/hfi_msgs.c : sys_get_prop_image_version(), based on the **contents**
>> of the binary?
>>
> 
> I agree that checking for "gen2" as a substring in the firmware name is not
> reliable. Unfortunately, we cannot
> usevenus/hfi_msgs.c:sys_get_prop_image_version() (or any Gen1 HFI query) to
> probe the contents of the binary here, because Gen1 vs Gen2 have
> incompatible HFI protocols—probing a Gen2 image with Gen1 HFI (or
> vice‑versa) isn’t viable in this path.
> 
> 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
> want to use Gen2 can opt in by naming the firmware accordingly.

Exact match would be reasonable, IMO.

---
bod

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

[Konrad Dybcio]

On 2/9/26 12:34 PM, 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>
>>> ---
>>
>> [...]
>>
>>> +int iris_update_platform_data(struct iris_core *core)
>>> +{
>>> +	const char *fwname = NULL;
>>> +	const struct firmware *fw;
>>> +	int ret;
>>> +
>>> +	if (of_device_is_compatible(core->dev->of_node, "qcom,sc7280-venus")) {
>>> +		ret = of_property_read_string_index(core->dev->of_node, "firmware-name", 0,
>>> +					    &fwname);
>>> +		if (ret)
>>> +			return 0;
>>> +
>>> +		if (strstr(fwname, "gen2")) {
>>> +			ret = request_firmware(&fw, fwname, core->dev);
>>> +			if (ret) {
>>> +				dev_err(core->dev, "Specified firmware is not present\n");
>>> +				return ret;
>>
>> This is fragile - if someone names names their gen1 firmware something like
>> "myproduct_gen2_vidfw.mbn", it's going to match..
>>
>> Could we instead do something like the explicit format checks in
>> venus/hfi_msgs.c : sys_get_prop_image_version(), based on the **contents**
>> of the binary?
>>
> 
> I agree that checking for "gen2" as a substring in the firmware name is not
> reliable. Unfortunately, we cannot
> usevenus/hfi_msgs.c:sys_get_prop_image_version() (or any Gen1 HFI query) to
> probe the contents of the binary here, because Gen1 vs Gen2 have
> incompatible HFI protocols—probing a Gen2 image with Gen1 HFI (or
> vice‑versa) isn’t viable in this path.
> 
> 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
> want to use Gen2 can opt in by naming the firmware accordingly.

Can we do strstr for QC_IMAGE_VERSION_STRING on fw->data and rely on that?

Konrad

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

[Dmitry Baryshkov]

On Mon, Feb 09, 2026 at 03:15:26PM +0530, 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.

What are the benefits of using Gen2 firmware? Why is it left as a
board-level selection? E.g. for the non-fused boards, would it be
benefitable to switch to Gen2 or not?

> 
> 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>
> ---
>  drivers/media/platform/qcom/iris/iris_core.c       | 30 ++++++++
>  drivers/media/platform/qcom/iris/iris_core.h       |  1 +
>  .../platform/qcom/iris/iris_platform_common.h      |  1 +
>  .../media/platform/qcom/iris/iris_platform_gen1.c  |  4 +-
>  .../media/platform/qcom/iris/iris_platform_gen2.c  | 83 ++++++++++++++++++++++
>  .../platform/qcom/iris/iris_platform_sc7280.h      | 15 ++++
>  drivers/media/platform/qcom/iris/iris_probe.c      |  3 -
>  drivers/media/platform/qcom/iris/iris_vidc.c       |  3 +
>  8 files changed, 135 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/iris/iris_core.c b/drivers/media/platform/qcom/iris/iris_core.c
> index 8e4cc6d6123069dea860062f0172f1e4b90cfc13..b14b04b32b62e324a70a558063dc673f7b9c2981 100644
> --- a/drivers/media/platform/qcom/iris/iris_core.c
> +++ b/drivers/media/platform/qcom/iris/iris_core.c
> @@ -3,6 +3,7 @@
>   * Copyright (c) 2022-2024 Qualcomm Innovation Center, Inc. All rights reserved.
>   */
>  
> +#include <linux/firmware.h>
>  #include <linux/pm_runtime.h>
>  
>  #include "iris_core.h"
> @@ -10,6 +11,31 @@
>  #include "iris_state.h"
>  #include "iris_vpu_common.h"
>  
> +int iris_update_platform_data(struct iris_core *core)
> +{
> +	const char *fwname = NULL;
> +	const struct firmware *fw;
> +	int ret;
> +
> +	if (of_device_is_compatible(core->dev->of_node, "qcom,sc7280-venus")) {
> +		ret = of_property_read_string_index(core->dev->of_node, "firmware-name", 0,
> +					    &fwname);
> +		if (ret)
> +			return 0;
> +
> +		if (strstr(fwname, "gen2")) {

How is going to be applicable for the possibly vendor-signed firmware?
Or for the firmware which uses a different name?  E.g.
qcom/qcm6490/fairphone5/venus.mbn - is it gen1 or gen2?

We need to query the firmware and detect the interface based on the
query results. Either check the file itself, or start the firmware and
query the running system.

Moreover, I guess, this is not limited to SC7280 only. My guess would be
that any platform can be either gen1 or gen2 (not implying that both
firmware versions actually exists for all the platforms).

> +			ret = request_firmware(&fw, fwname, core->dev);
> +			if (ret) {
> +				dev_err(core->dev, "Specified firmware is not present\n");

Doesn't request_firmware already print a warning?

> +				return ret;
> +			}
> +			release_firmware(fw);
> +			core->iris_platform_data = &sc7280_gen2_data;
> +		}
> +	}
> +	return 0;
> +}
> +
>  void iris_core_deinit(struct iris_core *core)
>  {
>  	pm_runtime_resume_and_get(core->dev);

-- 
With best wishes
Dmitry

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

[Dmitry Baryshkov]

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>
> >> ---
> > 
> > [...]
> > 
> >> +int iris_update_platform_data(struct iris_core *core)
> >> +{
> >> +	const char *fwname = NULL;
> >> +	const struct firmware *fw;
> >> +	int ret;
> >> +
> >> +	if (of_device_is_compatible(core->dev->of_node, "qcom,sc7280-venus")) {
> >> +		ret = of_property_read_string_index(core->dev->of_node, "firmware-name", 0,
> >> +					    &fwname);
> >> +		if (ret)
> >> +			return 0;
> >> +
> >> +		if (strstr(fwname, "gen2")) {
> >> +			ret = request_firmware(&fw, fwname, core->dev);
> >> +			if (ret) {
> >> +				dev_err(core->dev, "Specified firmware is not present\n");
> >> +				return ret;
> > 
> > This is fragile - if someone names names their gen1 firmware something like
> > "myproduct_gen2_vidfw.mbn", it's going to match..
> > 
> > Could we instead do something like the explicit format checks in
> > venus/hfi_msgs.c : sys_get_prop_image_version(), based on the **contents**
> > of the binary?
> > 
> 
> I agree that checking for "gen2" as a substring in the firmware name is not
> reliable. Unfortunately, we cannot
> usevenus/hfi_msgs.c:sys_get_prop_image_version() (or any Gen1 HFI query) to
> probe the contents of the binary here, because Gen1 vs Gen2 have
> incompatible HFI protocols—probing a Gen2 image with Gen1 HFI (or
> vice‑versa) isn’t viable in this path.

Can't we perform Gen2 query on Gen1 firmware, get the error and act
accordingly? Or, better, perform Gen1 query on Gen2 firmware, receive
the error from the firmware and act? In the end, your team is handling
the firmware. If you want to support both interfaces, it should be a
runtime check rather than filename matching.

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

-- 
With best wishes
Dmitry

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

[Dikshita Agarwal]

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>
>>>> ---
>>>
>>> [...]
>>>
>>>> +int iris_update_platform_data(struct iris_core *core)
>>>> +{
>>>> +	const char *fwname = NULL;
>>>> +	const struct firmware *fw;
>>>> +	int ret;
>>>> +
>>>> +	if (of_device_is_compatible(core->dev->of_node, "qcom,sc7280-venus")) {
>>>> +		ret = of_property_read_string_index(core->dev->of_node, "firmware-name", 0,
>>>> +					    &fwname);
>>>> +		if (ret)
>>>> +			return 0;
>>>> +
>>>> +		if (strstr(fwname, "gen2")) {
>>>> +			ret = request_firmware(&fw, fwname, core->dev);
>>>> +			if (ret) {
>>>> +				dev_err(core->dev, "Specified firmware is not present\n");
>>>> +				return ret;
>>>
>>> This is fragile - if someone names names their gen1 firmware something like
>>> "myproduct_gen2_vidfw.mbn", it's going to match..
>>>
>>> Could we instead do something like the explicit format checks in
>>> venus/hfi_msgs.c : sys_get_prop_image_version(), based on the **contents**
>>> of the binary?
>>>
>>
>> I agree that checking for "gen2" as a substring in the firmware name is not
>> reliable. Unfortunately, we cannot
>> usevenus/hfi_msgs.c:sys_get_prop_image_version() (or any Gen1 HFI query) to
>> probe the contents of the binary here, because Gen1 vs Gen2 have
>> incompatible HFI protocols—probing a Gen2 image with Gen1 HFI (or
>> vice‑versa) isn’t viable in this path.
> 
> Can't we perform Gen2 query on Gen1 firmware, get the error and act
> accordingly? Or, better, perform Gen1 query on Gen2 firmware, receive
> the error from the firmware and act? In the end, your team is handling
> the firmware. If you want to support both interfaces, it should be a
> runtime check rather than filename matching.
> 
>>
>> 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.
	
2. Booting the firmware and querying it via an HFI system property
Issues with this approach :

- Gen1 and Gen2 use different HFI protocol formats (different packet
layouts, IDs, and message structures). There is no unified HFI message that
both generations can safely accept.

- The HFI protocol provides no version marker in any packet header.
The firmware does not know whether it is being talked to with Gen1‑style
packets or Gen2‑style packets. The driver simply typecasts the memory
buffer into a Gen1 or Gen2 packet type — the firmware has no concept of
“wrong HFI generation”. So it cannot return a dedicated error indicating
“incompatible HFI interface”.


Thanks,
Dikshita

>>
>> Thanks,
>> Dikshita
>>
>>> Konrad
> 

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

[Konrad Dybcio]

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;


Can we agree that VIDEO.VPU.x firmwares are hfigen2? If so, problem also
solved for <=8450

Konrad

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

[Dikshita Agarwal]

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.

> 
> 
> 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

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

[Bryan O'Donoghue]

On 12/02/2026 13:05, 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.
> 
>>
>>
>> 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

I really don't see what the problem with Dikshita's proposal here is 
after all she literally controls the firmware name that goes to 
linux-firmware.

Presumably you can attest to the naming format you have-sent and 
will-send in future.

---
bod

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

[Konrad Dybcio]

On 2/12/26 2:27 PM, Bryan O'Donoghue wrote:
> On 12/02/2026 13:05, 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.
>>
>>>
>>>
>>> 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
> 
> I really don't see what the problem with Dikshita's proposal here is after all she literally controls the firmware name that goes to linux-firmware.

A vendor could name their gen1 binary i_really_wanted_gen2_but_didnt_get_it.mbn,
or perhaps "snapdragon_8_gen_2_venus.mbn" and we can't control it.

Plus I generally see relying on file*names* as a hack (in the same way that
Linux doesn't care about file extensions, but Windows blindly trusts them).
And there's oddball cases like with FW_LOADER_USER_HELPER

Konrad

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

[Dmitry Baryshkov]

On Thu, Feb 12, 2026 at 01:27:15PM +0000, Bryan O'Donoghue wrote:
> On 12/02/2026 13:05, 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.
> > 
> > > 
> > > 
> > > 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
> 
> I really don't see what the problem with Dikshita's proposal here is after
> all she literally controls the firmware name that goes to linux-firmware.
> 
> Presumably you can attest to the naming format you have-sent and will-send
> in future.

Is qcvss8280.mbn using hfigen1 or gen2? Is qcvss8380.mbn using gen1 or
gen2 HFI? I really, really would warn against hardcoding something for
kodiak only, because at a later point there will be a business
requirement and some other platform will be upgraded from gen1 to gen2
in some other way. Also, in many cases, we don't rename the firmware
provided by the vendors (both inside linux-firmware and for the firmware
shipped with the device).

-- 
With best wishes
Dmitry

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@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.

> 
> > 
> > 
> > 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

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

[Dikshita Agarwal]

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

This is not the correct firmware for gen2 to work with kodiak, the correct
firmware (not posted yet) would have VIDEO.VPU.3.4.*

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
> 

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

[Dmitry Baryshkov]

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?

> 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?

> 
> 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

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

[Dikshita Agarwal]

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.

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

> 
>> 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.

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
>>>
> 

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@oss.qualcomm.com> 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@quicinc.com/

[2] https://lore.kernel.org/linux-firmware/20260216144056.524560-1-dmitry.baryshkov@oss.qualcomm.com/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

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

[Dikshita Agarwal]

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.

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

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

[Bryan O'Donoghue]

On 17/02/2026 07:40, Dikshita Agarwal wrote:
> Due to these constraints, I think, the only possible way is to extract the
> version from the firmware binary blob itself.

According to the internet machine

MDT::SW_ID
      GEN1 == 0x0b || 0x0c
      GEN2 == 0x24 (or above one assumes)

If you can verify that with the Iris firmware people we should be able 
to parse that data out of the mdt header and reliably differentiate on it.

---
bod

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

[Dmitry Baryshkov]

On Tue, 17 Feb 2026 at 12:37, Bryan O'Donoghue <bod@kernel.org> wrote:
>
> On 17/02/2026 07:40, Dikshita Agarwal wrote:
> > Due to these constraints, I think, the only possible way is to extract the
> > version from the firmware binary blob itself.
>
> According to the internet machine
>
> MDT::SW_ID
>       GEN1 == 0x0b || 0x0c
>       GEN2 == 0x24 (or above one assumes)

Neither one is correct. I see SW_ID = 0x0e for all VPU binaries in
linux-firmware.

>
> If you can verify that with the Iris firmware people we should be able
> to parse that data out of the mdt header and reliably differentiate on it.
>
> ---
> bod



-- 
With best wishes
Dmitry

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

[Konrad Dybcio]

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

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

[Dmitry Baryshkov]

On Tue, Feb 17, 2026 at 01:10:21PM +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:
> >>>>>>>> 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.

Ack. I for some reason thought that the version is populated more
automatically.

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

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

[Dikshita Agarwal]

On 2/17/2026 5:50 PM, Konrad Dybcio wrote:
> 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?

The two HFI generations do share some lower‑level queue infrastructure, but
the command formats and packet layouts for Gen1 and Gen2 differ.

Because of this, sending a Gen1 HFI_CMD_SYS_INIT into a Gen2 firmware (or
vice‑versa) is not safe. The firmware will interpret the buffer strictly
according to its own expected packet layout, and since there is no
protocol‑level version discriminator, it has no way to recognize that the
host used the wrong HFI format.

Additionally, using a timeout as a discriminator is unreliable. If we issue
a command and receive no response, we cannot differentiate whether it due
to using the wrong HFI generation, or due to a genuine sys_init failure.

So, I will proceed with implementing the solution based on reading the
firmware blob, extracting the version string, and switching between Gen1
and Gen2 HFI accordingly. This avoids protocol ambiguity and does not
require the firmware to support any additional detection mechanism.

Thanks,
Dikshita

> 
> Konrad

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

[Dmitry Baryshkov]

On Fri, Feb 20, 2026 at 11:50:35AM +0530, Dikshita Agarwal wrote:
> 
> 
> On 2/17/2026 5:50 PM, Konrad Dybcio wrote:
> > On 2/17/26 8:40 AM, Dikshita Agarwal wrote:
> >>
> >> 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?
> 
> The two HFI generations do share some lower‑level queue infrastructure, but
> the command formats and packet layouts for Gen1 and Gen2 differ.
> 
> Because of this, sending a Gen1 HFI_CMD_SYS_INIT into a Gen2 firmware (or
> vice‑versa) is not safe. The firmware will interpret the buffer strictly
> according to its own expected packet layout, and since there is no
> protocol‑level version discriminator, it has no way to recognize that the
> host used the wrong HFI format.
> 
> Additionally, using a timeout as a discriminator is unreliable. If we issue
> a command and receive no response, we cannot differentiate whether it due
> to using the wrong HFI generation, or due to a genuine sys_init failure.
> 
> So, I will proceed with implementing the solution based on reading the
> firmware blob, extracting the version string, and switching between Gen1
> and Gen2 HFI accordingly. This avoids protocol ambiguity and does not
> require the firmware to support any additional detection mechanism.

Ack. Please proceed with this idea.

-- 
With best wishes
Dmitry