Devicetree
 help / color / mirror / Atom feed
From: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Bryan O'Donoghue <bod@kernel.org>,
	Vikash Garodia <vikash.garodia@oss.qualcomm.com>,
	Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Stanimir Varbanov <stanimir.varbanov@linaro.org>,
	Mansur Alisha Shaik <mansur@codeaurora.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Abhinav Kumar <abhinav.kumar@linux.dev>,
	Hans Verkuil <hverkuil@kernel.org>,
	Stefan Schmidt <stefan.schmidt@linaro.org>,
	Hans Verkuil <hverkuil+cisco@kernel.org>,
	linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH 2/4] arm64: dts: qcom: sc7280: Add dma-coherent property into venus node
Date: Fri, 14 Aug 2026 10:59:32 +0530	[thread overview]
Message-ID: <4b34e718-0878-25cc-a5bd-0d8858df5133@oss.qualcomm.com> (raw)
In-Reply-To: <20260813-frisky-augmented-crow-fd5d3d@quoll>


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

  reply	other threads:[~2026-08-14  5:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <VEKY5BOnE_id6Ffw6u5r3P27fJtoDL7JS18ztQULo44427A70oT4o5SEHbD5wM4jJDH1CreNcmSnx_zfLLVi-w==@protonmail.internalid>
2026-08-01  7:37 ` [PATCH 0/4] media: iris: Fix DMA coherency, power-off ordering, and frame interval issues Vishnu Reddy
2026-08-01  7:37   ` [PATCH 1/4] dt-bindings: media: qcom,sc7280-venus: Add dma-coherent property Vishnu Reddy
2026-08-01  7:46     ` sashiko-bot
2026-08-11 13:51     ` Rob Herring
2026-08-14  5:28       ` Vishnu Reddy
2026-08-13  9:19     ` Krzysztof Kozlowski
2026-08-01  7:37   ` [PATCH 2/4] arm64: dts: qcom: sc7280: Add dma-coherent property into venus node Vishnu Reddy
2026-08-06 18:46     ` Deepa Guthyappa Madivalara
2026-08-13  9:19     ` Krzysztof Kozlowski
2026-08-14  5:29       ` Vishnu Reddy [this message]
2026-08-14  6:31         ` Krzysztof Kozlowski
2026-08-01  7:37   ` [PATCH 3/4] media: iris: Fix power-off ordering to disable power domain after clocks Vishnu Reddy
2026-08-01  7:51     ` sashiko-bot
2026-08-01  7:37   ` [PATCH 4/4] media: iris: Fix frame interval enumeration for non-divisor framerates Vishnu Reddy
2026-08-05  4:41   ` [PATCH 0/4] media: iris: Fix DMA coherency, power-off ordering, and frame interval issues Bryan O'Donoghue

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4b34e718-0878-25cc-a5bd-0d8858df5133@oss.qualcomm.com \
    --to=busanna.reddy@oss.qualcomm.com \
    --cc=abhinav.kumar@linux.dev \
    --cc=andersson@kernel.org \
    --cc=bod@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dikshita.agarwal@oss.qualcomm.com \
    --cc=hverkuil+cisco@kernel.org \
    --cc=hverkuil@kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mansur@codeaurora.org \
    --cc=mchehab@kernel.org \
    --cc=robh@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=stanimir.varbanov@linaro.org \
    --cc=stefan.schmidt@linaro.org \
    --cc=vikash.garodia@oss.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox