From: Vikash Garodia <quic_vgarodia@quicinc.com>
To: Dikshita Agarwal <quic_dikshita@quicinc.com>,
Abhinav Kumar <abhinav.kumar@linux.dev>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>
Cc: <linux-media@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Vikash Garodia <quic_vgarodia@quicinc.com>
Subject: [PATCH v3 1/5] media: dt-bindings: add non-pixel property in iris schema
Date: Fri, 27 Jun 2025 21:18:07 +0530 [thread overview]
Message-ID: <20250627-video_cb-v3-1-51e18c0ffbce@quicinc.com> (raw)
In-Reply-To: <20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com>
Existing definition limits the IOVA to an addressable range of 4GiB, and
even within that range, some of the space is used by IO registers,
thereby limiting the available IOVA to even lesser. Video hardware is
designed to emit different stream-ID for pixel and non-pixel buffers,
thereby introduce a non-pixel sub node to handle non-pixel stream-ID.
With this, both iris and non-pixel device can have IOVA range of 0-4GiB
individually. Certain video usecases like higher video concurrency needs
IOVA higher than 4GiB.
Add reference to the reserve-memory schema, which defines reserved IOVA
regions that are *excluded* from addressable range. Video hardware
generates different stream IDs based on the predefined range of IOVA
addresses. Thereby IOVA addresses for firmware and data buffers need to
be non overlapping. For ex. 0x0-0x25800000 address range is reserved for
firmware stream-ID, while non-pixel (bitstream) stream-ID can be
generated by hardware only when bitstream buffers IOVA address is from
0x25800000-0xe0000000.
Non-pixel stream-ID can now be part of the new sub-node, hence iommus in
iris node can have either 1 entry for pixel stream-id or 2 entries for
pixel and non-pixel stream-ids.
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
---
.../bindings/media/qcom,sm8550-iris.yaml | 40 ++++++++++++++++++++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
index c79bf2101812d83b99704f38b7348a9f728dff44..4dda2c9ca1293baa7aee3b9ee10aff38d280fe05 100644
--- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
@@ -65,10 +65,31 @@ properties:
- const: core
iommus:
+ minItems: 1
maxItems: 2
dma-coherent: true
+ non-pixel:
+ type: object
+ additionalProperties: false
+
+ description:
+ Non pixel context bank is needed when video hardware have distinct iommus
+ for non pixel buffers. Non pixel buffers are mainly compressed and
+ internal buffers.
+
+ properties:
+ iommus:
+ maxItems: 1
+
+ memory-region:
+ maxItems: 1
+
+ required:
+ - iommus
+ - memory-region
+
operating-points-v2: true
opp-table:
@@ -86,6 +107,7 @@ required:
allOf:
- $ref: qcom,venus-common.yaml#
+ - $ref: /schemas/reserved-memory/reserved-memory.yaml
- if:
properties:
compatible:
@@ -117,6 +139,16 @@ examples:
#include <dt-bindings/power/qcom-rpmpd.h>
#include <dt-bindings/power/qcom,rpmhpd.h>
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ iris_resv: reservation-iris {
+ iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>,
+ <&iris_non_pixel 0x0 0xe0000000 0x0 0x20000000>;
+ };
+ };
+
video-codec@aa00000 {
compatible = "qcom,sm8550-iris";
reg = <0x0aa00000 0xf0000>;
@@ -144,12 +176,16 @@ examples:
resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
reset-names = "bus";
- iommus = <&apps_smmu 0x1940 0x0000>,
- <&apps_smmu 0x1947 0x0000>;
+ iommus = <&apps_smmu 0x1947 0x0000>;
dma-coherent;
operating-points-v2 = <&iris_opp_table>;
+ iris_non_pixel: non-pixel {
+ iommus = <&apps_smmu 0x1940 0x0000>;
+ memory-region = <&iris_resv>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
next prev parent reply other threads:[~2025-06-27 15:48 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-27 15:48 [PATCH v3 0/5] Introduce "non-pixel" sub node within iris video node Vikash Garodia
2025-06-27 15:48 ` Vikash Garodia [this message]
2025-06-27 16:31 ` [PATCH v3 1/5] media: dt-bindings: add non-pixel property in iris schema Bryan O'Donoghue
2025-06-27 17:16 ` Vikash Garodia
2025-06-30 15:48 ` neil.armstrong
2025-06-30 15:56 ` Neil Armstrong
2025-07-02 11:13 ` Krzysztof Kozlowski
2025-07-02 11:32 ` Vikash Garodia
2025-07-02 11:46 ` Krzysztof Kozlowski
2025-07-02 13:11 ` Konrad Dybcio
2025-07-02 13:59 ` Krzysztof Kozlowski
2025-07-02 16:36 ` Vikash Garodia
2025-07-02 20:16 ` Krzysztof Kozlowski
2025-07-03 10:11 ` Konrad Dybcio
2025-07-03 7:29 ` Krzysztof Kozlowski
2025-07-02 11:23 ` Krzysztof Kozlowski
2025-07-02 11:45 ` Vikash Garodia
2025-07-02 11:47 ` Krzysztof Kozlowski
2025-07-02 11:55 ` Vikash Garodia
2025-07-02 11:58 ` Krzysztof Kozlowski
2025-07-02 12:08 ` Vikash Garodia
2025-07-02 12:11 ` Krzysztof Kozlowski
2025-06-27 15:48 ` [PATCH v3 2/5] media: iris: register and configure non-pixel node as platform device Vikash Garodia
2025-06-27 17:01 ` Bryan O'Donoghue
2025-07-02 11:04 ` Krzysztof Kozlowski
2025-07-02 11:39 ` Vikash Garodia
2025-07-02 12:45 ` Konrad Dybcio
2025-06-27 15:48 ` [PATCH v3 3/5] media: iris: use np_dev as preferred DMA device in HFI queue management Vikash Garodia
2025-06-27 17:03 ` Bryan O'Donoghue
2025-06-27 15:48 ` [PATCH v3 4/5] media: iris: select appropriate DMA device for internal buffers Vikash Garodia
2025-06-27 17:07 ` Bryan O'Donoghue
2025-06-27 15:48 ` [PATCH v3 5/5] media: iris: configure DMA device for vb2 queue on OUTPUT plane Vikash Garodia
2025-06-27 17:08 ` Bryan O'Donoghue
2025-06-30 7:58 ` Vikash Garodia
2025-07-01 12:04 ` Konrad Dybcio
2025-06-27 16:30 ` [PATCH v3 0/5] Introduce "non-pixel" sub node within iris video node Bryan O'Donoghue
2025-06-27 17:00 ` Vikash Garodia
2025-07-02 11:05 ` Krzysztof Kozlowski
2025-06-30 15:55 ` neil.armstrong
2025-06-30 18:04 ` neil.armstrong
2025-07-01 8:42 ` Konrad Dybcio
2025-07-01 10:23 ` Vikash Garodia
2025-07-01 13:19 ` Neil Armstrong
2025-07-01 16:11 ` Vikash Garodia
2025-07-02 7:59 ` Neil Armstrong
2025-07-02 11:06 ` Krzysztof Kozlowski
2025-07-02 11:18 ` Krzysztof Kozlowski
2025-07-02 11:37 ` Vikash Garodia
2025-07-02 11:52 ` Krzysztof Kozlowski
2025-07-02 11:54 ` Krzysztof Kozlowski
2025-07-02 12:01 ` Vikash Garodia
2025-07-02 12:05 ` Krzysztof Kozlowski
2025-07-02 12:57 ` Vikash Garodia
2025-07-02 12:06 ` Bryan O'Donoghue
2025-07-02 22:26 ` Dmitry Baryshkov
2025-07-03 7:27 ` Krzysztof Kozlowski
2025-07-03 12:38 ` Konrad Dybcio
2025-07-03 12:54 ` Krzysztof Kozlowski
2025-07-03 15:28 ` Konrad Dybcio
2025-07-03 20:28 ` Bryan O'Donoghue
2025-07-03 21:23 ` Dmitry Baryshkov
2025-07-04 8:23 ` Bryan O'Donoghue
2025-07-04 10:28 ` Konrad Dybcio
2025-07-04 16:45 ` Dmitry Baryshkov
2025-07-04 22:44 ` Bryan O'Donoghue
2025-07-10 18:18 ` Prakash Gupta
2025-07-15 12:15 ` Konrad Dybcio
2025-07-04 19:15 ` Vikash Garodia
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=20250627-video_cb-v3-1-51e18c0ffbce@quicinc.com \
--to=quic_vgarodia@quicinc.com \
--cc=abhinav.kumar@linux.dev \
--cc=bryan.odonoghue@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=quic_dikshita@quicinc.com \
--cc=robh@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).