* [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-22 13:41 [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
@ 2026-07-22 13:41 ` Vikash Garodia
2026-07-22 22:03 ` Bryan O'Donoghue
2026-07-24 5:59 ` Krzysztof Kozlowski
2026-07-22 13:41 ` [PATCH v5 2/4] dt-bindings: media: qcom,qcm2290-venus: document shikra venus compatible Vikash Garodia
` (3 subsequent siblings)
4 siblings, 2 replies; 14+ messages in thread
From: Vikash Garodia @ 2026-07-22 13:41 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel,
Vikash Garodia
Update the memory-region property to support two regions:
1. Firmware-loaded codec carveout (existing)
2. IOMMU IOVA reservation region (new)
The IOMMU IOVA reservation region is required to restrict usage of
specific IOVA memory range. For example, VPU restricts usage of 600MB
for specific streams, which could otherwise lead to device crash. This
change allows platforms to define separate memory regions for codec
carveout and IOVA restrictions.
This schema update supports existing DTS having single memory-region,
thereby allowing gradual migration of DTS to support two memory region.
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
Documentation/devicetree/bindings/media/qcom,venus-common.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
index 59a3fde846d2196ab1e4588eb396012ba6860712..0be2f9119e78233928d23af86836ac294aa769ee 100644
--- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
@@ -37,7 +37,10 @@ properties:
maxItems: 20
memory-region:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: Firmware-loaded codec carveout
+ - description: IOMMU IOVA reservation region
power-domains:
minItems: 1
--
2.34.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-22 13:41 ` [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region Vikash Garodia
@ 2026-07-22 22:03 ` Bryan O'Donoghue
2026-07-23 9:06 ` Konrad Dybcio
2026-07-24 5:59 ` Krzysztof Kozlowski
1 sibling, 1 reply; 14+ messages in thread
From: Bryan O'Donoghue @ 2026-07-22 22:03 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel
On 22/07/2026 14:41, Vikash Garodia wrote:
> Update the memory-region property to support two regions:
> 1. Firmware-loaded codec carveout (existing)
> 2. IOMMU IOVA reservation region (new)
>
> The IOMMU IOVA reservation region is required to restrict usage of
> specific IOVA memory range. For example, VPU restricts usage of 600MB
> for specific streams, which could otherwise lead to device crash. This
> change allows platforms to define separate memory regions for codec
> carveout and IOVA restrictions.
> This schema update supports existing DTS having single memory-region,
> thereby allowing gradual migration of DTS to support two memory region.
>
> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
> ---
I'm not mega-happy with this pattern being used - I prefer the pixel
pixel_cb sub-node model you've proposed yourself.
OTOH you're the maintainer so its really up to you how you want to
arbitrate this - the 600MB constraint will work even if its not pretty
or the best thing (tm).
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-22 22:03 ` Bryan O'Donoghue
@ 2026-07-23 9:06 ` Konrad Dybcio
2026-07-23 10:44 ` Vikash Garodia
0 siblings, 1 reply; 14+ messages in thread
From: Konrad Dybcio @ 2026-07-23 9:06 UTC (permalink / raw)
To: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jorge Ramirez-Ortiz, Stanimir Varbanov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel
On 7/23/26 12:03 AM, Bryan O'Donoghue wrote:
> On 22/07/2026 14:41, Vikash Garodia wrote:
>> Update the memory-region property to support two regions:
>> 1. Firmware-loaded codec carveout (existing)
>> 2. IOMMU IOVA reservation region (new)
>>
>> The IOMMU IOVA reservation region is required to restrict usage of
>> specific IOVA memory range. For example, VPU restricts usage of 600MB
>> for specific streams, which could otherwise lead to device crash. This
>> change allows platforms to define separate memory regions for codec
>> carveout and IOVA restrictions.
>> This schema update supports existing DTS having single memory-region,
>> thereby allowing gradual migration of DTS to support two memory region.
>>
>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>> ---
>
> I'm not mega-happy with this pattern being used - I prefer the pixel pixel_cb sub-node model you've proposed yourself.
>
> OTOH you're the maintainer so its really up to you how you want to arbitrate this - the 600MB constraint will work even if its not pretty or the best thing (tm).
>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Doesn't this cause the same limitation that the initial patch
by Daniel (all HW contexts can't access 0-600MiB anymore)?
Konrad
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-23 9:06 ` Konrad Dybcio
@ 2026-07-23 10:44 ` Vikash Garodia
2026-07-29 12:21 ` Konrad Dybcio
0 siblings, 1 reply; 14+ messages in thread
From: Vikash Garodia @ 2026-07-23 10:44 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Dikshita Agarwal,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jorge Ramirez-Ortiz, Stanimir Varbanov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel
On 7/23/2026 2:36 PM, Konrad Dybcio wrote:
> On 7/23/26 12:03 AM, Bryan O'Donoghue wrote:
>> On 22/07/2026 14:41, Vikash Garodia wrote:
>>> Update the memory-region property to support two regions:
>>> 1. Firmware-loaded codec carveout (existing)
>>> 2. IOMMU IOVA reservation region (new)
>>>
>>> The IOMMU IOVA reservation region is required to restrict usage of
>>> specific IOVA memory range. For example, VPU restricts usage of 600MB
>>> for specific streams, which could otherwise lead to device crash. This
>>> change allows platforms to define separate memory regions for codec
>>> carveout and IOVA restrictions.
>>> This schema update supports existing DTS having single memory-region,
>>> thereby allowing gradual migration of DTS to support two memory region.
>>>
>>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>>> ---
>>
>> I'm not mega-happy with this pattern being used - I prefer the pixel pixel_cb sub-node model you've proposed yourself.
>>
>> OTOH you're the maintainer so its really up to you how you want to arbitrate this - the 600MB constraint will work even if its not pretty or the best thing (tm).
>>
>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>
> Doesn't this cause the same limitation that the initial patch
> by Daniel (all HW contexts can't access 0-600MiB anymore)?
Yes, it does, but for cases, like Shikra, which have single streams
(with SMRs), there is no additional benefit in going with sub nodes in
such case.
Regards,
Vikash
>
> Konrad
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-23 10:44 ` Vikash Garodia
@ 2026-07-29 12:21 ` Konrad Dybcio
2026-07-29 12:21 ` Konrad Dybcio
2026-07-30 8:50 ` Vikash Garodia
0 siblings, 2 replies; 14+ messages in thread
From: Konrad Dybcio @ 2026-07-29 12:21 UTC (permalink / raw)
To: Vikash Garodia, Bryan O'Donoghue, Dikshita Agarwal,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jorge Ramirez-Ortiz, Stanimir Varbanov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel
On 7/23/26 12:44 PM, Vikash Garodia wrote:
>
> On 7/23/2026 2:36 PM, Konrad Dybcio wrote:
>> On 7/23/26 12:03 AM, Bryan O'Donoghue wrote:
>>> On 22/07/2026 14:41, Vikash Garodia wrote:
>>>> Update the memory-region property to support two regions:
>>>> 1. Firmware-loaded codec carveout (existing)
>>>> 2. IOMMU IOVA reservation region (new)
>>>>
>>>> The IOMMU IOVA reservation region is required to restrict usage of
>>>> specific IOVA memory range. For example, VPU restricts usage of 600MB
>>>> for specific streams, which could otherwise lead to device crash. This
>>>> change allows platforms to define separate memory regions for codec
>>>> carveout and IOVA restrictions.
>>>> This schema update supports existing DTS having single memory-region,
>>>> thereby allowing gradual migration of DTS to support two memory region.
>>>>
>>>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>>>> ---
>>>
>>> I'm not mega-happy with this pattern being used - I prefer the pixel pixel_cb sub-node model you've proposed yourself.
>>>
>>> OTOH you're the maintainer so its really up to you how you want to arbitrate this - the 600MB constraint will work even if its not pretty or the best thing (tm).
>>>
>>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>
>> Doesn't this cause the same limitation that the initial patch
>> by Daniel (all HW contexts can't access 0-600MiB anymore)?
>
> Yes, it does, but for cases, like Shikra, which have single streams (with SMRs), there is no additional benefit in going with sub nodes in such case.
Please note that somewhere, I was under the impression all venus
impls suffer from that
Konrad
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-29 12:21 ` Konrad Dybcio
@ 2026-07-29 12:21 ` Konrad Dybcio
2026-07-30 8:50 ` Vikash Garodia
1 sibling, 0 replies; 14+ messages in thread
From: Konrad Dybcio @ 2026-07-29 12:21 UTC (permalink / raw)
To: Vikash Garodia, Bryan O'Donoghue, Dikshita Agarwal,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jorge Ramirez-Ortiz, Stanimir Varbanov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel
On 7/29/26 2:21 PM, Konrad Dybcio wrote:
> On 7/23/26 12:44 PM, Vikash Garodia wrote:
>>
>> On 7/23/2026 2:36 PM, Konrad Dybcio wrote:
>>> On 7/23/26 12:03 AM, Bryan O'Donoghue wrote:
>>>> On 22/07/2026 14:41, Vikash Garodia wrote:
>>>>> Update the memory-region property to support two regions:
>>>>> 1. Firmware-loaded codec carveout (existing)
>>>>> 2. IOMMU IOVA reservation region (new)
>>>>>
>>>>> The IOMMU IOVA reservation region is required to restrict usage of
>>>>> specific IOVA memory range. For example, VPU restricts usage of 600MB
>>>>> for specific streams, which could otherwise lead to device crash. This
>>>>> change allows platforms to define separate memory regions for codec
>>>>> carveout and IOVA restrictions.
>>>>> This schema update supports existing DTS having single memory-region,
>>>>> thereby allowing gradual migration of DTS to support two memory region.
>>>>>
>>>>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> I'm not mega-happy with this pattern being used - I prefer the pixel pixel_cb sub-node model you've proposed yourself.
>>>>
>>>> OTOH you're the maintainer so its really up to you how you want to arbitrate this - the 600MB constraint will work even if its not pretty or the best thing (tm).
>>>>
>>>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>>
>>> Doesn't this cause the same limitation that the initial patch
>>> by Daniel (all HW contexts can't access 0-600MiB anymore)?
>>
>> Yes, it does, but for cases, like Shikra, which have single streams (with SMRs), there is no additional benefit in going with sub nodes in such case.
>
> Please note that somewhere, I was under the impression all venus
> impls suffer from that
Or.. is that a difference of "linux uses iommu-map today" vs "doesnt"?
Konrad
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-29 12:21 ` Konrad Dybcio
2026-07-29 12:21 ` Konrad Dybcio
@ 2026-07-30 8:50 ` Vikash Garodia
1 sibling, 0 replies; 14+ messages in thread
From: Vikash Garodia @ 2026-07-30 8:50 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Dikshita Agarwal,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jorge Ramirez-Ortiz, Stanimir Varbanov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel
On 7/29/2026 5:51 PM, Konrad Dybcio wrote:
> On 7/23/26 12:44 PM, Vikash Garodia wrote:
>>
>> On 7/23/2026 2:36 PM, Konrad Dybcio wrote:
>>> On 7/23/26 12:03 AM, Bryan O'Donoghue wrote:
>>>> On 22/07/2026 14:41, Vikash Garodia wrote:
>>>>> Update the memory-region property to support two regions:
>>>>> 1. Firmware-loaded codec carveout (existing)
>>>>> 2. IOMMU IOVA reservation region (new)
>>>>>
>>>>> The IOMMU IOVA reservation region is required to restrict usage of
>>>>> specific IOVA memory range. For example, VPU restricts usage of 600MB
>>>>> for specific streams, which could otherwise lead to device crash. This
>>>>> change allows platforms to define separate memory regions for codec
>>>>> carveout and IOVA restrictions.
>>>>> This schema update supports existing DTS having single memory-region,
>>>>> thereby allowing gradual migration of DTS to support two memory region.
>>>>>
>>>>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> I'm not mega-happy with this pattern being used - I prefer the pixel pixel_cb sub-node model you've proposed yourself.
>>>>
>>>> OTOH you're the maintainer so its really up to you how you want to arbitrate this - the 600MB constraint will work even if its not pretty or the best thing (tm).
>>>>
>>>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>>
>>> Doesn't this cause the same limitation that the initial patch
>>> by Daniel (all HW contexts can't access 0-600MiB anymore)?
>>
>> Yes, it does, but for cases, like Shikra, which have single streams (with SMRs), there is no additional benefit in going with sub nodes in such case.
>
> Please note that somewhere, I was under the impression all venus
> impls suffer from that
Yes, all of venus/iris, including Shikra, have this limitation. I was
trying to convey that for single stream case, like that of Shikra, we
can specify the restrictive IOVA range in the parent iris node itself
instead of introducing a sub node and put the same restriction there.
Regards,
Vikash
>
> Konrad
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-22 13:41 ` [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region Vikash Garodia
2026-07-22 22:03 ` Bryan O'Donoghue
@ 2026-07-24 5:59 ` Krzysztof Kozlowski
1 sibling, 0 replies; 14+ messages in thread
From: Krzysztof Kozlowski @ 2026-07-24 5:59 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-media, devicetree,
linux-kernel
On Wed, Jul 22, 2026 at 07:11:18PM +0530, Vikash Garodia wrote:
> Update the memory-region property to support two regions:
> 1. Firmware-loaded codec carveout (existing)
> 2. IOMMU IOVA reservation region (new)
>
> The IOMMU IOVA reservation region is required to restrict usage of
> specific IOVA memory range. For example, VPU restricts usage of 600MB
> for specific streams, which could otherwise lead to device crash. This
> change allows platforms to define separate memory regions for codec
> carveout and IOVA restrictions.
> This schema update supports existing DTS having single memory-region,
> thereby allowing gradual migration of DTS to support two memory region.
>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/media/qcom,venus-common.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH v5 2/4] dt-bindings: media: qcom,qcm2290-venus: document shikra venus compatible
2026-07-22 13:41 [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
2026-07-22 13:41 ` [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region Vikash Garodia
@ 2026-07-22 13:41 ` Vikash Garodia
2026-07-24 6:03 ` Krzysztof Kozlowski
2026-07-22 13:41 ` [PATCH v5 3/4] arm64: dts: qcom: shikra: Add Iris video codec node Vikash Garodia
` (2 subsequent siblings)
4 siblings, 1 reply; 14+ messages in thread
From: Vikash Garodia @ 2026-07-22 13:41 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel,
Vikash Garodia, Vishnu Reddy
Document the venus video accelerator used on shikra platforms by adding
the qcom,shikra-venus compatible.
Although QCM2290 and shikra share the same video hardware and overall
integration, their SMMU programming differs. QCM2290 exposes separate
stream IDs for the video hardware and the Xtensa path, requiring two
explicit IOMMU entries, whereas shikra uses a masked SMR to collapse
equivalent stream IDs into a single mapping. Due to QCM2290's SID layout
and Xtensa isolation requirements, such SMR masking is not applicable on
QCM2290 platforms.
Since shikra uses the same video hardware as QCM2290 and shares the same
programming model and capabilities, it is added as a fallback compatible
to qcom,qcm2290-venus, with conditional handling to allow either one or
two IOMMU entries.
Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
.../bindings/media/qcom,qcm2290-venus.yaml | 26 ++++++++++++++++------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
index 5977e7d0a71b4fb5681f1c2094439c251366f01f..b27899ebf164229ceff1ca5cda50ee30d875e953 100644
--- a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
@@ -13,14 +13,13 @@ description:
The Venus AR50_LITE IP is a video encode and decode accelerator present
on Qualcomm platforms.
-allOf:
- - $ref: qcom,venus-common.yaml#
-
properties:
compatible:
oneOf:
- items:
- - const: qcom,sm6115-venus
+ - enum:
+ - qcom,shikra-venus
+ - qcom,sm6115-venus
- const: qcom,qcm2290-venus
- const: qcom,qcm2290-venus
@@ -45,9 +44,6 @@ properties:
- const: vcodec0_core
- const: vcodec0_bus
- iommus:
- maxItems: 2
-
interconnects:
maxItems: 2
@@ -65,6 +61,22 @@ required:
- power-domain-names
- iommus
+allOf:
+ - $ref: qcom,venus-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,shikra-venus
+ then:
+ properties:
+ iommus:
+ maxItems: 1
+ else:
+ properties:
+ iommus:
+ maxItems: 2
+
unevaluatedProperties: false
examples:
--
2.34.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH v5 2/4] dt-bindings: media: qcom,qcm2290-venus: document shikra venus compatible
2026-07-22 13:41 ` [PATCH v5 2/4] dt-bindings: media: qcom,qcm2290-venus: document shikra venus compatible Vikash Garodia
@ 2026-07-24 6:03 ` Krzysztof Kozlowski
0 siblings, 0 replies; 14+ messages in thread
From: Krzysztof Kozlowski @ 2026-07-24 6:03 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-media, devicetree,
linux-kernel, Vishnu Reddy
On Wed, Jul 22, 2026 at 07:11:19PM +0530, Vikash Garodia wrote:
> Document the venus video accelerator used on shikra platforms by adding
> the qcom,shikra-venus compatible.
>
> Although QCM2290 and shikra share the same video hardware and overall
> integration, their SMMU programming differs. QCM2290 exposes separate
> stream IDs for the video hardware and the Xtensa path, requiring two
> explicit IOMMU entries, whereas shikra uses a masked SMR to collapse
> equivalent stream IDs into a single mapping. Due to QCM2290's SID layout
> and Xtensa isolation requirements, such SMR masking is not applicable on
> QCM2290 platforms.
> Since shikra uses the same video hardware as QCM2290 and shares the same
> programming model and capabilities, it is added as a fallback compatible
> to qcom,qcm2290-venus, with conditional handling to allow either one or
> two IOMMU entries.
>
> Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,qcm2290-venus.yaml | 26 ++++++++++++++++------
> 1 file changed, 19 insertions(+), 7 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH v5 3/4] arm64: dts: qcom: shikra: Add Iris video codec node
2026-07-22 13:41 [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
2026-07-22 13:41 ` [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region Vikash Garodia
2026-07-22 13:41 ` [PATCH v5 2/4] dt-bindings: media: qcom,qcm2290-venus: document shikra venus compatible Vikash Garodia
@ 2026-07-22 13:41 ` Vikash Garodia
2026-07-22 13:41 ` [PATCH v5 4/4] arm64: dts: qcom: shikra-evk: Enable Iris core Vikash Garodia
2026-09-17 10:39 ` [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
4 siblings, 0 replies; 14+ messages in thread
From: Vikash Garodia @ 2026-07-22 13:41 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel,
Vikash Garodia, Konrad Dybcio, Dmitry Baryshkov, Vishnu Reddy
Add the Iris video codec device tree node for the Shikra platform.
Shikra reuses the QCM2290-class video hardware and programming model.
The video node is added to describe the Iris based video decoder
encoder block, allowing the media driver to probe and initialize
the hardware.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra.dtsi | 71 ++++++++++++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
index 2a131ae601a7040142da16e39dbe2f8563ef43ee..8449af599cfc501bf17904c7533b0796948f8fb3 100644
--- a/arch/arm64/boot/dts/qcom/shikra.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -314,6 +314,16 @@ lmcu_dtb_mem: lmcu-dtb@b4702000 {
reg = <0x0 0xb4702000 0x0 0x40000>;
no-map;
};
+
+ /*
+ * The Iris VPU reserves IOVA below 0x25800000 (600MB),
+ * DMA into that range triggers unhandled SMMU faults and
+ * spontaneous reboots, so reserve it to keep IOMMU
+ * allocation above this boundary.
+ */
+ iris_iova: iris-iova {
+ iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
+ };
};
soc: soc@0 {
@@ -655,6 +665,67 @@ gpucc: clock-controller@5990000 {
#power-domain-cells = <1>;
};
+ iris: video-codec@5a00000 {
+ compatible = "qcom,shikra-venus", "qcom,qcm2290-venus";
+ reg = <0x0 0x05a00000 0x0 0x200000>;
+ interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH 0>;
+
+ power-domains = <&gcc GCC_VENUS_GDSC>,
+ <&gcc GCC_VCODEC0_GDSC>,
+ <&rpmpd QCM2290_VDDCX>;
+ power-domain-names = "venus",
+ "vcodec0",
+ "cx";
+ operating-points-v2 = <&venus_opp_table>;
+
+ clocks = <&gcc GCC_VIDEO_VENUS_CTL_CLK>,
+ <&gcc GCC_VIDEO_AHB_CLK>,
+ <&gcc GCC_VENUS_CTL_AXI_CLK>,
+ <&gcc GCC_VIDEO_THROTTLE_CORE_CLK>,
+ <&gcc GCC_VIDEO_VCODEC0_SYS_CLK>,
+ <&gcc GCC_VCODEC0_AXI_CLK>;
+ clock-names = "core",
+ "iface",
+ "bus",
+ "throttle",
+ "vcodec0_core",
+ "vcodec0_bus";
+
+ memory-region = <&video_mem>, <&iris_iova>;
+ interconnects = <&mmnrt_virt MASTER_VIDEO_P0 RPM_ALWAYS_TAG
+ &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>,
+ <&mem_noc MASTER_AMPSS_M0 RPM_ACTIVE_TAG
+ &config_noc SLAVE_VENUS_CFG RPM_ACTIVE_TAG>;
+ interconnect-names = "video-mem",
+ "cpu-cfg";
+
+ iommus = <&apps_smmu 0x780 0x20>;
+
+ venus_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-133333333 {
+ opp-hz = /bits/ 64 <133333333>;
+ required-opps = <&rpmpd_opp_low_svs>;
+ };
+
+ opp-240000000 {
+ opp-hz = /bits/ 64 <240000000>;
+ required-opps = <&rpmpd_opp_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmpd_opp_svs_plus>;
+ };
+
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ required-opps = <&rpmpd_opp_nom>;
+ };
+ };
+ };
+
dispcc: clock-controller@5f00000 {
compatible = "qcom,shikra-dispcc", "qcom,qcm2290-dispcc";
reg = <0x0 0x05f00000 0x0 0x20000>;
--
2.34.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH v5 4/4] arm64: dts: qcom: shikra-evk: Enable Iris core
2026-07-22 13:41 [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
` (2 preceding siblings ...)
2026-07-22 13:41 ` [PATCH v5 3/4] arm64: dts: qcom: shikra: Add Iris video codec node Vikash Garodia
@ 2026-07-22 13:41 ` Vikash Garodia
2026-09-17 10:39 ` [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
4 siblings, 0 replies; 14+ messages in thread
From: Vikash Garodia @ 2026-07-22 13:41 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel,
Vikash Garodia, Dmitry Baryshkov, Vishnu Reddy
Enable video en/decoder on the Shikra EVK board.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra-evk.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra-evk.dtsi b/arch/arm64/boot/dts/qcom/shikra-evk.dtsi
index 6eb4184f76422d57766ba34647010c690646fdab..696df7c9a7e0f7c86955066e76df3d8fcb8bad1f 100644
--- a/arch/arm64/boot/dts/qcom/shikra-evk.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra-evk.dtsi
@@ -3,6 +3,12 @@
* Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
*/
+&iris {
+ firmware-name = "qcom/vpu/ar50lt_p1_gen2_s6.mbn";
+
+ status = "okay";
+};
+
&qupv3_0 {
firmware-name = "qcom/shikra/qupv3fw.elf";
--
2.34.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra
2026-07-22 13:41 [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
` (3 preceding siblings ...)
2026-07-22 13:41 ` [PATCH v5 4/4] arm64: dts: qcom: shikra-evk: Enable Iris core Vikash Garodia
@ 2026-09-17 10:39 ` Vikash Garodia
4 siblings, 0 replies; 14+ messages in thread
From: Vikash Garodia @ 2026-09-17 10:39 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel,
Vishnu Reddy, Konrad Dybcio, Dmitry Baryshkov
On 7/22/2026 7:11 PM, Vikash Garodia wrote:
> Vikash Garodia (4):
> dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
> dt-bindings: media: qcom,qcm2290-venus: document shikra venus compatible
> arm64: dts: qcom: shikra: Add Iris video codec node
> arm64: dts: qcom: shikra-evk: Enable Iris core
>
> .../bindings/media/qcom,qcm2290-venus.yaml | 26 +++++---
> .../bindings/media/qcom,venus-common.yaml | 5 +-
> arch/arm64/boot/dts/qcom/shikra-evk.dtsi | 6 ++
> arch/arm64/boot/dts/qcom/shikra.dtsi | 71 ++++++++++++++++++++++
> 4 files changed, 100 insertions(+), 8 deletions(-)
Hello Bryan,
Could you please update when we can expect the binding patch to be applied ?
#1 patch in this series can be dropped once you apply the 600MB iova fix
in iris/venus driver.
Once the #2 binding is applied, i will reach out to DT maintainers to
apply the DTS.
Regards,
Vikash
^ permalink raw reply [flat|nested] 14+ messages in thread