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

Vishnu Reddy <[email protected]>
Newsgroups org.kernel.vger.linux-devicetree,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-media,org.kernel.vger.stable
Message-ID <20260818-iris-fixes-dma-pseq-fint-v2-0-8dc8c4b3880e@oss.qualcomm.com>
This series addresses three independent issues in the iris video
driver and its devicetree bindings/nodes for SC7280-based platforms:

- 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, found that DMA buffers shared between the CPU and the
  venus video hardware/controller are not in sync. CPU writes to an
  input buffer can remain in CPU cache 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.
  This series adds explicit dma_sync*() calls in the driver for the
  input and output buffers, and declares the dma-coherent property on
  the venus node and its dt-binding, since the venus hardware on
  SC7280 is IO-coherent hardware that performs cache snooping between
  the CPU and the video hardware/controller. Together, these changes
  keep the CPU cache and the DMA buffers in sync.

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

---
Changes in v2:
- Add dma_sync*() calls in driver (Rob Herring)
- Updated commit descriptions.
- Link to v1: https://lore.kernel.org/all/20260801-iris-fixes-dma-pseq-fint-v1-0-aba0cb22f6ab@oss.qualcomm.com

To: Vikash Garodia <[email protected]>
To: Dikshita Agarwal <[email protected]>
To: Abhinav Kumar <[email protected]>
To: Bryan O'Donoghue <[email protected]>
To: Mauro Carvalho Chehab <[email protected]>
To: Rob Herring <[email protected]>
To: Krzysztof Kozlowski <[email protected]>
To: Conor Dooley <[email protected]>
To: Stanimir Varbanov <[email protected]>
To: Bjorn Andersson <[email protected]>
To: Konrad Dybcio <[email protected]>
To: Hans Verkuil <[email protected]>
To: Stefan Schmidt <[email protected]>
To: Hans Verkuil <[email protected]>
To: Mansur Alisha Shaik <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Vishnu Reddy <[email protected]>

---
Vishnu Reddy (5):
      media: iris: Add dma sync calls for input and output buffers
      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_buffer.c                 | 7 +++++++
 drivers/media/platform/qcom/iris/iris_vidc.c                   | 4 ++--
 drivers/media/platform/qcom/iris/iris_vpu_common.c             | 2 +-
 5 files changed, 17 insertions(+), 3 deletions(-)
---
base-commit: e6664f2b33db9b6811eb4cec109f06cb2b4f458d
change-id: 20260818-iris-fixes-dma-pseq-fint-707f14d69753

Best regards,
--  
Vishnu Reddy <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.