From 663b9536fc8704d1b05a24bf6b4848d57338b53b Mon Sep 17 00:00:00 2001 From: Vishnu Reddy Date: Sat, 1 Aug 2026 13:07:27 +0530 Subject: [PATCH 1/3] FROMLIST: dt-bindings: media: qcom,sc7280-venus: Add dma-coherent property While testing with some higher resolution clips, the venus hardware triggers a fault due to wrong input data being received. Corruption was also observed in the captured output when the client dumped it to a file. On debugging, this was traced to the venus node not declaring dma-coherent. As a result, DMA buffers shared between the CPU and the venus video hardware/controller are not guaranteed to be I/O coherent: CPU writes to an input buffer can remain in CPU caches without being visible to the video hardware when it reads the same buffer, so the hardware receives input data that does not match what the CPU wrote. Likewise, on the capture path, data written by the video hardware to the output buffer may not be visible to the CPU, so the client reads stale or partial data, resulting in corruption. Add the dma-coherent property to the venus node so that DMA buffers shared between the CPU and the video hardware and controller remain coherent. Link: https://lore.kernel.org/all/20260801-iris-fixes-dma-pseq-fint-v1-1-aba0cb22f6ab@oss.qualcomm.com/ Fixes: 37613aee2179 ("arm64: dts: qcom: sc7280: Add venus DT node") Cc: stable@vger.kernel.org Signed-off-by: Vishnu Reddy --- Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml index 413c5b4ee6504..a553c28660e12 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml @@ -41,6 +41,7 @@ properties: - const: iface - const: vcodec_core - const: vcodec_bus + dma-coherent: true iommus: minItems: 1 @@ -86,6 +87,7 @@ properties: required: - compatible + - dma-coherent - power-domain-names - iommus @@ -119,6 +121,7 @@ examples: interconnects = <&gem_noc MASTER_APPSS_PROC 0 &cnoc2 SLAVE_VENUS_CFG 0>, <&mmss_noc MASTER_VIDEO_P0 0 &mc_virt SLAVE_EBI1 0>; interconnect-names = "cpu-cfg", "video-mem"; + dma-coherent; iommus = <&apps_smmu 0x2180 0x20>, <&apps_smmu 0x2184 0x20>; From 8cb1fc2b6da2a6b463a93f20ef67cb98c6e26c53 Mon Sep 17 00:00:00 2001 From: Vishnu Reddy Date: Sat, 1 Aug 2026 13:07:28 +0530 Subject: [PATCH 2/3] FROMLIST: arm64: dts: qcom: sc7280: Add dma-coherent property into venus node While testing with some higher resolution clips, the venus hardware triggers a fault due to wrong input data being received. Corruption was also observed in the captured output when the client dumped it to a file. On debugging, this was traced to the venus node not declaring dma-coherent. As a result, DMA buffers shared between the CPU and the venus video hardware/controller are not guaranteed to be I/O coherent: CPU writes to an input buffer can remain in CPU caches without being visible to the video hardware when it reads the same buffer, so the hardware receives input data that does not match what the CPU wrote. Likewise, on the capture path, data written by the video hardware to the output buffer may not be visible to the CPU, so the client reads stale or partial data, resulting in corruption. Add the dma-coherent property to the venus node so that DMA buffers shared between the CPU and the video hardware and controller remain coherent. Link: https://lore.kernel.org/all/20260801-iris-fixes-dma-pseq-fint-v1-2-aba0cb22f6ab@oss.qualcomm.com/ Fixes: 37613aee2179 ("arm64: dts: qcom: sc7280: Add venus DT node") Cc: stable@vger.kernel.org Signed-off-by: Vishnu Reddy --- arch/arm64/boot/dts/qcom/sc7280.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi index 51dcd31796844..92be04f93b009 100644 --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi @@ -4986,6 +4986,7 @@ interconnects = <&gem_noc MASTER_APPSS_PROC 0 &cnoc2 SLAVE_VENUS_CFG 0>, <&mmss_noc MASTER_VIDEO_P0 0 &mc_virt SLAVE_EBI1 0>; interconnect-names = "cpu-cfg", "video-mem"; + dma-coherent; iommus = <&apps_smmu 0x2180 0x20>; memory-region = <&video_mem>; From 0c7f7abaa52e22139ab5567c287dd4233327706d Mon Sep 17 00:00:00 2001 From: Vishnu Reddy Date: Sat, 1 Aug 2026 13:07:30 +0530 Subject: [PATCH 3/3] FROMLIST: media: iris: Fix frame interval enumeration for non-divisor framerates iris_enum_frameintervals() advertised frame intervals using V4L2_FRMIVAL_TYPE_STEPWISE with step=1/MAXIMUM_FPS where MAXIMUM_FPS is 480. This caused client to enumerate only framerates of the form MAXIMUM_FPS/n (where n is a positive integer), restricting support to exact divisors of MAXIMUM_FPS (e.g., 480, 240, 160, 120, 96, 80, 60, 30, 24, 1). Framerates that are not exact divisors of MAXIMUM_FPS, such as 29 fps, 25 fps, were excluded from the enumerated list. There is no hardware restriction to framerates that are exact divisors of MAXIMUM_FPS. This caused GStreamer caps negotiation to fail with an "internal data stream error" when encoding content at such framerates. Fix this by using V4L2_FRMIVAL_TYPE_CONTINUOUS. With CONTINUOUS type, GStreamer creates a continuous framerate range [1, max_fps], allowing any integer framerate within the range to pass caps negotiation. The step field is set to 1/1 as required by the V4L2 specification for continuous frame intervals. Link: https://lore.kernel.org/all/20260801-iris-fixes-dma-pseq-fint-v1-4-aba0cb22f6ab@oss.qualcomm.com/ Fixes: a6882431a138 ("media: iris: Add support for ENUM_FRAMESIZES/FRAMEINTERVALS for encoder") Cc: stable@vger.kernel.org Signed-off-by: Vishnu Reddy --- drivers/media/platform/qcom/iris/iris_vidc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/qcom/iris/iris_vidc.c b/drivers/media/platform/qcom/iris/iris_vidc.c index 8975ee3d6c64a..c4f96dba74351 100644 --- a/drivers/media/platform/qcom/iris/iris_vidc.c +++ b/drivers/media/platform/qcom/iris/iris_vidc.c @@ -440,14 +440,14 @@ static int iris_enum_frameintervals(struct file *filp, void *fh, mbpf = NUM_MBS_PER_FRAME(fival->height, fival->width); fps = DIV_ROUND_UP(core->iris_platform_data->max_core_mbps, mbpf); - fival->type = V4L2_FRMIVAL_TYPE_STEPWISE; + fival->type = V4L2_FRMIVAL_TYPE_CONTINUOUS; fival->stepwise.min.numerator = 1; fival->stepwise.min.denominator = min_t(u32, fps, MAXIMUM_FPS); fival->stepwise.max.numerator = 1; fival->stepwise.max.denominator = 1; fival->stepwise.step.numerator = 1; - fival->stepwise.step.denominator = MAXIMUM_FPS; + fival->stepwise.step.denominator = 1; return 0; }