.../devicetree/bindings/media/qcom,sc7180-venus.yaml | 15 +++++++++++++++ .../devicetree/bindings/media/qcom,sc7280-venus.yaml | 10 ++-------- .../devicetree/bindings/media/qcom,venus-common.yaml | 15 --------------- arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 11 ----------- drivers/media/platform/qcom/iris/iris_probe.c | 4 ---- drivers/media/platform/qcom/venus/core.c | 6 ++++++ drivers/media/platform/qcom/venus/core.h | 11 +++++++++++ 7 files changed, 34 insertions(+), 38 deletions(-)
As the Venus and Iris drivers are close to the "feature parity" for the
common platforms (SC7280, SM8250), in order to get more attention to
squashing bugs from the Iris driver, flip the switch and default to the
Iris driver if both are enabled. The Iris driver has several
regressions, but hopefully they can be fixed through the development
cycle by the respective team. Also it is better to fail the test than
crash the device (which Venus driver does a lot).
Note: then intention is to land this in 6.21, which might let us to
drop those platforms from the Venus driver in 6.22+.
Testing methodology: fluster test-suite, single-threaded mode, SM8250
device (RB5).
$ ./fluster.py r -j 1 -d GStreamer-H.264-V4L2-Gst1.0 -s -so out-h264.md -ts JVT-AVC_V1
$ ./fluster.py r -j 1 -d GStreamer-H.265-V4L2-Gst1.0 -s -so out-h265.md -ts JCT-VC-HEVC_V1
$ ./fluster.py r -j 1 -d GStreamer-VP9-V4L2-Gst1.0 -s -so out-vp9.md
For H.264:
Only the main set was used on both platforms
On Venus pass 126/135
On Iris pass 78/135
- Fail on Iris, but pass on Venus:
cabac_mot_fld0_full, cabac_mot_mbaff0_full, cabac_mot_picaff0_full,
CAFI1_SVA_C, CAMA1_Sony_C, cama1_vtc_c, cama2_vtc_b, cama3_vtc_b,
CAMACI3_Sony_C, CAMASL3_Sony_B, CAMP_MOT_MBAFF_L30,
CAMP_MOT_MBAFF_L31, CANLMA2_Sony_C, CANLMA3_Sony_C,
cavlc_mot_fld0_full_B, cavlc_mot_mbaff0_full_B,
cavlc_mot_picaff0_full_B, CVCANLMA2_Sony_C, CVFI1_Sony_D, CVFI1_SVA_C,
CVFI2_Sony_H, CVFI2_SVA_C, CVMA1_Sony_D, CVMAPAQP3_Sony_E,
CVMAQP2_Sony_G, CVMAQP3_Sony_D, CVMP_MOT_FLD_L30_B,
CVMP_MOT_FRM_L31_B, CVNLFI1_Sony_C, CVNLFI2_Sony_H, FI1_Sony_E,
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
- Fail on Venus, but pass on Iris:
BA3_SVA_C
For Venus several tests crash the firmware or crash the device,
so test-suite was executed with extra:
-sv CABREF3_Sand_D CAMANL1_TOSHIBA_B CAMA1_TOSHIBA_B \
CAMA3_Sand_E CAMANL2_TOSHIBA_B CAMANL3_Sand_E CAPA1_TOSHIBA_B \
CAPAMA3_Sand_F CVMA1_TOSHIBA_B CVMANL1_TOSHIBA_B CVMANL2_TOSHIBA_B \
CVPA1_TOSHIBA_B
For H.265:
Only the main set was used on both platforms
On Venus pass 135/147
On Iris pass 133/147
- Fail on Iris, but pass on Venus:
INITQP_B_Main10_Sony_1, WP_A_MAIN10_Toshiba_3,
WPP_A_ericsson_MAIN10_2, WPP_B_ericsson_MAIN10_2,
WPP_C_ericsson_MAIN10_2, WPP_E_ericsson_MAIN10_2,
WPP_F_ericsson_MAIN10_2
- Fail on Venus, but pass on Iris:
ipcm_A_NEC_3, ipcm_B_NEC_3, ipcm_C_NEC_3, ipcm_D_NEC_3, ipcm_E_NEC_2,
IPRED_B_Nokia_3, VPSSPSPPS_A_MainConcept_1
For VP9 codec:
On Venus pass 174/311
On Iris pass 232/311
- Fail on Venus, but pass on Iris:
vp90-2-05-resize.ivf, vp90-2-14-resize-10frames-fp-tiles-1-2-4-8,
vp90-2-14-resize-10frames-fp-tiles-1-2,
vp90-2-14-resize-10frames-fp-tiles-1-4,
vp90-2-14-resize-10frames-fp-tiles-1-8,
vp90-2-14-resize-10frames-fp-tiles-2-1,
vp90-2-14-resize-10frames-fp-tiles-2-4,
vp90-2-14-resize-10frames-fp-tiles-2-8,
vp90-2-14-resize-10frames-fp-tiles-4-1,
vp90-2-14-resize-10frames-fp-tiles-4-2,
vp90-2-14-resize-10frames-fp-tiles-4-8,
vp90-2-14-resize-10frames-fp-tiles-8-1,
vp90-2-14-resize-10frames-fp-tiles-8-2,
vp90-2-14-resize-10frames-fp-tiles-8-4-2-1,
vp90-2-14-resize-10frames-fp-tiles-8-4, vp90-2-14-resize-fp-tiles-1-16,
vp90-2-14-resize-fp-tiles-1-2-4-8-16, vp90-2-14-resize-fp-tiles-1-2,
vp90-2-14-resize-fp-tiles-1-4, vp90-2-14-resize-fp-tiles-16-1,
vp90-2-14-resize-fp-tiles-16-2, vp90-2-14-resize-fp-tiles-16-4,
vp90-2-14-resize-fp-tiles-16-8-4-2-1, vp90-2-14-resize-fp-tiles-16-8,
vp90-2-14-resize-fp-tiles-1-8, vp90-2-14-resize-fp-tiles-2-16,
vp90-2-14-resize-fp-tiles-2-1, vp90-2-14-resize-fp-tiles-2-4,
vp90-2-14-resize-fp-tiles-2-8, vp90-2-14-resize-fp-tiles-4-16,
vp90-2-14-resize-fp-tiles-4-1, vp90-2-14-resize-fp-tiles-4-2,
vp90-2-14-resize-fp-tiles-4-8, vp90-2-14-resize-fp-tiles-8-16,
vp90-2-14-resize-fp-tiles-8-1, vp90-2-14-resize-fp-tiles-8-2,
vp90-2-14-resize-fp-tiles-8-4, vp90-2-15-segkey,
vp90-2-21-resize_inter_1280x720_5_1-2, vp90-2-21-resize_inter_1280x720_5_3-4,
vp90-2-21-resize_inter_1280x720_7_1-2, vp90-2-21-resize_inter_1280x720_7_3-4,
vp90-2-21-resize_inter_1920x1080_5_1-2,
vp90-2-21-resize_inter_1920x1080_5_3-4,
vp90-2-21-resize_inter_1920x1080_7_1-2,
vp90-2-21-resize_inter_1920x1080_7_3-4,
vp90-2-21-resize_inter_320x180_5_3-4, vp90-2-21-resize_inter_320x180_7_3-4,
vp90-2-21-resize_inter_320x240_5_3-4, vp90-2-21-resize_inter_320x240_7_3-4,
vp90-2-21-resize_inter_640x360_5_1-2, vp90-2-21-resize_inter_640x360_5_3-4,
vp90-2-21-resize_inter_640x360_7_1-2, vp90-2-21-resize_inter_640x360_7_3-4,
vp90-2-21-resize_inter_640x480_5_1-2, vp90-2-21-resize_inter_640x480_5_3-4,
vp90-2-21-resize_inter_640x480_7_1-2, vp90-2-21-resize_inter_640x480_7_3-4
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
Changes in v2:
- Sorted out SC7280 Chromebook bindings (Stephan)
- Dropped most of ifdef from venus (Vikash, Konrad)
- Added testign results to the cover letter.
- Link to v1: https://lore.kernel.org/r/20251119-venus-iris-flip-switch-v1-1-852369f66e36@oss.qualcomm.com
---
Dmitry Baryshkov (4):
arm64: dts: qcom: sc7280-chrome-common: disable Venus
media: dt-bindings: qcom,sc7280-venus: drop non-PAS support
media: dt-bindings: qcom-sc7180-venus: move video-firmware here
media: qcom: venus: flip the venus/iris switch
.../devicetree/bindings/media/qcom,sc7180-venus.yaml | 15 +++++++++++++++
.../devicetree/bindings/media/qcom,sc7280-venus.yaml | 10 ++--------
.../devicetree/bindings/media/qcom,venus-common.yaml | 15 ---------------
arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 11 -----------
drivers/media/platform/qcom/iris/iris_probe.c | 4 ----
drivers/media/platform/qcom/venus/core.c | 6 ++++++
drivers/media/platform/qcom/venus/core.h | 11 +++++++++++
7 files changed, 34 insertions(+), 38 deletions(-)
---
base-commit: ca3a02fda4da8e2c1cb6baee5d72352e9e2cfaea
change-id: 20251119-venus-iris-flip-switch-d59a3fbc6a4b
prerequisite-change-id: 20260120-iris-sc8280xp-85d13bc60536:v3
prerequisite-patch-id: d34f95892aabfca4695d8b41c4001a23688e72ad
prerequisite-patch-id: 0dd97291d4aa94feb2e915a6a6324ac0031deca8
prerequisite-patch-id: 9de15d81588208683f296b6d48363226df41fbd6
prerequisite-patch-id: 6a89a4c1709b0b543a7d2a03954b7a628f549aa5
prerequisite-patch-id: 668a6b7fec7ed8302ab23c65ad76481be06847f6
prerequisite-patch-id: e423b8d12b47c7414e694625204977e37414ce4e
prerequisite-patch-id: e5be869bdd8a73b5c3d3407b1a47c66c944dc832
Best regards,
--
With best wishes
Dmitry
On 1/26/26 3:09 AM, Dmitry Baryshkov wrote: > As the Venus and Iris drivers are close to the "feature parity" for the > common platforms (SC7280, SM8250), in order to get more attention to > squashing bugs from the Iris driver, flip the switch and default to the > Iris driver if both are enabled. The Iris driver has several > regressions, but hopefully they can be fixed through the development > cycle by the respective team. Also it is better to fail the test than > crash the device (which Venus driver does a lot). > > Note: then intention is to land this in 6.21, which might let us to > drop those platforms from the Venus driver in 6.22+. > > Testing methodology: fluster test-suite, single-threaded mode, SM8250 > device (RB5). > > $ ./fluster.py r -j 1 -d GStreamer-H.264-V4L2-Gst1.0 -s -so out-h264.md -ts JVT-AVC_V1 > $ ./fluster.py r -j 1 -d GStreamer-H.265-V4L2-Gst1.0 -s -so out-h265.md -ts JCT-VC-HEVC_V1 > $ ./fluster.py r -j 1 -d GStreamer-VP9-V4L2-Gst1.0 -s -so out-vp9.md > > For H.264: > > Only the main set was used on both platforms > > On Venus pass 126/135 > On Iris pass 78/135 This sounds a little bad.. [...] > For Venus several tests crash the firmware or crash the device, > so test-suite was executed with extra: But this sounds way way worse [...] > For H.265: > > Only the main set was used on both platforms > > On Venus pass 135/147 > On Iris pass 133/147 [...] > For VP9 codec: > > On Venus pass 174/311 > On Iris pass 232/311 These two give me hope.. Ultimately, I think it's the right thing to do, if only to prevent the crashes you've described.. Konrad
On Tue, Jan 27, 2026 at 12:43:36PM +0100, Konrad Dybcio wrote: > On 1/26/26 3:09 AM, Dmitry Baryshkov wrote: > > As the Venus and Iris drivers are close to the "feature parity" for the > > common platforms (SC7280, SM8250), in order to get more attention to > > squashing bugs from the Iris driver, flip the switch and default to the > > Iris driver if both are enabled. The Iris driver has several > > regressions, but hopefully they can be fixed through the development > > cycle by the respective team. Also it is better to fail the test than > > crash the device (which Venus driver does a lot). > > > > Note: then intention is to land this in 6.21, which might let us to > > drop those platforms from the Venus driver in 6.22+. > > > > Testing methodology: fluster test-suite, single-threaded mode, SM8250 > > device (RB5). > > > > $ ./fluster.py r -j 1 -d GStreamer-H.264-V4L2-Gst1.0 -s -so out-h264.md -ts JVT-AVC_V1 > > $ ./fluster.py r -j 1 -d GStreamer-H.265-V4L2-Gst1.0 -s -so out-h265.md -ts JCT-VC-HEVC_V1 > > $ ./fluster.py r -j 1 -d GStreamer-VP9-V4L2-Gst1.0 -s -so out-vp9.md > > > > For H.264: > > > > Only the main set was used on both platforms > > > > On Venus pass 126/135 > > On Iris pass 78/135 > > This sounds a little bad.. I'd let Vikash comment here, we were promised feature parity for Venus / Iris drivers before accepting the latter one. The list of tests passing for Venus, but failing for Iris: > |BA3_SVA_C|✔️| < |cabac_mot_fld0_full|✔️| < |cabac_mot_mbaff0_full|✔️| < |cabac_mot_picaff0_full|✔️| < |CAFI1_SVA_C|✔️| < |CAMA1_Sony_C|✔️| < |cama1_vtc_c|✔️| < |cama2_vtc_b|✔️| < |cama3_vtc_b|✔️| < |CAMACI3_Sony_C|✔️| < |CAMASL3_Sony_B|✔️| < |CAMP_MOT_MBAFF_L30|✔️| < |CAMP_MOT_MBAFF_L31|✔️| < |CANLMA2_Sony_C|✔️| < |CANLMA3_Sony_C|✔️| < |cavlc_mot_fld0_full_B|✔️| < |cavlc_mot_mbaff0_full_B|✔️| < |cavlc_mot_picaff0_full_B|✔️| < |CVCANLMA2_Sony_C|✔️| < |CVFI1_Sony_D|✔️| < |CVFI1_SVA_C|✔️| < |CVFI2_Sony_H|✔️| < |CVFI2_SVA_C|✔️| < |CVMA1_Sony_D|✔️| < |CVMAPAQP3_Sony_E|✔️| < |CVMAQP2_Sony_G|✔️| < |CVMAQP3_Sony_D|✔️| < |CVMP_MOT_FLD_L30_B|✔️| < |CVMP_MOT_FRM_L31_B|✔️| < |CVNLFI1_Sony_C|✔️| < |CVNLFI2_Sony_H|✔️| < |FI1_Sony_E|✔️| < |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|✔️| > > [...] > > > For Venus several tests crash the firmware or crash the device, > > so test-suite was executed with extra: > > But this sounds way way worse > > [...] > > > For H.265: > > > > Only the main set was used on both platforms > > > > On Venus pass 135/147 > > On Iris pass 133/147 > > [...] > > > For VP9 codec: > > > > On Venus pass 174/311 > > On Iris pass 232/311 > > These two give me hope.. > > Ultimately, I think it's the right thing to do, if only to prevent the > crashes you've described.. Yep. -- With best wishes Dmitry
On 1/27/2026 5:35 PM, Dmitry Baryshkov wrote: > On Tue, Jan 27, 2026 at 12:43:36PM +0100, Konrad Dybcio wrote: >> On 1/26/26 3:09 AM, Dmitry Baryshkov wrote: >>> As the Venus and Iris drivers are close to the "feature parity" for the >>> common platforms (SC7280, SM8250), in order to get more attention to >>> squashing bugs from the Iris driver, flip the switch and default to the >>> Iris driver if both are enabled. The Iris driver has several >>> regressions, but hopefully they can be fixed through the development >>> cycle by the respective team. Also it is better to fail the test than >>> crash the device (which Venus driver does a lot). >>> >>> Note: then intention is to land this in 6.21, which might let us to >>> drop those platforms from the Venus driver in 6.22+. >>> >>> Testing methodology: fluster test-suite, single-threaded mode, SM8250 >>> device (RB5). >>> >>> $ ./fluster.py r -j 1 -d GStreamer-H.264-V4L2-Gst1.0 -s -so out-h264.md -ts JVT-AVC_V1 >>> $ ./fluster.py r -j 1 -d GStreamer-H.265-V4L2-Gst1.0 -s -so out-h265.md -ts JCT-VC-HEVC_V1 >>> $ ./fluster.py r -j 1 -d GStreamer-VP9-V4L2-Gst1.0 -s -so out-vp9.md >>> >>> For H.264: >>> >>> Only the main set was used on both platforms >>> >>> On Venus pass 126/135 >>> On Iris pass 78/135 >> >> This sounds a little bad.. > > I'd let Vikash comment here, we were promised feature parity for Venus / > Iris drivers before accepting the latter one. > > The list of tests passing for Venus, but failing for Iris: > >> |BA3_SVA_C|✔️| This need to be checked. Similar failure was seen in SM8550 due to unssuported profile V4L2_MPEG_VIDEO_H264_PROFILE_EXTENDED. > < |cabac_mot_fld0_full|✔️| > < |cabac_mot_mbaff0_full|✔️| > < |cabac_mot_picaff0_full|✔️| > < |CAFI1_SVA_C|✔️| > < |CAMA1_Sony_C|✔️| > < |cama1_vtc_c|✔️| > < |cama2_vtc_b|✔️| > < |cama3_vtc_b|✔️| > < |CAMACI3_Sony_C|✔️| > < |CAMASL3_Sony_B|✔️| > < |CAMP_MOT_MBAFF_L30|✔️| > < |CAMP_MOT_MBAFF_L31|✔️| > < |CANLMA2_Sony_C|✔️| > < |CANLMA3_Sony_C|✔️| > < |cavlc_mot_fld0_full_B|✔️| > < |cavlc_mot_mbaff0_full_B|✔️| > < |cavlc_mot_picaff0_full_B|✔️| > < |CVCANLMA2_Sony_C|✔️| > < |CVFI1_Sony_D|✔️| > < |CVFI1_SVA_C|✔️| > < |CVFI2_Sony_H|✔️| > < |CVFI2_SVA_C|✔️| > < |CVMA1_Sony_D|✔️| > < |CVMAPAQP3_Sony_E|✔️| > < |CVMAQP2_Sony_G|✔️| > < |CVMAQP3_Sony_D|✔️| > < |CVMP_MOT_FLD_L30_B|✔️| > < |CVMP_MOT_FRM_L31_B|✔️| > < |CVNLFI1_Sony_C|✔️| > < |CVNLFI2_Sony_H|✔️| > < |FI1_Sony_E|✔️| > < |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|✔️| Above tests are related to interlace support. As of now, interlace support is not there in iris driver, as it is gradually evolving w.r.t enabling available hardware codecs. > > >> >> [...] >> >>> For Venus several tests crash the firmware or crash the device, >>> so test-suite was executed with extra: >> >> But this sounds way way worse >> >> [...] >> >>> For H.265: >>> >>> Only the main set was used on both platforms >>> >>> On Venus pass 135/147 >>> On Iris pass 133/147 >> >> [...] >> >>> For VP9 codec: >>> >>> On Venus pass 174/311 >>> On Iris pass 232/311 >> >> These two give me hope.. >> >> Ultimately, I think it's the right thing to do, if only to prevent the >> crashes you've described.. > > Yep. > Regards, Vikash
© 2016 - 2026 Red Hat, Inc.