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

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

[Vishnu Reddy]

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

[PATCH 1/4] dt-bindings: media: qcom,sc7280-venus: Add dma-coherent property

[Vishnu Reddy]

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.

Fixes: 37613aee2179 ("arm64: dts: qcom: sc7280: Add venus DT node")
Cc: stable@vger.kernel.org
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml
index 9725fcb761dc..cc31f3ba7e7e 100644
--- a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml
@@ -42,6 +42,8 @@ properties:
       - const: vcodec_core
       - const: vcodec_bus
 
+  dma-coherent: true
+
   iommus:
     maxItems: 1
 
@@ -85,6 +87,7 @@ properties:
 
 required:
   - compatible
+  - dma-coherent
   - power-domain-names
   - iommus
 
@@ -119,6 +122,8 @@ examples:
                         <&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>;

-- 
2.34.1

[PATCH 2/4] arm64: dts: qcom: sc7280: Add dma-coherent property into venus node

[Vishnu Reddy]

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.

Fixes: 37613aee2179 ("arm64: dts: qcom: sc7280: Add venus DT node")
Cc: stable@vger.kernel.org
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index f74fa66f1a67..98184760b4bf 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -5024,6 +5024,8 @@ venus: video-codec@aa00000 {
 					<&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>;
 

-- 
2.34.1

[PATCH 3/4] media: iris: Fix power-off ordering to disable power domain after clocks

[Vishnu Reddy]

In iris_vpu_power_off_hw(), iris_disable_power_domains() was called
before the associated clocks (IRIS_BSE_HW_CLK, IRIS_HW_AHB_CLK,
IRIS_HW_CLK) were disabled and unprepared. This reverses the correct
power-down sequence: with the power domain already removed, the
subsequent clk_disable_unprepare() calls end up operating on
clock-controller hardware that is no longer powered, which can hang
or behave unpredictably.

Reorder the calls so iris_disable_power_domains() runs after all
three clocks are disabled, ensuring clocks are always turned off
while their power domain is still active, and mirroring the reverse
of the power-on sequence.

Fixes: bb8a95aa038e ("media: iris: implement power management")
Cc: stable@vger.kernel.org
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
---
 drivers/media/platform/qcom/iris/iris_vpu_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.c b/drivers/media/platform/qcom/iris/iris_vpu_common.c
index e4847c107709..3cd493b06d84 100644
--- a/drivers/media/platform/qcom/iris/iris_vpu_common.c
+++ b/drivers/media/platform/qcom/iris/iris_vpu_common.c
@@ -223,10 +223,10 @@ int iris_vpu_power_off_controller(struct iris_core *core)
 void iris_vpu_power_off_hw(struct iris_core *core)
 {
 	dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], false);
-	iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
 	iris_disable_unprepare_clock(core, IRIS_BSE_HW_CLK);
 	iris_disable_unprepare_clock(core, IRIS_HW_AHB_CLK);
 	iris_disable_unprepare_clock(core, IRIS_HW_CLK);
+	iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
 }
 
 void iris_vpu_power_off(struct iris_core *core)

-- 
2.34.1

[PATCH 4/4] media: iris: Fix frame interval enumeration for non-divisor framerates

[Vishnu Reddy]

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.

Fixes: a6882431a138 ("media: iris: Add support for ENUM_FRAMESIZES/FRAMEINTERVALS for encoder")
Cc: stable@vger.kernel.org
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
---
 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 fcbc60016bee..8f20cb281a93 100644
--- a/drivers/media/platform/qcom/iris/iris_vidc.c
+++ b/drivers/media/platform/qcom/iris/iris_vidc.c
@@ -438,14 +438,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;
 }

-- 
2.34.1

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

[Bryan O'Donoghue]

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

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

Re: [PATCH 2/4] arm64: dts: qcom: sc7280: Add dma-coherent property into venus node

[Deepa Guthyappa Madivalara]

On 8/1/2026 12:37 AM, Vishnu Reddy wrote:
> 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.
>
> Fixes: 37613aee2179 ("arm64: dts: qcom: sc7280: Add venus DT node")
> Cc: stable@vger.kernel.org
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> ---
>   arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index f74fa66f1a67..98184760b4bf 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -5024,6 +5024,8 @@ venus: video-codec@aa00000 {
>   					<&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>;

> Is this fix applicable to only Kodiak platform?
> Or are there other smmu coherent platforms that might need a similar fix?
>

Re: [PATCH 1/4] dt-bindings: media: qcom,sc7280-venus: Add dma-coherent property

[Rob Herring]

On Sat, Aug 01, 2026 at 01:07:27PM +0530, Vishnu Reddy wrote:
> 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.

The only side effect of 'dma-coherent' not being present should be doing 
unnecessary cache flushes. It should still work. Maybe you are missing 
some DMA API sync functions?

Rob

Re: [PATCH 1/4] dt-bindings: media: qcom,sc7280-venus: Add dma-coherent property

[Krzysztof Kozlowski]

On Sat, Aug 01, 2026 at 01:07:27PM +0530, Vishnu Reddy wrote:
> 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.

This is confusing - dma-coherent saves you from syncing the buffers, so
how could it solve the issue? You basically skip certain cache sync
operations, not add them.

Best regards,
Krzysztof

Re: [PATCH 2/4] arm64: dts: qcom: sc7280: Add dma-coherent property into venus node

[Krzysztof Kozlowski]

On Sat, Aug 01, 2026 at 01:07:28PM +0530, Vishnu Reddy wrote:
> 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.
> 
> Fixes: 37613aee2179 ("arm64: dts: qcom: sc7280: Add venus DT node")

Really does not look like a fix. How skipping a cache sync can fix
anything exactly?

Best regards,
Krzysztof

Re: [PATCH 1/4] dt-bindings: media: qcom,sc7280-venus: Add dma-coherent property

[Vishnu Reddy]

On 8/11/2026 7:21 PM, Rob Herring wrote:
> On Sat, Aug 01, 2026 at 01:07:27PM +0530, Vishnu Reddy wrote:
>> 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.
> The only side effect of 'dma-coherent' not being present should be doing 
> unnecessary cache flushes. It should still work. Maybe you are missing 
> some DMA API sync functions?

dma-coherent tells the kernel that this device DMA path is hardware-coherent,
so the SMMU maps its buffers as cacheable. That attribute is what causes the
coherent interconnect to snoop CPU cache lines on every VPU transaction, so
hardware keeps CPU caches and VPU visible memory in sync — which is why the
dma-coherent property lets us skip the unnecessary cache clean/invalidate.

If a device doesn't support I/O coherence, its buffers would instead be mapped
non-cacheable, no snooping would occur, and the driver would need explicit
dma_sync_*() calls at each transition. Venus on SC7280 does support I/O
coherence, so dma-coherent describes that existing hardware capability to
the DMA subsystem.

> Rob
>

Re: [PATCH 2/4] arm64: dts: qcom: sc7280: Add dma-coherent property into venus node

[Vishnu Reddy]

On 8/13/2026 2:49 PM, Krzysztof Kozlowski wrote:
> On Sat, Aug 01, 2026 at 01:07:28PM +0530, Vishnu Reddy wrote:
>> 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.
>>
>> Fixes: 37613aee2179 ("arm64: dts: qcom: sc7280: Add venus DT node")
> Really does not look like a fix. How skipping a cache sync can fix
> anything exactly?

dma-coherent tells the kernel that this device DMA path is hardware-coherent,
so the SMMU maps its buffers as cacheable. That attribute is what causes the
coherent interconnect to snoop CPU cache lines on every VPU transaction, so
hardware keeps CPU caches and VPU-visible memory in sync — which is why the
dma-coherent property lets us skip the unnecessary cache clean/invalidate.

If a device doesn't support I/O coherence, its buffers would instead be mapped
non-cacheable, no snooping would occur, and the driver would need explicit
dma_sync_*() calls at each transition. Venus on SC7280 does support I/O
coherence, so dma-coherent describes that existing hardware capability to
the DMA subsystem.

> Best regards,
> Krzysztof
>
>

Re: [PATCH 2/4] arm64: dts: qcom: sc7280: Add dma-coherent property into venus node

[Krzysztof Kozlowski]

On 14/08/2026 07:29, Vishnu Reddy wrote:
> 
> On 8/13/2026 2:49 PM, Krzysztof Kozlowski wrote:
>> On Sat, Aug 01, 2026 at 01:07:28PM +0530, Vishnu Reddy wrote:
>>> 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.
>>>
>>> Fixes: 37613aee2179 ("arm64: dts: qcom: sc7280: Add venus DT node")
>> Really does not look like a fix. How skipping a cache sync can fix
>> anything exactly?
> 
> dma-coherent tells the kernel that this device DMA path is hardware-coherent,
> so the SMMU maps its buffers as cacheable. That attribute is what causes the
> coherent interconnect to snoop CPU cache lines on every VPU transaction, so
> hardware keeps CPU caches and VPU-visible memory in sync — which is why the
> dma-coherent property lets us skip the unnecessary cache clean/invalidate.

You just repeated what I wrote. What for?

> 
> If a device doesn't support I/O coherence, its buffers would instead be mapped
> non-cacheable, no snooping would occur, and the driver would need explicit
> dma_sync_*() calls at each transition. Venus on SC7280 does support I/O
> coherence, so dma-coherent describes that existing hardware capability to
> the DMA subsystem.

How does this anyhow explain your commit msg? Are you saying driver is
buggy that it misses sync calls?

Best regards,
Krzysztof

Re: [PATCH 2/4] arm64: dts: qcom: sc7280: Add dma-coherent property into venus node

[Vishnu Reddy]

On 8/14/2026 12:01 PM, Krzysztof Kozlowski wrote:
> On 14/08/2026 07:29, Vishnu Reddy wrote:
>> On 8/13/2026 2:49 PM, Krzysztof Kozlowski wrote:
>>> On Sat, Aug 01, 2026 at 01:07:28PM +0530, Vishnu Reddy wrote:
>>>> 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.
>>>>
>>>> Fixes: 37613aee2179 ("arm64: dts: qcom: sc7280: Add venus DT node")
>>> Really does not look like a fix. How skipping a cache sync can fix
>>> anything exactly?
>> dma-coherent tells the kernel that this device DMA path is hardware-coherent,
>> so the SMMU maps its buffers as cacheable. That attribute is what causes the
>> coherent interconnect to snoop CPU cache lines on every VPU transaction, so
>> hardware keeps CPU caches and VPU-visible memory in sync — which is why the
>> dma-coherent property lets us skip the unnecessary cache clean/invalidate.
> You just repeated what I wrote. What for?
>
>> If a device doesn't support I/O coherence, its buffers would instead be mapped
>> non-cacheable, no snooping would occur, and the driver would need explicit
>> dma_sync_*() calls at each transition. Venus on SC7280 does support I/O
>> coherence, so dma-coherent describes that existing hardware capability to
>> the DMA subsystem.
> How does this anyhow explain your commit msg? Are you saying driver is
> buggy that it misses sync calls?

No, driver is not buggy here. dma-coherent flag is missed in the dt node.

> Best regards,
> Krzysztof
>

Re: [PATCH 2/4] arm64: dts: qcom: sc7280: Add dma-coherent property into venus node

[Krzysztof Kozlowski]

On 14/08/2026 11:49, Vishnu Reddy wrote:
> 
> On 8/14/2026 12:01 PM, Krzysztof Kozlowski wrote:
>> On 14/08/2026 07:29, Vishnu Reddy wrote:
>>> On 8/13/2026 2:49 PM, Krzysztof Kozlowski wrote:
>>>> On Sat, Aug 01, 2026 at 01:07:28PM +0530, Vishnu Reddy wrote:
>>>>> 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.
>>>>>
>>>>> Fixes: 37613aee2179 ("arm64: dts: qcom: sc7280: Add venus DT node")
>>>> Really does not look like a fix. How skipping a cache sync can fix
>>>> anything exactly?
>>> dma-coherent tells the kernel that this device DMA path is hardware-coherent,
>>> so the SMMU maps its buffers as cacheable. That attribute is what causes the
>>> coherent interconnect to snoop CPU cache lines on every VPU transaction, so
>>> hardware keeps CPU caches and VPU-visible memory in sync — which is why the
>>> dma-coherent property lets us skip the unnecessary cache clean/invalidate.
>> You just repeated what I wrote. What for?
>>
>>> If a device doesn't support I/O coherence, its buffers would instead be mapped
>>> non-cacheable, no snooping would occur, and the driver would need explicit
>>> dma_sync_*() calls at each transition. Venus on SC7280 does support I/O
>>> coherence, so dma-coherent describes that existing hardware capability to
>>> the DMA subsystem.
>> How does this anyhow explain your commit msg? Are you saying driver is
>> buggy that it misses sync calls?
> 
> No, driver is not buggy here. dma-coherent flag is missed in the dt node.

Again, no... or explain why. Missing dma-coherent is not a fix, but
rather optimisation, but you claimed it is a fix. Explain why.

Best regards,
Krzysztof

Re: [PATCH 2/4] arm64: dts: qcom: sc7280: Add dma-coherent property into venus node

[Vishnu Reddy]

On 8/14/2026 3:26 PM, Krzysztof Kozlowski wrote:
> On 14/08/2026 11:49, Vishnu Reddy wrote:
>> On 8/14/2026 12:01 PM, Krzysztof Kozlowski wrote:
>>> On 14/08/2026 07:29, Vishnu Reddy wrote:
>>>> On 8/13/2026 2:49 PM, Krzysztof Kozlowski wrote:
>>>>> On Sat, Aug 01, 2026 at 01:07:28PM +0530, Vishnu Reddy wrote:
>>>>>> 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.
>>>>>>
>>>>>> Fixes: 37613aee2179 ("arm64: dts: qcom: sc7280: Add venus DT node")
>>>>> Really does not look like a fix. How skipping a cache sync can fix
>>>>> anything exactly?
>>>> dma-coherent tells the kernel that this device DMA path is hardware-coherent,
>>>> so the SMMU maps its buffers as cacheable. That attribute is what causes the
>>>> coherent interconnect to snoop CPU cache lines on every VPU transaction, so
>>>> hardware keeps CPU caches and VPU-visible memory in sync — which is why the
>>>> dma-coherent property lets us skip the unnecessary cache clean/invalidate.
>>> You just repeated what I wrote. What for?
>>>
>>>> If a device doesn't support I/O coherence, its buffers would instead be mapped
>>>> non-cacheable, no snooping would occur, and the driver would need explicit
>>>> dma_sync_*() calls at each transition. Venus on SC7280 does support I/O
>>>> coherence, so dma-coherent describes that existing hardware capability to
>>>> the DMA subsystem.
>>> How does this anyhow explain your commit msg? Are you saying driver is
>>> buggy that it misses sync calls?
>> No, driver is not buggy here. dma-coherent flag is missed in the dt node.
> Again, no... or explain why. Missing dma-coherent is not a fix, but
> rather optimisation, but you claimed it is a fix. Explain why.

Is the dma-coherent flag only for skipping cache sync?
I might be repeating here — it enables the hardware level snoop between CPU
caches and DMA memory. Without dma-coherent, the CPU cache and the memory
which VPU accesses aren't in sync at the hardware level, which is what
caused the corruption. So dma-coherent is the proper fix here, and that's
why I've mentioned it as a fix. Do you have any opinion on how you'd prefer
to handle this? Please share.

> Best regards,
> Krzysztof
>

Re: [PATCH 2/4] arm64: dts: qcom: sc7280: Add dma-coherent property into venus node

[Krzysztof Kozlowski]

On 14/08/2026 12:24, Vishnu Reddy wrote:
> 
> On 8/14/2026 3:26 PM, Krzysztof Kozlowski wrote:
>> On 14/08/2026 11:49, Vishnu Reddy wrote:
>>> On 8/14/2026 12:01 PM, Krzysztof Kozlowski wrote:
>>>> On 14/08/2026 07:29, Vishnu Reddy wrote:
>>>>> On 8/13/2026 2:49 PM, Krzysztof Kozlowski wrote:
>>>>>> On Sat, Aug 01, 2026 at 01:07:28PM +0530, Vishnu Reddy wrote:
>>>>>>> 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.
>>>>>>>
>>>>>>> Fixes: 37613aee2179 ("arm64: dts: qcom: sc7280: Add venus DT node")
>>>>>> Really does not look like a fix. How skipping a cache sync can fix
>>>>>> anything exactly?
>>>>> dma-coherent tells the kernel that this device DMA path is hardware-coherent,
>>>>> so the SMMU maps its buffers as cacheable. That attribute is what causes the
>>>>> coherent interconnect to snoop CPU cache lines on every VPU transaction, so
>>>>> hardware keeps CPU caches and VPU-visible memory in sync — which is why the
>>>>> dma-coherent property lets us skip the unnecessary cache clean/invalidate.
>>>> You just repeated what I wrote. What for?
>>>>
>>>>> If a device doesn't support I/O coherence, its buffers would instead be mapped
>>>>> non-cacheable, no snooping would occur, and the driver would need explicit
>>>>> dma_sync_*() calls at each transition. Venus on SC7280 does support I/O
>>>>> coherence, so dma-coherent describes that existing hardware capability to
>>>>> the DMA subsystem.
>>>> How does this anyhow explain your commit msg? Are you saying driver is
>>>> buggy that it misses sync calls?
>>> No, driver is not buggy here. dma-coherent flag is missed in the dt node.
>> Again, no... or explain why. Missing dma-coherent is not a fix, but
>> rather optimisation, but you claimed it is a fix. Explain why.
> 
> Is the dma-coherent flag only for skipping cache sync?
> I might be repeating here — it enables the hardware level snoop between CPU
> caches and DMA memory. Without dma-coherent, the CPU cache and the memory
> which VPU accesses aren't in sync at the hardware level, which is what

They are in sync, because driver explicitly MUST sync it.

You cannot have uncoherent accesses without proper DMA cache syncing
operations.

> caused the corruption. So dma-coherent is the proper fix here, and that's
> why I've mentioned it as a fix. Do you have any opinion on how you'd prefer
> to handle this? Please share.

As I told you, it is not a fix and provide arguments why.


Best regards,
Krzysztof

Re: [PATCH 2/4] arm64: dts: qcom: sc7280: Add dma-coherent property into venus node

[Vishnu Reddy]

On 8/14/2026 3:56 PM, Krzysztof Kozlowski wrote:
> On 14/08/2026 12:24, Vishnu Reddy wrote:
>> On 8/14/2026 3:26 PM, Krzysztof Kozlowski wrote:
>>> On 14/08/2026 11:49, Vishnu Reddy wrote:
>>>> On 8/14/2026 12:01 PM, Krzysztof Kozlowski wrote:
>>>>> On 14/08/2026 07:29, Vishnu Reddy wrote:
>>>>>> On 8/13/2026 2:49 PM, Krzysztof Kozlowski wrote:
>>>>>>> On Sat, Aug 01, 2026 at 01:07:28PM +0530, Vishnu Reddy wrote:
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Fixes: 37613aee2179 ("arm64: dts: qcom: sc7280: Add venus DT node")
>>>>>>> Really does not look like a fix. How skipping a cache sync can fix
>>>>>>> anything exactly?
>>>>>> dma-coherent tells the kernel that this device DMA path is hardware-coherent,
>>>>>> so the SMMU maps its buffers as cacheable. That attribute is what causes the
>>>>>> coherent interconnect to snoop CPU cache lines on every VPU transaction, so
>>>>>> hardware keeps CPU caches and VPU-visible memory in sync — which is why the
>>>>>> dma-coherent property lets us skip the unnecessary cache clean/invalidate.
>>>>> You just repeated what I wrote. What for?
>>>>>
>>>>>> If a device doesn't support I/O coherence, its buffers would instead be mapped
>>>>>> non-cacheable, no snooping would occur, and the driver would need explicit
>>>>>> dma_sync_*() calls at each transition. Venus on SC7280 does support I/O
>>>>>> coherence, so dma-coherent describes that existing hardware capability to
>>>>>> the DMA subsystem.
>>>>> How does this anyhow explain your commit msg? Are you saying driver is
>>>>> buggy that it misses sync calls?
>>>> No, driver is not buggy here. dma-coherent flag is missed in the dt node.
>>> Again, no... or explain why. Missing dma-coherent is not a fix, but
>>> rather optimisation, but you claimed it is a fix. Explain why.
>> Is the dma-coherent flag only for skipping cache sync?
>> I might be repeating here — it enables the hardware level snoop between CPU
>> caches and DMA memory. Without dma-coherent, the CPU cache and the memory
>> which VPU accesses aren't in sync at the hardware level, which is what
> They are in sync, because driver explicitly MUST sync it.

No, currently driver is not calling the dma_sync*() explicitly.
It won't be in sync. That's why dma-coherent flag added to keep the
CPU cache and DMA memory in sync.
Will you suggest to sync from the driver explicitly?

If we call dma_sync*() in driver, will you recommend to add the
dma-coherent flag or not in the dt node?

> You cannot have uncoherent accesses without proper DMA cache syncing
> operations.
>
>> caused the corruption. So dma-coherent is the proper fix here, and that's
>> why I've mentioned it as a fix. Do you have any opinion on how you'd prefer
>> to handle this? Please share.
> As I told you, it is not a fix and provide arguments why.
>
>
> Best regards,
> Krzysztof
>

Re: [PATCH 1/4] dt-bindings: media: qcom,sc7280-venus: Add dma-coherent property

[Rob Herring]

On Fri, Aug 14, 2026 at 10:58:47AM +0530, Vishnu Reddy wrote:
> 
> On 8/11/2026 7:21 PM, Rob Herring wrote:
> > On Sat, Aug 01, 2026 at 01:07:27PM +0530, Vishnu Reddy wrote:
> >> 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.
> > The only side effect of 'dma-coherent' not being present should be doing 
> > unnecessary cache flushes. It should still work. Maybe you are missing 
> > some DMA API sync functions?
> 
> dma-coherent tells the kernel that this device DMA path is hardware-coherent,
> so the SMMU maps its buffers as cacheable. That attribute is what causes the
> coherent interconnect to snoop CPU cache lines on every VPU transaction, so
> hardware keeps CPU caches and VPU visible memory in sync — which is why the
> dma-coherent property lets us skip the unnecessary cache clean/invalidate.
> 
> If a device doesn't support I/O coherence, its buffers would instead be mapped
> non-cacheable, no snooping would occur, and the driver would need explicit
> dma_sync_*() calls at each transition.

The driver should have dma_sync_*() calls regardless. Even if cache 
flush/invalidate are not needed, IIRC the calls still provide barriers 
which may be needed.

Rob