Re: [PATCH 0/4] media: iris: Fix DMA coherency, power-off ordering, and frame interval issues

From: Bryan O'Donoghue

Date: Wed Aug 05 2026 - 00:41:49 EST


On 01/08/2026 08:37, Vishnu Reddy wrote:
This series fixes a set of issues found in the Qualcomm iris video
driver and the venus/kodiak devicetree bindings:

- The venus devicetree nodes for sc7280-based bindings and the kodiak
platform do not declare dma-coherent, which allows the CPU and the
video hardware/controller to see stale or inconsistent data in DMA
buffers they share. This causes hardware faults on input and
corruption of captured output when the client dumps it, observed
while testing with some higher resolution clips.

- iris_vpu_power_off_hw() disables the power domain before disabling
the associated clocks, reversing the correct power-down order and
risking clock-controller access after its power domain is already
removed.

- iris_enum_frameintervals() advertised frame intervals as
V4L2_FRMIVAL_TYPE_STEPWISE with a fixed step derived from the
maximum FPS, which excluded valid framerates that aren't exact
divisors of the maximum and broke GStreamer caps negotiation for
those framerates. Switching to V4L2_FRMIVAL_TYPE_CONTINUOUS fixes
this.

Signed-off-by: Vishnu Reddy <busanna.reddy@xxxxxxxxxxxxxxxx>
---
Vishnu Reddy (4):
dt-bindings: media: qcom,sc7280-venus: Add dma-coherent property
arm64: dts: qcom: sc7280: Add dma-coherent property into venus node
media: iris: Fix power-off ordering to disable power domain after clocks
media: iris: Fix frame interval enumeration for non-divisor framerates

Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml | 5 +++++
arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 ++
drivers/media/platform/qcom/iris/iris_vidc.c | 4 ++--
drivers/media/platform/qcom/iris/iris_vpu_common.c | 2 +-
4 files changed, 10 insertions(+), 3 deletions(-)
---
base-commit: 415606a7be939835db9b0d6b711887586646346d
change-id: 20260801-iris-fixes-dma-pseq-fint-8345b2d67e3d

Best regards,
--
Vishnu Reddy <busanna.reddy@xxxxxxxxxxxxxxxx>


Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>