* [PATCH v5 01/13] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema
2026-09-26 6:33 [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
@ 2026-09-26 6:34 ` Vikash Garodia
2026-10-08 6:46 ` Zhangfei Gao
2026-10-08 22:58 ` Bryan O'Donoghue
2026-09-26 6:34 ` [PATCH v5 02/13] dt-bindings: media: qcom,sm8550-iris: Add context bank subnodes Vikash Garodia
` (12 subsequent siblings)
13 siblings, 2 replies; 41+ messages in thread
From: Vikash Garodia @ 2026-09-26 6:34 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vikash Garodia,
Krzysztof Kozlowski
The VPU issues DMA through several SMMU streams, and the hardware does
not give every stream the same addressable range. The non-pixel stream
cannot address the low 600MB of IOVA space, while the pixel stream can
address the full range:
+-----------------------------------------------------------+
| non-pixel stream addressable range (600 MB - 3.5 GB) |
| 0x25800000 - 0xe0000000 |
+-----------------------------------------------------------+
| pixel stream addressable range (0 - 3.5 GB) |
| 0x00000000 - 0xe0000000 |
+-----------------------------------------------------------+
A single "iommus" property on the video-codec node puts every stream in
one IOMMU domain sharing one IOVA allocator, so nothing restricts a
non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
that boundary the hardware faults, which shows up as unhandled SMMU page
faults and spontaneous reboots:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Given that the address range restriction is for specific VPU stream, it
should be ideally be moved to that stream. To achieve the same, a subset
of streams is now represented as subnodes, so that each can be
associated with its respective addressable range. The design was
discussed and agreed by mainatiners here
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
In the past, this limitation was addressed with an iommu-map approach,
with the iris driver dynamically creating the devices. That approach was
later concluded to be a hack to avoid having subnodes, and was NAKed by
the iommu maintainers. It was discussed in detail here:
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
"iommu-ranges" on the subnode describes the *allowed* IOVA range that
stream is allowed to use, so the IOVA is allocated from the specified
range only. Define all the possible subnodes so as to describe all the
VPU hardware iommu interfaces, both secure as well as non secure.
address-cells, size-cells and dma-ranges declares the 1:1 DMA
translation into the parent.
The parent "iommus" is kept as an alternative via "oneOf", so platforms
that have not been converted to subnodes still validate. New platforms
should use the subnode form.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
.../bindings/media/qcom,sc7180-venus.yaml | 15 ----
.../bindings/media/qcom,venus-common.yaml | 97 ++++++++++++++++++++++
2 files changed, 97 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
index b21bed314848480b82153e49602f0b19e08e7335..bfd8b1ad473128c974bce84639cb0aff59d8c2cc 100644
--- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
@@ -91,21 +91,6 @@ properties:
deprecated: true
additionalProperties: false
- video-firmware:
- type: object
- additionalProperties: false
-
- description: |
- Firmware subnode is needed when the platform does not
- have TrustZone.
-
- properties:
- iommus:
- maxItems: 1
-
- required:
- - iommus
-
required:
- compatible
- power-domain-names
diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
index 59a3fde846d2196ab1e4588eb396012ba6860712..68d5e592a028c5eecde04ce72cd5ae6815ba5c82 100644
--- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
@@ -47,6 +47,93 @@ properties:
minItems: 1
maxItems: 4
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ dma-ranges:
+ maxItems: 1
+
+ non-pixel:
+ type: object
+ description:
+ Context bank for VPU non-pixel buffers, including compressed and internal buffers.
+ additionalProperties: false
+
+ properties:
+ iommus:
+ maxItems: 1
+ iommu-ranges:
+ maxItems: 1
+ required:
+ - iommus
+ - iommu-ranges
+
+ pixel:
+ type: object
+ description:
+ Context bank for VPU pixel buffers containing uncompressed video data.
+ additionalProperties: false
+
+ properties:
+ iommus:
+ maxItems: 1
+ required:
+ - iommus
+
+ video-firmware:
+ type: object
+ description:
+ Context bank for the VPU firmware processing domain.
+ additionalProperties: false
+
+ properties:
+ iommus:
+ maxItems: 1
+ required:
+ - iommus
+
+ secure-non-pixel:
+ type: object
+ description:
+ Context bank for VPU secure non-pixel buffers.
+ additionalProperties: false
+
+ properties:
+ iommus:
+ maxItems: 1
+ iommu-ranges:
+ maxItems: 1
+ required:
+ - iommus
+ - iommu-ranges
+
+ secure-pixel:
+ type: object
+ description:
+ Context bank for VPU secure pixel buffers containing uncompressed video data.
+ additionalProperties: false
+
+ properties:
+ iommus:
+ maxItems: 1
+ required:
+ - iommus
+
+ secure-bitstream:
+ type: object
+ description:
+ Context bank for VPU secure bitstream buffers containing compressed video data.
+ additionalProperties: false
+
+ properties:
+ iommus:
+ maxItems: 1
+ required:
+ - iommus
+
required:
- reg
- clocks
@@ -55,4 +142,14 @@ required:
- memory-region
- power-domains
+oneOf:
+ - required:
+ - iommus
+ - required:
+ - '#address-cells'
+ - '#size-cells'
+ - dma-ranges
+ - non-pixel
+ - pixel
+
additionalProperties: true
--
2.34.1
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [PATCH v5 01/13] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema
2026-09-26 6:34 ` [PATCH v5 01/13] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema Vikash Garodia
@ 2026-10-08 6:46 ` Zhangfei Gao
2026-10-08 9:34 ` Vikash Garodia
2026-10-08 22:58 ` Bryan O'Donoghue
1 sibling, 1 reply; 41+ messages in thread
From: Zhangfei Gao @ 2026-10-08 6:46 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa, linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Krzysztof Kozlowski
On Sat, Sep 26, 2026 at 2:38 PM Vikash Garodia
<vikash.garodia@oss.qualcomm.com> wrote:
>
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | pixel stream addressable range (0 - 3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
> A single "iommus" property on the video-codec node puts every stream in
> one IOMMU domain sharing one IOVA allocator, so nothing restricts a
> non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
> that boundary the hardware faults, which shows up as unhandled SMMU page
> faults and spontaneous reboots:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> Given that the address range restriction is for specific VPU stream, it
> should be ideally be moved to that stream. To achieve the same, a subset
> of streams is now represented as subnodes, so that each can be
> associated with its respective addressable range. The design was
> discussed and agreed by mainatiners here
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
>
> In the past, this limitation was addressed with an iommu-map approach,
> with the iris driver dynamically creating the devices. That approach was
> later concluded to be a hack to avoid having subnodes, and was NAKed by
> the iommu maintainers. It was discussed in detail here:
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
>
> "iommu-ranges" on the subnode describes the *allowed* IOVA range that
> stream is allowed to use, so the IOVA is allocated from the specified
> range only. Define all the possible subnodes so as to describe all the
> VPU hardware iommu interfaces, both secure as well as non secure.
>
> address-cells, size-cells and dma-ranges declares the 1:1 DMA
> translation into the parent.
>
> The parent "iommus" is kept as an alternative via "oneOf", so platforms
> that have not been converted to subnodes still validate. New platforms
> should use the subnode form.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,sc7180-venus.yaml | 15 ----
> .../bindings/media/qcom,venus-common.yaml | 97 ++++++++++++++++++++++
> 2 files changed, 97 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> index b21bed314848480b82153e49602f0b19e08e7335..bfd8b1ad473128c974bce84639cb0aff59d8c2cc 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> @@ -91,21 +91,6 @@ properties:
> deprecated: true
> additionalProperties: false
>
> - video-firmware:
> - type: object
> - additionalProperties: false
> -
> - description: |
> - Firmware subnode is needed when the platform does not
> - have TrustZone.
> -
> - properties:
> - iommus:
> - maxItems: 1
> -
> - required:
> - - iommus
> -
> required:
> - compatible
> - power-domain-names
> diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> index 59a3fde846d2196ab1e4588eb396012ba6860712..68d5e592a028c5eecde04ce72cd5ae6815ba5c82 100644
> --- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> @@ -47,6 +47,93 @@ properties:
> minItems: 1
> maxItems: 4
>
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 1
> +
> + dma-ranges:
> + maxItems: 1
> +
> + non-pixel:
> + type: object
> + description:
> + Context bank for VPU non-pixel buffers, including compressed and internal buffers.
> + additionalProperties: false
> +
> + properties:
> + iommus:
> + maxItems: 1
> + iommu-ranges:
> + maxItems: 1
> + required:
> + - iommus
> + - iommu-ranges
> +
> + pixel:
> + type: object
> + description:
> + Context bank for VPU pixel buffers containing uncompressed video data.
> + additionalProperties: false
> +
> + properties:
> + iommus:
> + maxItems: 1
> + required:
> + - iommus
> +
> + video-firmware:
> + type: object
> + description:
> + Context bank for the VPU firmware processing domain.
> + additionalProperties: false
> +
> + properties:
> + iommus:
> + maxItems: 1
> + required:
> + - iommus
> +
> + secure-non-pixel:
> + type: object
> + description:
> + Context bank for VPU secure non-pixel buffers.
> + additionalProperties: false
> +
> + properties:
> + iommus:
> + maxItems: 1
> + iommu-ranges:
> + maxItems: 1
> + required:
> + - iommus
> + - iommu-ranges
> +
> + secure-pixel:
> + type: object
> + description:
> + Context bank for VPU secure pixel buffers containing uncompressed video data.
> + additionalProperties: false
> +
> + properties:
> + iommus:
> + maxItems: 1
> + required:
> + - iommus
> +
> + secure-bitstream:
> + type: object
> + description:
> + Context bank for VPU secure bitstream buffers containing compressed video data.
> + additionalProperties: false
> +
> + properties:
> + iommus:
> + maxItems: 1
> + required:
> + - iommus
> +
> required:
> - reg
> - clocks
> @@ -55,4 +142,14 @@ required:
> - memory-region
> - power-domains
>
> +oneOf:
> + - required:
> + - iommus
> + - required:
> + - '#address-cells'
> + - '#size-cells'
> + - dma-ranges
> + - non-pixel
> + - pixel
> +
> additionalProperties: true
>
Got this warning:
arch/arm64/boot/dts/qcom/nord-rrd.dtb: non-pixel: iommu-ranges:
b'%\x80\x00\x00\xda`\x00\x00' is not of type 'object', 'integer',
'array', 'boolean', 'null'
arch/arm64/boot/dts/qcom/nord-ride-embedded.dtb: non-pixel:
iommu-ranges: b'%\x80\x00\x00\xda`\x00\x00' is not of type 'object',
'integer', 'array', 'boolean', 'null'
Need
--- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
@@ -67,7 +67,9 @@ properties:
minItems: 1
maxItems: 3
iommu-ranges:
- maxItems: 1
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 2
required:
- iommus
- iommu-ranges
@@ -106,7 +108,9 @@ properties:
iommus:
maxItems: 1
iommu-ranges:
- maxItems: 1
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 2
required:
- iommus
- iommu-ranges
Thanks
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH v5 01/13] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema
2026-10-08 6:46 ` Zhangfei Gao
@ 2026-10-08 9:34 ` Vikash Garodia
2026-10-08 12:02 ` Zhangfei Gao
0 siblings, 1 reply; 41+ messages in thread
From: Vikash Garodia @ 2026-10-08 9:34 UTC (permalink / raw)
To: Zhangfei Gao
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa, linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Krzysztof Kozlowski
On 10/8/2026 12:16 PM, Zhangfei Gao wrote:
> On Sat, Sep 26, 2026 at 2:38 PM Vikash Garodia
> <vikash.garodia@oss.qualcomm.com> wrote:
>>
>> The VPU issues DMA through several SMMU streams, and the hardware does
>> not give every stream the same addressable range. The non-pixel stream
>> cannot address the low 600MB of IOVA space, while the pixel stream can
>> address the full range:
>> +-----------------------------------------------------------+
>> | non-pixel stream addressable range (600 MB - 3.5 GB) |
>> | 0x25800000 - 0xe0000000 |
>> +-----------------------------------------------------------+
>> | pixel stream addressable range (0 - 3.5 GB) |
>> | 0x00000000 - 0xe0000000 |
>> +-----------------------------------------------------------+
>> A single "iommus" property on the video-codec node puts every stream in
>> one IOMMU domain sharing one IOVA allocator, so nothing restricts a
>> non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
>> that boundary the hardware faults, which shows up as unhandled SMMU page
>> faults and spontaneous reboots:
>> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>>
>> Given that the address range restriction is for specific VPU stream, it
>> should be ideally be moved to that stream. To achieve the same, a subset
>> of streams is now represented as subnodes, so that each can be
>> associated with its respective addressable range. The design was
>> discussed and agreed by mainatiners here
>> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
>>
>> In the past, this limitation was addressed with an iommu-map approach,
>> with the iris driver dynamically creating the devices. That approach was
>> later concluded to be a hack to avoid having subnodes, and was NAKed by
>> the iommu maintainers. It was discussed in detail here:
>> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
>>
>> "iommu-ranges" on the subnode describes the *allowed* IOVA range that
>> stream is allowed to use, so the IOVA is allocated from the specified
>> range only. Define all the possible subnodes so as to describe all the
>> VPU hardware iommu interfaces, both secure as well as non secure.
>>
>> address-cells, size-cells and dma-ranges declares the 1:1 DMA
>> translation into the parent.
>>
>> The parent "iommus" is kept as an alternative via "oneOf", so platforms
>> that have not been converted to subnodes still validate. New platforms
>> should use the subnode form.
>>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>> ---
>> .../bindings/media/qcom,sc7180-venus.yaml | 15 ----
>> .../bindings/media/qcom,venus-common.yaml | 97 ++++++++++++++++++++++
>> 2 files changed, 97 insertions(+), 15 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
>> index b21bed314848480b82153e49602f0b19e08e7335..bfd8b1ad473128c974bce84639cb0aff59d8c2cc 100644
>> --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
>> +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
>> @@ -91,21 +91,6 @@ properties:
>> deprecated: true
>> additionalProperties: false
>>
>> - video-firmware:
>> - type: object
>> - additionalProperties: false
>> -
>> - description: |
>> - Firmware subnode is needed when the platform does not
>> - have TrustZone.
>> -
>> - properties:
>> - iommus:
>> - maxItems: 1
>> -
>> - required:
>> - - iommus
>> -
>> required:
>> - compatible
>> - power-domain-names
>> diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
>> index 59a3fde846d2196ab1e4588eb396012ba6860712..68d5e592a028c5eecde04ce72cd5ae6815ba5c82 100644
>> --- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
>> +++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
>> @@ -47,6 +47,93 @@ properties:
>> minItems: 1
>> maxItems: 4
>>
>> + '#address-cells':
>> + const: 1
>> +
>> + '#size-cells':
>> + const: 1
>> +
>> + dma-ranges:
>> + maxItems: 1
>> +
>> + non-pixel:
>> + type: object
>> + description:
>> + Context bank for VPU non-pixel buffers, including compressed and internal buffers.
>> + additionalProperties: false
>> +
>> + properties:
>> + iommus:
>> + maxItems: 1
>> + iommu-ranges:
>> + maxItems: 1
>> + required:
>> + - iommus
>> + - iommu-ranges
>> +
>> + pixel:
>> + type: object
>> + description:
>> + Context bank for VPU pixel buffers containing uncompressed video data.
>> + additionalProperties: false
>> +
>> + properties:
>> + iommus:
>> + maxItems: 1
>> + required:
>> + - iommus
>> +
>> + video-firmware:
>> + type: object
>> + description:
>> + Context bank for the VPU firmware processing domain.
>> + additionalProperties: false
>> +
>> + properties:
>> + iommus:
>> + maxItems: 1
>> + required:
>> + - iommus
>> +
>> + secure-non-pixel:
>> + type: object
>> + description:
>> + Context bank for VPU secure non-pixel buffers.
>> + additionalProperties: false
>> +
>> + properties:
>> + iommus:
>> + maxItems: 1
>> + iommu-ranges:
>> + maxItems: 1
>> + required:
>> + - iommus
>> + - iommu-ranges
>> +
>> + secure-pixel:
>> + type: object
>> + description:
>> + Context bank for VPU secure pixel buffers containing uncompressed video data.
>> + additionalProperties: false
>> +
>> + properties:
>> + iommus:
>> + maxItems: 1
>> + required:
>> + - iommus
>> +
>> + secure-bitstream:
>> + type: object
>> + description:
>> + Context bank for VPU secure bitstream buffers containing compressed video data.
>> + additionalProperties: false
>> +
>> + properties:
>> + iommus:
>> + maxItems: 1
>> + required:
>> + - iommus
>> +
>> required:
>> - reg
>> - clocks
>> @@ -55,4 +142,14 @@ required:
>> - memory-region
>> - power-domains
>>
>> +oneOf:
>> + - required:
>> + - iommus
>> + - required:
>> + - '#address-cells'
>> + - '#size-cells'
>> + - dma-ranges
>> + - non-pixel
>> + - pixel
>> +
>> additionalProperties: true
>>
> Got this warning:
> arch/arm64/boot/dts/qcom/nord-rrd.dtb: non-pixel: iommu-ranges:
> b'%\x80\x00\x00\xda`\x00\x00' is not of type 'object', 'integer',
> 'array', 'boolean', 'null'
> arch/arm64/boot/dts/qcom/nord-ride-embedded.dtb: non-pixel:
> iommu-ranges: b'%\x80\x00\x00\xda`\x00\x00' is not of type 'object',
> 'integer', 'array', 'boolean', 'null'
>
You have not picked the latest dt schema. Please go through the cover
letter where a PR is mentioned, please pull that or validate against
latest schema.
Regards,
Vikash
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v5 01/13] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema
2026-10-08 9:34 ` Vikash Garodia
@ 2026-10-08 12:02 ` Zhangfei Gao
0 siblings, 0 replies; 41+ messages in thread
From: Zhangfei Gao @ 2026-10-08 12:02 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa, linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Krzysztof Kozlowski
On Thu, Oct 8, 2026 at 5:34 PM Vikash Garodia
<vikash.garodia@oss.qualcomm.com> wrote:
>
>
> On 10/8/2026 12:16 PM, Zhangfei Gao wrote:
> > On Sat, Sep 26, 2026 at 2:38 PM Vikash Garodia
> > <vikash.garodia@oss.qualcomm.com> wrote:
> >>
> >> The VPU issues DMA through several SMMU streams, and the hardware does
> >> not give every stream the same addressable range. The non-pixel stream
> >> cannot address the low 600MB of IOVA space, while the pixel stream can
> >> address the full range:
> >> +-----------------------------------------------------------+
> >> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> >> | 0x25800000 - 0xe0000000 |
> >> +-----------------------------------------------------------+
> >> | pixel stream addressable range (0 - 3.5 GB) |
> >> | 0x00000000 - 0xe0000000 |
> >> +-----------------------------------------------------------+
> >> A single "iommus" property on the video-codec node puts every stream in
> >> one IOMMU domain sharing one IOVA allocator, so nothing restricts a
> >> non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
> >> that boundary the hardware faults, which shows up as unhandled SMMU page
> >> faults and spontaneous reboots:
> >> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
> >>
> >> Given that the address range restriction is for specific VPU stream, it
> >> should be ideally be moved to that stream. To achieve the same, a subset
> >> of streams is now represented as subnodes, so that each can be
> >> associated with its respective addressable range. The design was
> >> discussed and agreed by mainatiners here
> >> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
> >>
> >> In the past, this limitation was addressed with an iommu-map approach,
> >> with the iris driver dynamically creating the devices. That approach was
> >> later concluded to be a hack to avoid having subnodes, and was NAKed by
> >> the iommu maintainers. It was discussed in detail here:
> >> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
> >>
> >> "iommu-ranges" on the subnode describes the *allowed* IOVA range that
> >> stream is allowed to use, so the IOVA is allocated from the specified
> >> range only. Define all the possible subnodes so as to describe all the
> >> VPU hardware iommu interfaces, both secure as well as non secure.
> >>
> >> address-cells, size-cells and dma-ranges declares the 1:1 DMA
> >> translation into the parent.
> >>
> >> The parent "iommus" is kept as an alternative via "oneOf", so platforms
> >> that have not been converted to subnodes still validate. New platforms
> >> should use the subnode form.
> >>
> >> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> >> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> >> ---
> >> .../bindings/media/qcom,sc7180-venus.yaml | 15 ----
> >> .../bindings/media/qcom,venus-common.yaml | 97 ++++++++++++++++++++++
> >> 2 files changed, 97 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> >> index b21bed314848480b82153e49602f0b19e08e7335..bfd8b1ad473128c974bce84639cb0aff59d8c2cc 100644
> >> --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> >> +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> >> @@ -91,21 +91,6 @@ properties:
> >> deprecated: true
> >> additionalProperties: false
> >>
> >> - video-firmware:
> >> - type: object
> >> - additionalProperties: false
> >> -
> >> - description: |
> >> - Firmware subnode is needed when the platform does not
> >> - have TrustZone.
> >> -
> >> - properties:
> >> - iommus:
> >> - maxItems: 1
> >> -
> >> - required:
> >> - - iommus
> >> -
> >> required:
> >> - compatible
> >> - power-domain-names
> >> diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> >> index 59a3fde846d2196ab1e4588eb396012ba6860712..68d5e592a028c5eecde04ce72cd5ae6815ba5c82 100644
> >> --- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> >> +++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> >> @@ -47,6 +47,93 @@ properties:
> >> minItems: 1
> >> maxItems: 4
> >>
> >> + '#address-cells':
> >> + const: 1
> >> +
> >> + '#size-cells':
> >> + const: 1
> >> +
> >> + dma-ranges:
> >> + maxItems: 1
> >> +
> >> + non-pixel:
> >> + type: object
> >> + description:
> >> + Context bank for VPU non-pixel buffers, including compressed and internal buffers.
> >> + additionalProperties: false
> >> +
> >> + properties:
> >> + iommus:
> >> + maxItems: 1
> >> + iommu-ranges:
> >> + maxItems: 1
> >> + required:
> >> + - iommus
> >> + - iommu-ranges
> >> +
> >> + pixel:
> >> + type: object
> >> + description:
> >> + Context bank for VPU pixel buffers containing uncompressed video data.
> >> + additionalProperties: false
> >> +
> >> + properties:
> >> + iommus:
> >> + maxItems: 1
> >> + required:
> >> + - iommus
> >> +
> >> + video-firmware:
> >> + type: object
> >> + description:
> >> + Context bank for the VPU firmware processing domain.
> >> + additionalProperties: false
> >> +
> >> + properties:
> >> + iommus:
> >> + maxItems: 1
> >> + required:
> >> + - iommus
> >> +
> >> + secure-non-pixel:
> >> + type: object
> >> + description:
> >> + Context bank for VPU secure non-pixel buffers.
> >> + additionalProperties: false
> >> +
> >> + properties:
> >> + iommus:
> >> + maxItems: 1
> >> + iommu-ranges:
> >> + maxItems: 1
> >> + required:
> >> + - iommus
> >> + - iommu-ranges
> >> +
> >> + secure-pixel:
> >> + type: object
> >> + description:
> >> + Context bank for VPU secure pixel buffers containing uncompressed video data.
> >> + additionalProperties: false
> >> +
> >> + properties:
> >> + iommus:
> >> + maxItems: 1
> >> + required:
> >> + - iommus
> >> +
> >> + secure-bitstream:
> >> + type: object
> >> + description:
> >> + Context bank for VPU secure bitstream buffers containing compressed video data.
> >> + additionalProperties: false
> >> +
> >> + properties:
> >> + iommus:
> >> + maxItems: 1
> >> + required:
> >> + - iommus
> >> +
> >> required:
> >> - reg
> >> - clocks
> >> @@ -55,4 +142,14 @@ required:
> >> - memory-region
> >> - power-domains
> >>
> >> +oneOf:
> >> + - required:
> >> + - iommus
> >> + - required:
> >> + - '#address-cells'
> >> + - '#size-cells'
> >> + - dma-ranges
> >> + - non-pixel
> >> + - pixel
> >> +
> >> additionalProperties: true
> >>
> > Got this warning:
> > arch/arm64/boot/dts/qcom/nord-rrd.dtb: non-pixel: iommu-ranges:
> > b'%\x80\x00\x00\xda`\x00\x00' is not of type 'object', 'integer',
> > 'array', 'boolean', 'null'
> > arch/arm64/boot/dts/qcom/nord-ride-embedded.dtb: non-pixel:
> > iommu-ranges: b'%\x80\x00\x00\xda`\x00\x00' is not of type 'object',
> > 'integer', 'array', 'boolean', 'null'
> >
>
> You have not picked the latest dt schema. Please go through the cover
> letter where a PR is mentioned, please pull that or validate against
> latest schema.
Yes, with the latest dt schema, the check passes, thanks.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v5 01/13] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema
2026-09-26 6:34 ` [PATCH v5 01/13] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema Vikash Garodia
2026-10-08 6:46 ` Zhangfei Gao
@ 2026-10-08 22:58 ` Bryan O'Donoghue
1 sibling, 0 replies; 41+ messages in thread
From: Bryan O'Donoghue @ 2026-10-08 22:58 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Krzysztof Kozlowski
On 26/09/2026 07:34, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | pixel stream addressable range (0 - 3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
> A single "iommus" property on the video-codec node puts every stream in
> one IOMMU domain sharing one IOVA allocator, so nothing restricts a
> non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
> that boundary the hardware faults, which shows up as unhandled SMMU page
> faults and spontaneous reboots:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> Given that the address range restriction is for specific VPU stream, it
> should be ideally be moved to that stream. To achieve the same, a subset
> of streams is now represented as subnodes, so that each can be
> associated with its respective addressable range. The design was
> discussed and agreed by mainatiners here
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
>
> In the past, this limitation was addressed with an iommu-map approach,
> with the iris driver dynamically creating the devices. That approach was
> later concluded to be a hack to avoid having subnodes, and was NAKed by
> the iommu maintainers. It was discussed in detail here:
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
>
> "iommu-ranges" on the subnode describes the *allowed* IOVA range that
> stream is allowed to use, so the IOVA is allocated from the specified
> range only. Define all the possible subnodes so as to describe all the
> VPU hardware iommu interfaces, both secure as well as non secure.
>
> address-cells, size-cells and dma-ranges declares the 1:1 DMA
> translation into the parent.
>
> The parent "iommus" is kept as an alternative via "oneOf", so platforms
> that have not been converted to subnodes still validate. New platforms
> should use the subnode form.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,sc7180-venus.yaml | 15 ----
> .../bindings/media/qcom,venus-common.yaml | 97 ++++++++++++++++++++++
> 2 files changed, 97 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> index b21bed314848480b82153e49602f0b19e08e7335..bfd8b1ad473128c974bce84639cb0aff59d8c2cc 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> @@ -91,21 +91,6 @@ properties:
> deprecated: true
> additionalProperties: false
>
> - video-firmware:
> - type: object
> - additionalProperties: false
> -
> - description: |
> - Firmware subnode is needed when the platform does not
> - have TrustZone.
> -
> - properties:
> - iommus:
> - maxItems: 1
> -
> - required:
> - - iommus
> -
> required:
> - compatible
> - power-domain-names
> diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> index 59a3fde846d2196ab1e4588eb396012ba6860712..68d5e592a028c5eecde04ce72cd5ae6815ba5c82 100644
> --- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> @@ -47,6 +47,93 @@ properties:
> minItems: 1
> maxItems: 4
>
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 1
> +
> + dma-ranges:
> + maxItems: 1
> +
> + non-pixel:
> + type: object
> + description:
> + Context bank for VPU non-pixel buffers, including compressed and internal buffers.
> + additionalProperties: false
> +
> + properties:
> + iommus:
> + maxItems: 1
> + iommu-ranges:
> + maxItems: 1
> + required:
> + - iommus
> + - iommu-ranges
> +
> + pixel:
> + type: object
> + description:
> + Context bank for VPU pixel buffers containing uncompressed video data.
> + additionalProperties: false
> +
> + properties:
> + iommus:
> + maxItems: 1
> + required:
> + - iommus
> +
> + video-firmware:
> + type: object
> + description:
> + Context bank for the VPU firmware processing domain.
> + additionalProperties: false
> +
> + properties:
> + iommus:
> + maxItems: 1
> + required:
> + - iommus
> +
> + secure-non-pixel:
> + type: object
> + description:
> + Context bank for VPU secure non-pixel buffers.
> + additionalProperties: false
> +
> + properties:
> + iommus:
> + maxItems: 1
> + iommu-ranges:
> + maxItems: 1
> + required:
> + - iommus
> + - iommu-ranges
> +
> + secure-pixel:
> + type: object
> + description:
> + Context bank for VPU secure pixel buffers containing uncompressed video data.
> + additionalProperties: false
> +
> + properties:
> + iommus:
> + maxItems: 1
> + required:
> + - iommus
> +
> + secure-bitstream:
> + type: object
> + description:
> + Context bank for VPU secure bitstream buffers containing compressed video data.
> + additionalProperties: false
> +
> + properties:
> + iommus:
> + maxItems: 1
> + required:
> + - iommus
> +
> required:
> - reg
> - clocks
> @@ -55,4 +142,14 @@ required:
> - memory-region
> - power-domains
>
> +oneOf:
> + - required:
> + - iommus
> + - required:
> + - '#address-cells'
> + - '#size-cells'
> + - dma-ranges
> + - non-pixel
> + - pixel
> +
> additionalProperties: true
>
> --
> 2.34.1
>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH v5 02/13] dt-bindings: media: qcom,sm8550-iris: Add context bank subnodes
2026-09-26 6:33 [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
2026-09-26 6:34 ` [PATCH v5 01/13] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema Vikash Garodia
@ 2026-09-26 6:34 ` Vikash Garodia
2026-10-08 22:58 ` Bryan O'Donoghue
2026-09-26 6:34 ` [PATCH v5 03/13] dt-bindings: media: qcom,sm8750-iris: " Vikash Garodia
` (11 subsequent siblings)
13 siblings, 1 reply; 41+ messages in thread
From: Vikash Garodia @ 2026-09-26 6:34 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vikash Garodia,
Krzysztof Kozlowski, Vishnu Reddy
The VPU issues DMA through several SMMU streams, and the hardware does
not give every stream the same addressable range. The non-pixel stream
cannot address the low 600MB of IOVA space, while the pixel stream can
address the full range:
+-----------------------------------------------------------+
| non-pixel stream addressable range (600 MB - 3.5 GB) |
| 0x25800000 - 0xe0000000 |
+-----------------------------------------------------------+
| pixel stream addressable range (0 - 3.5 GB) |
| 0x00000000 - 0xe0000000 |
+-----------------------------------------------------------+
A single "iommus" property on the video-codec node puts every stream in
one IOMMU domain sharing one IOVA allocator, so nothing restricts a
non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
that boundary the hardware faults, which shows up as unhandled SMMU page
faults and spontaneous reboots:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Given that the address range restriction is for specific VPU stream, it
should be ideally be moved to that stream. To achieve the same, a subset
of streams is now represented as subnodes, so that each can be
associated with its respective addressable range. The design was
discussed and agreed by mainatiners here
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
In the past, this limitation was addressed with an iommu-map approach,
with the iris driver dynamically creating the devices. That approach was
later concluded to be a hack to avoid having subnodes, and was NAKed by
the iommu maintainers. It was discussed in detail here:
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
Update example to the subnode form. Doing so, it picks up the supporting
properties needed on the video-codec node, address-cells, size-cells and
dma-ranges to declare 1:1 DMA translation into the parent.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
.../devicetree/bindings/media/qcom,sm8550-iris.yaml | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
index 0400ca1bff05dcef6b742c3fbf77e38adca9f280..6ee9d23554cffb30c92017ef99de15c2493455ac 100644
--- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
@@ -98,10 +98,10 @@ required:
- interconnect-names
- resets
- reset-names
- - iommus
- dma-coherent
allOf:
+ - $ref: qcom,venus-common.yaml#
- if:
properties:
compatible:
@@ -177,12 +177,23 @@ examples:
resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
reset-names = "bus";
- iommus = <&apps_smmu 0x1940 0x0000>,
- <&apps_smmu 0x1947 0x0000>;
dma-coherent;
operating-points-v2 = <&iris_opp_table>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ dma-ranges = <0x0 0x0 0xe0000000>;
+
+ non-pixel {
+ iommus = <&apps_smmu 0x1940 0x0>;
+ iommu-ranges = <0x25800000 0xba800000>;
+ };
+
+ pixel {
+ iommus = <&apps_smmu 0x1947 0x0>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [PATCH v5 02/13] dt-bindings: media: qcom,sm8550-iris: Add context bank subnodes
2026-09-26 6:34 ` [PATCH v5 02/13] dt-bindings: media: qcom,sm8550-iris: Add context bank subnodes Vikash Garodia
@ 2026-10-08 22:58 ` Bryan O'Donoghue
0 siblings, 0 replies; 41+ messages in thread
From: Bryan O'Donoghue @ 2026-10-08 22:58 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Krzysztof Kozlowski,
Vishnu Reddy
On 26/09/2026 07:34, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | pixel stream addressable range (0 - 3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
> A single "iommus" property on the video-codec node puts every stream in
> one IOMMU domain sharing one IOVA allocator, so nothing restricts a
> non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
> that boundary the hardware faults, which shows up as unhandled SMMU page
> faults and spontaneous reboots:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> Given that the address range restriction is for specific VPU stream, it
> should be ideally be moved to that stream. To achieve the same, a subset
> of streams is now represented as subnodes, so that each can be
> associated with its respective addressable range. The design was
> discussed and agreed by mainatiners here
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
>
> In the past, this limitation was addressed with an iommu-map approach,
> with the iris driver dynamically creating the devices. That approach was
> later concluded to be a hack to avoid having subnodes, and was NAKed by
> the iommu maintainers. It was discussed in detail here:
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
>
> Update example to the subnode form. Doing so, it picks up the supporting
> properties needed on the video-codec node, address-cells, size-cells and
> dma-ranges to declare 1:1 DMA translation into the parent.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH v5 03/13] dt-bindings: media: qcom,sm8750-iris: Add context bank subnodes
2026-09-26 6:33 [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
2026-09-26 6:34 ` [PATCH v5 01/13] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema Vikash Garodia
2026-09-26 6:34 ` [PATCH v5 02/13] dt-bindings: media: qcom,sm8550-iris: Add context bank subnodes Vikash Garodia
@ 2026-09-26 6:34 ` Vikash Garodia
2026-09-26 6:34 ` [PATCH v5 04/13] iommu: of_iommu: Add support for "iommu-ranges" on a device node Vikash Garodia
` (10 subsequent siblings)
13 siblings, 0 replies; 41+ messages in thread
From: Vikash Garodia @ 2026-09-26 6:34 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vikash Garodia,
Krzysztof Kozlowski, Vishnu Reddy
The VPU issues DMA through several SMMU streams, and the hardware does
not give every stream the same addressable range. The non-pixel stream
cannot address the low 600MB of IOVA space, while the pixel stream can
address the full range:
+-----------------------------------------------------------+
| non-pixel stream addressable range (600 MB - 3.5 GB) |
| 0x25800000 - 0xe0000000 |
+-----------------------------------------------------------+
| pixel stream addressable range (0 - 3.5 GB) |
| 0x00000000 - 0xe0000000 |
+-----------------------------------------------------------+
A single "iommus" property on the video-codec node puts every stream in
one IOMMU domain sharing one IOVA allocator, so nothing restricts a
non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
that boundary the hardware faults, which shows up as unhandled SMMU page
faults and spontaneous reboots:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Given that the address range restriction is for specific VPU stream, it
should be ideally be moved to that stream. To achieve the same, a subset
of streams is now represented as subnodes, so that each can be
associated with its respective addressable range. The design was discussed
and agreed by mainatiners here
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
In the past, this limitation was addressed with an iommu-map approach,
with the iris driver dynamically creating the devices. That approach
was later concluded to be a hack to avoid having subnodes, and was NAKed
by the iommu maintainers. It was discussed in detail here:
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
Update example to the subnode form. Doing so, it picks up the supporting
properties needed on the video-codec node, address-cells, size-cells and
dma-ranges to declare 1:1 DMA translation into the parent.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
.../devicetree/bindings/media/qcom,sm8750-iris.yaml | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/qcom,sm8750-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8750-iris.yaml
index c42d3470bdac796cc878090e65becf6b62bd80ca..b6d5ded1aae6a1a6836c2c24b1dae548cdc6f9d2 100644
--- a/Documentation/devicetree/bindings/media/qcom,sm8750-iris.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sm8750-iris.yaml
@@ -72,7 +72,6 @@ required:
- dma-coherent
- interconnects
- interconnect-names
- - iommus
- power-domain-names
- resets
- reset-names
@@ -110,8 +109,6 @@ examples:
"vcodec0_core_freerun";
dma-coherent;
- iommus = <&apps_smmu 0x1940 0>,
- <&apps_smmu 0x1947 0>;
interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
&config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
@@ -144,6 +141,19 @@ examples:
"core",
"vcodec0_core";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ dma-ranges = <0x0 0x0 0xe0000000>;
+
+ non-pixel {
+ iommus = <&apps_smmu 0x1940 0x0>;
+ iommu-ranges = <0x25800000 0xba800000>;
+ };
+
+ pixel {
+ iommus = <&apps_smmu 0x1947 0x0>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
^ permalink raw reply related [flat|nested] 41+ messages in thread* [PATCH v5 04/13] iommu: of_iommu: Add support for "iommu-ranges" on a device node
2026-09-26 6:33 [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (2 preceding siblings ...)
2026-09-26 6:34 ` [PATCH v5 03/13] dt-bindings: media: qcom,sm8750-iris: " Vikash Garodia
@ 2026-09-26 6:34 ` Vikash Garodia
2026-09-26 6:47 ` sashiko-bot
2026-10-09 9:27 ` bod
2026-09-26 6:34 ` [PATCH v5 05/13] media: iris: Add non-pixel and pixel context bank devices Vikash Garodia
` (9 subsequent siblings)
13 siblings, 2 replies; 41+ messages in thread
From: Vikash Garodia @ 2026-09-26 6:34 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vikash Garodia,
Vishnu Reddy
Reserving an IOVA address using "iommu-addresses" requires it to be
placed in the reserved-memory node. But when "iommu-addresses" is the
only property being described and there is no backing "reg" (i.e. no
actual reserved system memory), it does not really belong under
/reserved-memory. A device IOVA range is specific to its own address
space, and does not describe the system physical memory to make it
qualify under reserved-memory. Given this, place "iommu-addresses"
inside reserved-memory only when it is paired with a "reg", otherwise,
define it within the device own node. It was discussed here:
https://lore.kernel.org/all/662f7093-fb0a-4564-9ca0-98e03e68ba9a@kernel.org
Existing "iommu-addresses" property expects a phandle, which does
not make sense when the property is defined within the device node.
Introduce a new property, "iommu-ranges", to specify the device
specific IOVA ranges when there is no backing "reg".
Suggested-by: Rob Herring <robh@kernel.org>
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
drivers/iommu/of_iommu.c | 128 ++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 121 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index a18bb60f6f3dfdba853b6e16dd2a8616f6a731c7..9766a6944d0e11a6cd8b74b1b89428acffe3dfdf 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -190,6 +190,111 @@ iommu_resv_region_get_type(struct device *dev,
return IOMMU_RESV_RESERVED;
}
+/**
+ * of_iommu_derive_resv_regions - derive reserved regions which
+ * are outside of iommu-ranges
+ * @dev: device for which to get reserved regions
+ * @list: reserved region list
+ *
+ * A device can describe its own usable IOVA ranges directly on its node
+ * via "iommu-ranges". Everything not under those ranges is derived
+ * as a reserved region so the IOMMU allocator won't use it. Entries may
+ * appear in any order in the property.
+ */
+static void of_iommu_derive_resv_regions(struct device *dev, struct list_head *list)
+{
+ struct of_iommu_range {
+ struct list_head node;
+ phys_addr_t start;
+ phys_addr_t end;
+ } *pos, *new, *next_range;
+ int size, prot = IOMMU_READ | IOMMU_WRITE;
+ struct iommu_resv_region *region;
+ const __be32 *maps, *end;
+ struct list_head *prev;
+ phys_addr_t next = 0;
+ LIST_HEAD(ranges);
+
+ maps = of_get_property(dev->of_node, "iommu-ranges", &size);
+ if (!maps)
+ return;
+
+ end = maps + size / sizeof(__be32);
+
+ while (maps < end) {
+ phys_addr_t iova, iova_end;
+ size_t length;
+
+ maps = of_translate_dma_region(dev->of_node, maps, &iova, &length);
+ if (!maps) {
+ dev_err(dev, "%pOF: failed to parse iommu-ranges\n",
+ dev->of_node);
+ break;
+ }
+
+ if (!length)
+ continue;
+
+ iova_end = iova + length - 1;
+
+ if (iova_end < iova) {
+ dev_err(dev, "%pOF: iommu-ranges overflows address space\n",
+ dev->of_node);
+ continue;
+ }
+
+ prev = &ranges;
+ list_for_each_entry(pos, &ranges, node) {
+ if (pos->start > iova)
+ break;
+ prev = &pos->node;
+ }
+
+ new = kmalloc_obj(*new);
+ if (!new)
+ continue;
+
+ new->start = iova;
+ new->end = iova_end;
+ list_add(&new->node, prev);
+ }
+
+ if (list_empty(&ranges))
+ return;
+
+ if (of_dma_is_coherent(dev->of_node))
+ prot |= IOMMU_CACHE;
+
+ list_for_each_entry_safe(pos, next_range, &ranges, node) {
+ if (pos->start > next) {
+ region = iommu_alloc_resv_region(next, pos->start - next, prot,
+ IOMMU_RESV_RESERVED, GFP_KERNEL);
+ if (region)
+ list_add_tail(®ion->list, list);
+ }
+
+ if (pos->end == PHYS_ADDR_MAX)
+ goto exit;
+
+ if (pos->end >= next)
+ next = pos->end + 1;
+
+ list_del(&pos->node);
+ kfree(pos);
+ }
+
+ region = iommu_alloc_resv_region(next, PHYS_ADDR_MAX - next + 1,
+ prot, IOMMU_RESV_RESERVED, GFP_KERNEL);
+ if (region)
+ list_add_tail(®ion->list, list);
+
+exit:
+ list_for_each_entry_safe(pos, next_range, &ranges, node) {
+ list_del(&pos->node);
+ kfree(pos);
+ }
+}
+
/**
* of_iommu_get_resv_regions - reserved region driver helper for device tree
* @dev: device for which to get reserved regions
@@ -214,10 +319,14 @@ void of_iommu_get_resv_regions(struct device *dev, struct list_head *list)
memset(&phys, 0, sizeof(phys));
+ maps = of_get_property(it.node, "iommu-addresses", &size);
+ if (!maps)
+ continue;
+
/*
- * The "reg" property is optional and can be omitted by reserved-memory regions
- * that represent reservations in the IOVA space, which are regions that should
- * not be mapped.
+ * "iommu-addresses" must be used in combination with a "reg" that provides
+ * the physical address and size of this memory region, for an identity 1:1
+ * IOVA mapping to that physical memory.
*/
if (of_property_present(it.node, "reg")) {
err = of_address_to_resource(it.node, 0, &phys);
@@ -226,11 +335,11 @@ void of_iommu_get_resv_regions(struct device *dev, struct list_head *list)
it.node, err);
continue;
}
- }
-
- maps = of_get_property(it.node, "iommu-addresses", &size);
- if (!maps)
+ } else {
+ dev_err(dev, "%pOF: iommu-addresses requires a reg property\n",
+ it.node);
continue;
+ }
end = maps + size / sizeof(__be32);
@@ -258,6 +367,9 @@ void of_iommu_get_resv_regions(struct device *dev, struct list_head *list)
}
type = iommu_resv_region_get_type(dev, &phys, iova, length);
+ if (type != IOMMU_RESV_DIRECT)
+ continue;
+
region = iommu_alloc_resv_region(iova, length, prot, type,
GFP_KERNEL);
if (region)
@@ -265,6 +377,8 @@ void of_iommu_get_resv_regions(struct device *dev, struct list_head *list)
}
}
}
+
+ of_iommu_derive_resv_regions(dev, list);
#endif
}
EXPORT_SYMBOL(of_iommu_get_resv_regions);
--
2.34.1
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [PATCH v5 04/13] iommu: of_iommu: Add support for "iommu-ranges" on a device node
2026-09-26 6:34 ` [PATCH v5 04/13] iommu: of_iommu: Add support for "iommu-ranges" on a device node Vikash Garodia
@ 2026-09-26 6:47 ` sashiko-bot
2026-09-26 7:53 ` Vishnu Reddy
2026-10-09 9:27 ` bod
1 sibling, 1 reply; 41+ messages in thread
From: sashiko-bot @ 2026-09-26 6:47 UTC (permalink / raw)
To: Vikash Garodia; +Cc: media-ci, conor+dt, robh, devicetree
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] iommu: size_t truncation of derived reserved region length on 32-bit systems
- [Medium] iommu: DT ABI breakage by rejecting iommu-addresses without reg
- [Medium] iommu: OOB read in of_iommu_derive_resv_regions when parsing malformed iommu-ranges
--
commit 08a09989ffefcbf5d38171159dcc911ca993ff18
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
iommu: of_iommu: Add support for "iommu-ranges" on a device node
Add support for "iommu-ranges" on device nodes to specify usable IOVA
ranges directly when there is no backing "reg". Introduce logic to derive
reserved regions outside of "iommu-ranges" and restrict "iommu-addresses"
to be paired with a "reg" property.
Link: https://lore.kernel.org/all/662f7093-fb0a-4564-9ca0-98e03e68ba9a@kernel.org
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index a18bb60f6f3df..9766a6944d0e1 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
[ ... ]
> +static void of_iommu_derive_resv_regions(struct device *dev, struct list_head *list)
> +{
[ ... ]
> + maps = of_get_property(dev->of_node, "iommu-ranges", &size);
> + if (!maps)
> + return;
> +
> + end = maps + size / sizeof(__be32);
> +
> + while (maps < end) {
> + phys_addr_t iova, iova_end;
> + size_t length;
> +
> + maps = of_translate_dma_region(dev->of_node, maps, &iova, &length);
[Severity: Medium]
Could this result in an out-of-bounds read if the "iommu-ranges" property is
malformed?
The loop condition checks `maps < end`, but of_translate_dma_region()
implicitly reads `na + ns` cells from the maps array.
Does this loop need to ensure there are at least `na + ns` cells remaining
before calling the translation function to prevent reading past the buffer?
[ ... ]
> + list_for_each_entry_safe(pos, next_range, &ranges, node) {
> + if (pos->start > next) {
> + region = iommu_alloc_resv_region(next, pos->start - next, prot,
> + IOMMU_RESV_RESERVED, GFP_KERNEL);
[Severity: High]
Can the length argument overflow on 32-bit systems?
On 32-bit systems with 64-bit physical addresses (like ARM LPAE), address
differences can easily exceed 4GB. Because iommu_alloc_resv_region() takes
a 32-bit size_t length, passing a 64-bit gap size causes it to truncate.
Will this truncation result in a reservation of at most 4GB, leaving the
IOVA address space above that unprotected?
[ ... ]
> + region = iommu_alloc_resv_region(next, PHYS_ADDR_MAX - next + 1,
> + prot, IOMMU_RESV_RESERVED, GFP_KERNEL);
[Severity: High]
Similarly, can passing `PHYS_ADDR_MAX - next + 1` here truncate the length
to its lower 32 bits on 32-bit systems?
If the remaining address space exceeds 4GB, this truncation could leave high
IOVA addresses unprotected, allowing the IOMMU allocator to hand out reserved
IOVAs.
[ ... ]
> @@ -214,10 +319,14 @@ void of_iommu_get_resv_regions(struct device *dev, struct list_head *list)
[ ... ]
> - * The "reg" property is optional and can be omitted by reserved-memory regions
> - * that represent reservations in the IOVA space, which are regions that should
> - * not be mapped.
> + * "iommu-addresses" must be used in combination with a "reg" that provides
> + * the physical address and size of this memory region, for an identity 1:1
> + * IOVA mapping to that physical memory.
> */
> if (of_property_present(it.node, "reg")) {
> err = of_address_to_resource(it.node, 0, &phys);
[ ... ]
> - }
> -
> - maps = of_get_property(it.node, "iommu-addresses", &size);
> - if (!maps)
> + } else {
> + dev_err(dev, "%pOF: iommu-addresses requires a reg property\n",
> + it.node);
> continue;
> + }
[Severity: Medium]
Will this break existing device trees?
This explicitly rejects the previously valid 'no reg' device tree
configurations. Existing device trees that validly relied on
"iommu-addresses" without a "reg" property to create IOVA reservations will
now have their reservations silently ignored.
Could this lead to the IOMMU allocating IOVAs in reserved spaces, causing
DMA faults?
[ ... ]
> @@ -258,6 +367,9 @@ void of_iommu_get_resv_regions(struct device *dev, struct list_head *list)
> }
> type = iommu_resv_region_get_type(dev, &phys, iova, length);
>
> + if (type != IOMMU_RESV_DIRECT)
> + continue;
> +
> region = iommu_alloc_resv_region(iova, length, prot, type,
> GFP_KERNEL);
[Severity: Medium]
Does this newly added check actively block pure reservations?
By enforcing that only identity mappings are honored, does this violate
backward compatibility for device trees that used pure reservations?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260926-vpu_iommu_iova_handling-v5-0-0322ca5dc10c@oss.qualcomm.com?part=4
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH v5 04/13] iommu: of_iommu: Add support for "iommu-ranges" on a device node
2026-09-26 6:47 ` sashiko-bot
@ 2026-09-26 7:53 ` Vishnu Reddy
2026-10-08 10:00 ` Dmitry Baryshkov
0 siblings, 1 reply; 41+ messages in thread
From: Vishnu Reddy @ 2026-09-26 7:53 UTC (permalink / raw)
To: sashiko-reviews, Vikash Garodia; +Cc: media-ci, conor+dt, robh, devicetree
On 9/26/2026 12:17 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] iommu: size_t truncation of derived reserved region length on 32-bit systems
> - [Medium] iommu: DT ABI breakage by rejecting iommu-addresses without reg
> - [Medium] iommu: OOB read in of_iommu_derive_resv_regions when parsing malformed iommu-ranges
> --
>
> commit 08a09989ffefcbf5d38171159dcc911ca993ff18
> Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>
> iommu: of_iommu: Add support for "iommu-ranges" on a device node
>
> Add support for "iommu-ranges" on device nodes to specify usable IOVA
> ranges directly when there is no backing "reg". Introduce logic to derive
> reserved regions outside of "iommu-ranges" and restrict "iommu-addresses"
> to be paired with a "reg" property.
>
> Link: https://lore.kernel.org/all/662f7093-fb0a-4564-9ca0-98e03e68ba9a@kernel.org
>
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index a18bb60f6f3df..9766a6944d0e1 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
> [ ... ]
>> +static void of_iommu_derive_resv_regions(struct device *dev, struct list_head *list)
>> +{
> [ ... ]
>> + maps = of_get_property(dev->of_node, "iommu-ranges", &size);
>> + if (!maps)
>> + return;
>> +
>> + end = maps + size / sizeof(__be32);
>> +
>> + while (maps < end) {
>> + phys_addr_t iova, iova_end;
>> + size_t length;
>> +
>> + maps = of_translate_dma_region(dev->of_node, maps, &iova, &length);
>
> [Severity: Medium]
> Could this result in an out-of-bounds read if the "iommu-ranges" property is
> malformed?
>
> The loop condition checks `maps < end`, but of_translate_dma_region()
> implicitly reads `na + ns` cells from the maps array.
>
> Does this loop need to ensure there are at least `na + ns` cells remaining
> before calling the translation function to prevent reading past the buffer?
>
This function intention is not to validate the address and size cells here and
it's not valid to read those properties here. If the out of bound ranges are
there, then it's part of dtc checks that dt node contains invalid ranges.
> [ ... ]
>> + list_for_each_entry_safe(pos, next_range, &ranges, node) {
>> + if (pos->start > next) {
>> + region = iommu_alloc_resv_region(next, pos->start - next, prot,
>> + IOMMU_RESV_RESERVED, GFP_KERNEL);
>
> [Severity: High]
> Can the length argument overflow on 32-bit systems?
>
> On 32-bit systems with 64-bit physical addresses (like ARM LPAE), address
> differences can easily exceed 4GB. Because iommu_alloc_resv_region() takes
> a 32-bit size_t length, passing a 64-bit gap size causes it to truncate.
>
> Will this truncation result in a reservation of at most 4GB, leaving the
> IOVA address space above that unprotected?
>
> [ ... ]
>> + region = iommu_alloc_resv_region(next, PHYS_ADDR_MAX - next + 1,
>> + prot, IOMMU_RESV_RESERVED, GFP_KERNEL);
>
> [Severity: High]
> Similarly, can passing `PHYS_ADDR_MAX - next + 1` here truncate the length
> to its lower 32 bits on 32-bit systems?
>
> If the remaining address space exceeds 4GB, this truncation could leave high
> IOVA addresses unprotected, allowing the IOMMU allocator to hand out reserved
> IOVAs.
>
size_t can hold up to 32 bit range in LPAE platforms. The relevant driver has to
set the dma_limit max range in that case.
> [ ... ]
>> @@ -214,10 +319,14 @@ void of_iommu_get_resv_regions(struct device *dev, struct list_head *list)
> [ ... ]
>> - * The "reg" property is optional and can be omitted by reserved-memory regions
>> - * that represent reservations in the IOVA space, which are regions that should
>> - * not be mapped.
>> + * "iommu-addresses" must be used in combination with a "reg" that provides
>> + * the physical address and size of this memory region, for an identity 1:1
>> + * IOVA mapping to that physical memory.
>> */
>> if (of_property_present(it.node, "reg")) {
>> err = of_address_to_resource(it.node, 0, &phys);
> [ ... ]
>> - }
>> -
>> - maps = of_get_property(it.node, "iommu-addresses", &size);
>> - if (!maps)
>> + } else {
>> + dev_err(dev, "%pOF: iommu-addresses requires a reg property\n",
>> + it.node);
>> continue;
>> + }
>
> [Severity: Medium]
> Will this break existing device trees?
>
> This explicitly rejects the previously valid 'no reg' device tree
> configurations. Existing device trees that validly relied on
> "iommu-addresses" without a "reg" property to create IOVA reservations will
> now have their reservations silently ignored.
>
> Could this lead to the IOMMU allocating IOVAs in reserved spaces, causing
> DMA faults?
>
This change is intentional and clearly mentioned in commit description.
dt_schema is updated accordingly. It was discussed here:
https://lore.kernel.org/all/CAL_JsqLGOz7Fh=AsM+g84=Uko10YXU4QN1buApD3CJMkOmsebA@mail.gmail.com/
> [ ... ]
>> @@ -258,6 +367,9 @@ void of_iommu_get_resv_regions(struct device *dev, struct list_head *list)
>> }
>> type = iommu_resv_region_get_type(dev, &phys, iova, length);
>>
>> + if (type != IOMMU_RESV_DIRECT)
>> + continue;
>> +
>> region = iommu_alloc_resv_region(iova, length, prot, type,
>> GFP_KERNEL);
>
> [Severity: Medium]
> Does this newly added check actively block pure reservations?
>
> By enforcing that only identity mappings are honored, does this violate
> backward compatibility for device trees that used pure reservations?
>
If the pure reservation is carveouts region without reg, it is not allowed,
which is aligned as per the discussion. This logic now handles the case where
reg indicates the iova reserve range for direct mapping.
Thanks,
Vishnu Reddy
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH v5 04/13] iommu: of_iommu: Add support for "iommu-ranges" on a device node
2026-09-26 7:53 ` Vishnu Reddy
@ 2026-10-08 10:00 ` Dmitry Baryshkov
2026-10-09 10:41 ` Vishnu Reddy
0 siblings, 1 reply; 41+ messages in thread
From: Dmitry Baryshkov @ 2026-10-08 10:00 UTC (permalink / raw)
To: Vishnu Reddy
Cc: sashiko-reviews, Vikash Garodia, media-ci, conor+dt, robh,
devicetree
On Sat, Sep 26, 2026 at 01:23:06PM +0530, Vishnu Reddy wrote:
>
>
> On 9/26/2026 12:17 PM, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> > - [High] iommu: size_t truncation of derived reserved region length on 32-bit systems
> > - [Medium] iommu: DT ABI breakage by rejecting iommu-addresses without reg
> > - [Medium] iommu: OOB read in of_iommu_derive_resv_regions when parsing malformed iommu-ranges
> > --
> >
> > commit 08a09989ffefcbf5d38171159dcc911ca993ff18
> > Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> >
> > iommu: of_iommu: Add support for "iommu-ranges" on a device node
> >
> > Add support for "iommu-ranges" on device nodes to specify usable IOVA
> > ranges directly when there is no backing "reg". Introduce logic to derive
> > reserved regions outside of "iommu-ranges" and restrict "iommu-addresses"
> > to be paired with a "reg" property.
> >
> > Link: https://lore.kernel.org/all/662f7093-fb0a-4564-9ca0-98e03e68ba9a@kernel.org
> >
> >> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> >> index a18bb60f6f3df..9766a6944d0e1 100644
> >> --- a/drivers/iommu/of_iommu.c
> >> +++ b/drivers/iommu/of_iommu.c
> > [ ... ]
> >> +static void of_iommu_derive_resv_regions(struct device *dev, struct list_head *list)
> >> +{
> > [ ... ]
> >> + maps = of_get_property(dev->of_node, "iommu-ranges", &size);
> >> + if (!maps)
> >> + return;
> >> +
> >> + end = maps + size / sizeof(__be32);
> >> +
> >> + while (maps < end) {
> >> + phys_addr_t iova, iova_end;
> >> + size_t length;
> >> +
> >> + maps = of_translate_dma_region(dev->of_node, maps, &iova, &length);
> >
> > [Severity: Medium]
> > Could this result in an out-of-bounds read if the "iommu-ranges" property is
> > malformed?
> >
> > The loop condition checks `maps < end`, but of_translate_dma_region()
> > implicitly reads `na + ns` cells from the maps array.
> >
> > Does this loop need to ensure there are at least `na + ns` cells remaining
> > before calling the translation function to prevent reading past the buffer?
> >
>
> This function intention is not to validate the address and size cells here and
> it's not valid to read those properties here. If the out of bound ranges are
> there, then it's part of dtc checks that dt node contains invalid ranges.
>
> > [ ... ]
> >> + list_for_each_entry_safe(pos, next_range, &ranges, node) {
> >> + if (pos->start > next) {
> >> + region = iommu_alloc_resv_region(next, pos->start - next, prot,
> >> + IOMMU_RESV_RESERVED, GFP_KERNEL);
> >
> > [Severity: High]
> > Can the length argument overflow on 32-bit systems?
> >
> > On 32-bit systems with 64-bit physical addresses (like ARM LPAE), address
> > differences can easily exceed 4GB. Because iommu_alloc_resv_region() takes
> > a 32-bit size_t length, passing a 64-bit gap size causes it to truncate.
> >
> > Will this truncation result in a reservation of at most 4GB, leaving the
> > IOVA address space above that unprotected?
> >
> > [ ... ]
> >> + region = iommu_alloc_resv_region(next, PHYS_ADDR_MAX - next + 1,
> >> + prot, IOMMU_RESV_RESERVED, GFP_KERNEL);
> >
> > [Severity: High]
> > Similarly, can passing `PHYS_ADDR_MAX - next + 1` here truncate the length
> > to its lower 32 bits on 32-bit systems?
> >
> > If the remaining address space exceeds 4GB, this truncation could leave high
> > IOVA addresses unprotected, allowing the IOMMU allocator to hand out reserved
> > IOVAs.
> >
>
> size_t can hold up to 32 bit range in LPAE platforms. The relevant driver has to
> set the dma_limit max range in that case.
As this is generic code, could you please adapt the code to work
correctly on LPAE systems?
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH v5 04/13] iommu: of_iommu: Add support for "iommu-ranges" on a device node
2026-10-08 10:00 ` Dmitry Baryshkov
@ 2026-10-09 10:41 ` Vishnu Reddy
0 siblings, 0 replies; 41+ messages in thread
From: Vishnu Reddy @ 2026-10-09 10:41 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: sashiko-reviews, Vikash Garodia, media-ci, conor+dt, robh,
devicetree
On 10/8/2026 3:30 PM, Dmitry Baryshkov wrote:
> On Sat, Sep 26, 2026 at 01:23:06PM +0530, Vishnu Reddy wrote:
>>
>> On 9/26/2026 12:17 PM, sashiko-bot@kernel.org wrote:
>>> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
>>> - [High] iommu: size_t truncation of derived reserved region length on 32-bit systems
>>> - [Medium] iommu: DT ABI breakage by rejecting iommu-addresses without reg
>>> - [Medium] iommu: OOB read in of_iommu_derive_resv_regions when parsing malformed iommu-ranges
>>> --
>>>
>>> commit 08a09989ffefcbf5d38171159dcc911ca993ff18
>>> Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>>>
>>> iommu: of_iommu: Add support for "iommu-ranges" on a device node
>>>
>>> Add support for "iommu-ranges" on device nodes to specify usable IOVA
>>> ranges directly when there is no backing "reg". Introduce logic to derive
>>> reserved regions outside of "iommu-ranges" and restrict "iommu-addresses"
>>> to be paired with a "reg" property.
>>>
>>> Link: https://lore.kernel.org/all/662f7093-fb0a-4564-9ca0-98e03e68ba9a@kernel.org
>>>
>>>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>>>> index a18bb60f6f3df..9766a6944d0e1 100644
>>>> --- a/drivers/iommu/of_iommu.c
>>>> +++ b/drivers/iommu/of_iommu.c
>>> [ ... ]
>>>> +static void of_iommu_derive_resv_regions(struct device *dev, struct list_head *list)
>>>> +{
>>> [ ... ]
>>>> + maps = of_get_property(dev->of_node, "iommu-ranges", &size);
>>>> + if (!maps)
>>>> + return;
>>>> +
>>>> + end = maps + size / sizeof(__be32);
>>>> +
>>>> + while (maps < end) {
>>>> + phys_addr_t iova, iova_end;
>>>> + size_t length;
>>>> +
>>>> + maps = of_translate_dma_region(dev->of_node, maps, &iova, &length);
>>> [Severity: Medium]
>>> Could this result in an out-of-bounds read if the "iommu-ranges" property is
>>> malformed?
>>>
>>> The loop condition checks `maps < end`, but of_translate_dma_region()
>>> implicitly reads `na + ns` cells from the maps array.
>>>
>>> Does this loop need to ensure there are at least `na + ns` cells remaining
>>> before calling the translation function to prevent reading past the buffer?
>>>
>> This function intention is not to validate the address and size cells here and
>> it's not valid to read those properties here. If the out of bound ranges are
>> there, then it's part of dtc checks that dt node contains invalid ranges.
>>
>>> [ ... ]
>>>> + list_for_each_entry_safe(pos, next_range, &ranges, node) {
>>>> + if (pos->start > next) {
>>>> + region = iommu_alloc_resv_region(next, pos->start - next, prot,
>>>> + IOMMU_RESV_RESERVED, GFP_KERNEL);
>>> [Severity: High]
>>> Can the length argument overflow on 32-bit systems?
>>>
>>> On 32-bit systems with 64-bit physical addresses (like ARM LPAE), address
>>> differences can easily exceed 4GB. Because iommu_alloc_resv_region() takes
>>> a 32-bit size_t length, passing a 64-bit gap size causes it to truncate.
>>>
>>> Will this truncation result in a reservation of at most 4GB, leaving the
>>> IOVA address space above that unprotected?
>>>
>>> [ ... ]
>>>> + region = iommu_alloc_resv_region(next, PHYS_ADDR_MAX - next + 1,
>>>> + prot, IOMMU_RESV_RESERVED, GFP_KERNEL);
>>> [Severity: High]
>>> Similarly, can passing `PHYS_ADDR_MAX - next + 1` here truncate the length
>>> to its lower 32 bits on 32-bit systems?
>>>
>>> If the remaining address space exceeds 4GB, this truncation could leave high
>>> IOVA addresses unprotected, allowing the IOMMU allocator to hand out reserved
>>> IOVAs.
>>>
>> size_t can hold up to 32 bit range in LPAE platforms. The relevant driver has to
>> set the dma_limit max range in that case.
> As this is generic code, could you please adapt the code to work
> correctly on LPAE systems?
This is no different than the existing logic where client tries to reserve
greater than 32bit length on the 32bit LPAE platforms.
I'm not convinced why sashiko claims this is introduced in this patch.
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v5 04/13] iommu: of_iommu: Add support for "iommu-ranges" on a device node
2026-09-26 6:34 ` [PATCH v5 04/13] iommu: of_iommu: Add support for "iommu-ranges" on a device node Vikash Garodia
2026-09-26 6:47 ` sashiko-bot
@ 2026-10-09 9:27 ` bod
1 sibling, 0 replies; 41+ messages in thread
From: bod @ 2026-10-09 9:27 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa, linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vishnu Reddy
On 2026-09-26 12:04 +0530, Vikash Garodia wrote:
> Reserving an IOVA address using "iommu-addresses" requires it to be
> placed in the reserved-memory node. But when "iommu-addresses" is the
> only property being described and there is no backing "reg" (i.e. no
> actual reserved system memory), it does not really belong under
> /reserved-memory. A device IOVA range is specific to its own address
> space, and does not describe the system physical memory to make it
> qualify under reserved-memory. Given this, place "iommu-addresses"
> inside reserved-memory only when it is paired with a "reg", otherwise,
> define it within the device own node. It was discussed here:
> https://lore.kernel.org/all/662f7093-fb0a-4564-9ca0-98e03e68ba9a@kernel.org
>
> Existing "iommu-addresses" property expects a phandle, which does
> not make sense when the property is defined within the device node.
> Introduce a new property, "iommu-ranges", to specify the device
> specific IOVA ranges when there is no backing "reg".
>
> Suggested-by: Rob Herring <robh@kernel.org>
> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
I think we need to get buy-in from the IOMMU people on this change before
we commit to bindings that may be affected by a rejection.
i.e. There's no point in absorbing potentially DOA bindings.
---
bod
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH v5 05/13] media: iris: Add non-pixel and pixel context bank devices
2026-09-26 6:33 [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (3 preceding siblings ...)
2026-09-26 6:34 ` [PATCH v5 04/13] iommu: of_iommu: Add support for "iommu-ranges" on a device node Vikash Garodia
@ 2026-09-26 6:34 ` Vikash Garodia
2026-09-26 6:34 ` [PATCH v5 06/13] media: iris: Route buffers to the matching context bank device Vikash Garodia
` (8 subsequent siblings)
13 siblings, 0 replies; 41+ messages in thread
From: Vikash Garodia @ 2026-09-26 6:34 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vikash Garodia,
Vishnu Reddy
The VPU issues DMA through several SMMU streams, and the hardware does
not give every stream the same addressable range. The non-pixel stream
cannot address the low 600MB of IOVA space, while the pixel stream can
address the full range:
+-----------------------------------------------------------+
| non-pixel stream addressable range (600 MB - 3.5 GB) |
| 0x25800000 - 0xe0000000 |
+-----------------------------------------------------------+
| pixel stream addressable range (0 - 3.5 GB) |
| 0x00000000 - 0xe0000000 |
+-----------------------------------------------------------+
A single "iommus" property on the video-codec node puts every stream in
one IOMMU domain sharing one IOVA allocator, so nothing restricts a
non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
that boundary the hardware faults, which shows up as unhandled SMMU page
faults and spontaneous reboots:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Now the device tree describes "non-pixel" and "pixel" as separate
context bank subnodes, each carrying its own "iommus" stream IDs.
Add helper functions to create and clean up devices from these DT
subnodes, and call them from iris_probe() and iris_remove(). This
applies to the common probe path as it is required for all platforms.
Set the context banks before v4l2_device_register() so the DMA plumbing
is in place before any video device is visible to userspace, and tear
them down on the probe error path and in iris_remove().
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
drivers/media/platform/qcom/iris/iris_core.h | 4 ++
drivers/media/platform/qcom/iris/iris_probe.c | 71 ++++++++++++++++++++++++++-
2 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/iris/iris_core.h b/drivers/media/platform/qcom/iris/iris_core.h
index 24da60448cf24820af7947b85eb7208555ab7786..3c96f46cf567b2802148b2a7cedb8488b6b9468b 100644
--- a/drivers/media/platform/qcom/iris/iris_core.h
+++ b/drivers/media/platform/qcom/iris/iris_core.h
@@ -36,6 +36,8 @@ struct qcom_ubwc_cfg_data;
* struct iris_core - holds core parameters valid for all instances
*
* @dev: reference to device structure
+ * @np_dev: reference to non-pixel device structure
+ * @p_dev: reference to pixel device structure
* @reg_base: IO memory base address
* @irq: iris irq
* @v4l2_dev: a holder for v4l2 device structure
@@ -81,6 +83,8 @@ struct qcom_ubwc_cfg_data;
struct iris_core {
struct device *dev;
+ struct device *np_dev;
+ struct device *p_dev;
void __iomem *reg_base;
int irq;
struct v4l2_device v4l2_dev;
diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
index e4acf4a74f944bcae83089ef5489f204d4b0078e..debd1f0e57038d7abf463e82fd80f887b67750e8 100644
--- a/drivers/media/platform/qcom/iris/iris_probe.c
+++ b/drivers/media/platform/qcom/iris/iris_probe.c
@@ -150,6 +150,67 @@ static int iris_init_resources(struct iris_core *core)
return iris_init_resets(core);
}
+static struct device *iris_create_cb_dev(struct iris_core *core, const char *name)
+{
+ struct platform_device_info plat_dev_info = {};
+ struct device_node *child_of_node;
+ struct platform_device *pdev;
+
+ child_of_node = of_get_child_by_name(core->dev->of_node, name);
+ if (!child_of_node)
+ return NULL;
+
+ plat_dev_info.dma_mask = core->iris_platform_data->dma_mask;
+ plat_dev_info.fwnode = &child_of_node->fwnode;
+ plat_dev_info.name = child_of_node->name;
+ plat_dev_info.id = PLATFORM_DEVID_AUTO;
+ plat_dev_info.parent = core->dev;
+
+ pdev = platform_device_register_full(&plat_dev_info);
+ of_node_put(child_of_node);
+ if (IS_ERR(pdev))
+ return ERR_CAST(pdev);
+
+ dma_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
+ dma_set_seg_boundary(&pdev->dev, DMA_BIT_MASK(32));
+
+ return &pdev->dev;
+}
+
+static int iris_init_cb_devs(struct iris_core *core)
+{
+ struct device *dev;
+
+ dev = iris_create_cb_dev(core, "non-pixel");
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
+
+ core->np_dev = dev;
+
+ dev = iris_create_cb_dev(core, "pixel");
+ if (IS_ERR(dev))
+ goto unreg_np_dev;
+
+ core->p_dev = dev;
+
+ return 0;
+
+unreg_np_dev:
+ if (core->np_dev)
+ platform_device_unregister(to_platform_device(core->np_dev));
+ core->np_dev = NULL;
+
+ return PTR_ERR(dev);
+}
+
+static void iris_deinit_cb_devs(struct iris_core *core)
+{
+ if (core->p_dev)
+ platform_device_unregister(to_platform_device(core->p_dev));
+ if (core->np_dev)
+ platform_device_unregister(to_platform_device(core->np_dev));
+}
+
static int iris_register_video_device(struct iris_core *core, enum domain_type type)
{
struct video_device *vdev;
@@ -207,6 +268,8 @@ static void iris_remove(struct platform_device *pdev)
v4l2_device_unregister(&core->v4l2_dev);
+ iris_deinit_cb_devs(core);
+
mutex_destroy(&core->lock);
}
@@ -269,10 +332,14 @@ static int iris_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = v4l2_device_register(dev, &core->v4l2_dev);
+ ret = iris_init_cb_devs(core);
if (ret)
return ret;
+ ret = v4l2_device_register(dev, &core->v4l2_dev);
+ if (ret)
+ goto err_cb_deinit;
+
ret = iris_register_video_device(core, DECODER);
if (ret)
goto err_v4l2_unreg;
@@ -306,6 +373,8 @@ static int iris_probe(struct platform_device *pdev)
video_unregister_device(core->vdev_dec);
err_v4l2_unreg:
v4l2_device_unregister(&core->v4l2_dev);
+err_cb_deinit:
+ iris_deinit_cb_devs(core);
return ret;
}
--
2.34.1
^ permalink raw reply related [flat|nested] 41+ messages in thread* [PATCH v5 06/13] media: iris: Route buffers to the matching context bank device
2026-09-26 6:33 [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (4 preceding siblings ...)
2026-09-26 6:34 ` [PATCH v5 05/13] media: iris: Add non-pixel and pixel context bank devices Vikash Garodia
@ 2026-09-26 6:34 ` Vikash Garodia
2026-09-26 6:49 ` sashiko-bot
2026-09-26 6:34 ` [PATCH v5 07/13] media: iris: Skip DMA mask setup when the core device has no IOMMU Vikash Garodia
` (7 subsequent siblings)
13 siblings, 1 reply; 41+ messages in thread
From: Vikash Garodia @ 2026-09-26 6:34 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vikash Garodia,
Vishnu Reddy
The VPU issues DMA through several SMMU streams, and the hardware does
not give every stream the same addressable range. The non-pixel stream
cannot address the low 600MB of IOVA space, while the pixel stream can
address the full range.
Add iris_get_cb_dev(), which maps a buffer type to the owning context
bank device. Bitstream and internal buffers (BIN, ARP, COMV, LINE,
NON_COMV, PERSIST) belong to the non-pixel device, and uncompressed
buffers (DPB, PARTIAL, SCRATCH_1, SCRATCH_2, VPSS) to the pixel device.
BUF_INPUT and BUF_OUTPUT depend on direction and are resolved from
inst->domain: for a decoder the input is non-pixel and the output pixel,
and the other way round for an encoder.
Fall back to core->dev whenever the relevant context bank device is
absent, so platforms still describing "iommus" on the parent iris node
behave exactly as before to maintain backward compatibility.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
drivers/media/platform/qcom/iris/iris_buffer.c | 8 ++---
drivers/media/platform/qcom/iris/iris_hfi_queue.c | 16 +++++----
drivers/media/platform/qcom/iris/iris_resources.c | 41 +++++++++++++++++++++++
drivers/media/platform/qcom/iris/iris_resources.h | 1 +
drivers/media/platform/qcom/iris/iris_vidc.c | 4 +--
5 files changed, 57 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/qcom/iris/iris_buffer.c b/drivers/media/platform/qcom/iris/iris_buffer.c
index eb8de60c1177f5e1ab83b90a3c8c80e0b4d1f02e..6e03d13ac1a792c539bf8fe6d26354aa29d7b3a2 100644
--- a/drivers/media/platform/qcom/iris/iris_buffer.c
+++ b/drivers/media/platform/qcom/iris/iris_buffer.c
@@ -531,7 +531,7 @@ static int iris_create_internal_buffer(struct iris_inst *inst,
enum iris_buffer_type buffer_type, u32 index)
{
struct iris_buffers *buffers = &inst->buffers[buffer_type];
- struct iris_core *core = inst->core;
+ struct device *dev = iris_get_cb_dev(inst, buffer_type);
struct iris_buffer *buffer;
if (!buffers->size)
@@ -547,7 +547,7 @@ static int iris_create_internal_buffer(struct iris_inst *inst,
buffer->buffer_size = buffers->size;
buffer->dma_attrs = DMA_ATTR_WRITE_COMBINE | DMA_ATTR_NO_KERNEL_MAPPING;
- buffer->kvaddr = dma_alloc_attrs(core->dev, buffer->buffer_size,
+ buffer->kvaddr = dma_alloc_attrs(dev, buffer->buffer_size,
&buffer->device_addr, GFP_KERNEL, buffer->dma_attrs);
if (!buffer->kvaddr) {
kfree(buffer);
@@ -650,10 +650,10 @@ int iris_queue_internal_buffers(struct iris_inst *inst, u32 plane)
void iris_destroy_internal_buffer(struct iris_inst *inst, struct iris_buffer *buffer)
{
- struct iris_core *core = inst->core;
+ struct device *dev = iris_get_cb_dev(inst, buffer->type);
list_del(&buffer->list);
- dma_free_attrs(core->dev, buffer->buffer_size, buffer->kvaddr,
+ dma_free_attrs(dev, buffer->buffer_size, buffer->kvaddr,
buffer->device_addr, buffer->dma_attrs);
kfree(buffer);
}
diff --git a/drivers/media/platform/qcom/iris/iris_hfi_queue.c b/drivers/media/platform/qcom/iris/iris_hfi_queue.c
index bf6db23b53e2106c08f2139b643f8626af8bc40a..ce6a682b0f9ada79f9fae26289db298855d777c2 100644
--- a/drivers/media/platform/qcom/iris/iris_hfi_queue.c
+++ b/drivers/media/platform/qcom/iris/iris_hfi_queue.c
@@ -245,25 +245,26 @@ static void iris_hfi_queue_deinit(struct iris_iface_q_info *iface_q)
int iris_hfi_queues_init(struct iris_core *core)
{
+ struct device *dev = core->np_dev ? core->np_dev : core->dev;
struct iris_hfi_queue_table_header *q_tbl_hdr;
u32 queue_size;
/* Iris hardware requires 4K queue alignment */
queue_size = ALIGN((sizeof(*q_tbl_hdr) + (IFACEQ_QUEUE_SIZE * IFACEQ_NUMQ)), SZ_4K);
- core->iface_q_table_vaddr = dma_alloc_attrs(core->dev, queue_size,
+ core->iface_q_table_vaddr = dma_alloc_attrs(dev, queue_size,
&core->iface_q_table_daddr,
GFP_KERNEL, DMA_ATTR_WRITE_COMBINE);
if (!core->iface_q_table_vaddr) {
- dev_err(core->dev, "queues alloc and map failed\n");
+ dev_err(dev, "queues alloc and map failed\n");
return -ENOMEM;
}
- core->sfr_vaddr = dma_alloc_attrs(core->dev, SFR_SIZE,
+ core->sfr_vaddr = dma_alloc_attrs(dev, SFR_SIZE,
&core->sfr_daddr,
GFP_KERNEL, DMA_ATTR_WRITE_COMBINE);
if (!core->sfr_vaddr) {
- dev_err(core->dev, "sfr alloc and map failed\n");
- dma_free_attrs(core->dev, queue_size, core->iface_q_table_vaddr,
+ dev_err(dev, "sfr alloc and map failed\n");
+ dma_free_attrs(dev, queue_size, core->iface_q_table_vaddr,
core->iface_q_table_daddr, DMA_ATTR_WRITE_COMBINE);
return -ENOMEM;
}
@@ -291,6 +292,7 @@ int iris_hfi_queues_init(struct iris_core *core)
void iris_hfi_queues_deinit(struct iris_core *core)
{
+ struct device *dev = core->np_dev ? core->np_dev : core->dev;
u32 queue_size;
if (!core->iface_q_table_vaddr)
@@ -300,7 +302,7 @@ void iris_hfi_queues_deinit(struct iris_core *core)
iris_hfi_queue_deinit(&core->message_queue);
iris_hfi_queue_deinit(&core->command_queue);
- dma_free_attrs(core->dev, SFR_SIZE, core->sfr_vaddr,
+ dma_free_attrs(dev, SFR_SIZE, core->sfr_vaddr,
core->sfr_daddr, DMA_ATTR_WRITE_COMBINE);
core->sfr_vaddr = NULL;
@@ -309,7 +311,7 @@ void iris_hfi_queues_deinit(struct iris_core *core)
queue_size = ALIGN(sizeof(struct iris_hfi_queue_table_header) +
(IFACEQ_QUEUE_SIZE * IFACEQ_NUMQ), SZ_4K);
- dma_free_attrs(core->dev, queue_size, core->iface_q_table_vaddr,
+ dma_free_attrs(dev, queue_size, core->iface_q_table_vaddr,
core->iface_q_table_daddr, DMA_ATTR_WRITE_COMBINE);
core->iface_q_table_vaddr = NULL;
diff --git a/drivers/media/platform/qcom/iris/iris_resources.c b/drivers/media/platform/qcom/iris/iris_resources.c
index 2c4d34c7bd77d1f78d3572f659da656eb3b12113..a6c3df892ca9888d82414ca6b48c80efbf7b06d0 100644
--- a/drivers/media/platform/qcom/iris/iris_resources.c
+++ b/drivers/media/platform/qcom/iris/iris_resources.c
@@ -12,6 +12,7 @@
#include <linux/reset.h>
#include "iris_core.h"
+#include "iris_instance.h"
#include "iris_resources.h"
#define BW_THRESHOLD 50000
@@ -138,3 +139,43 @@ int iris_disable_unprepare_clock(struct iris_core *core, enum platform_clk_type
return 0;
}
+
+struct device *iris_get_cb_dev(struct iris_inst *inst, enum iris_buffer_type buffer_type)
+{
+ struct iris_core *core = inst->core;
+ struct device *dev = NULL;
+
+ switch (buffer_type) {
+ case BUF_INPUT:
+ if (inst->domain == DECODER)
+ dev = core->np_dev;
+ else
+ dev = core->p_dev;
+ break;
+ case BUF_OUTPUT:
+ if (inst->domain == DECODER)
+ dev = core->p_dev;
+ else
+ dev = core->np_dev;
+ break;
+ case BUF_DPB:
+ case BUF_PARTIAL:
+ case BUF_SCRATCH_1:
+ case BUF_SCRATCH_2:
+ case BUF_VPSS:
+ dev = core->p_dev;
+ break;
+ case BUF_BIN:
+ case BUF_ARP:
+ case BUF_COMV:
+ case BUF_LINE:
+ case BUF_NON_COMV:
+ case BUF_PERSIST:
+ dev = core->np_dev;
+ break;
+ default:
+ dev_err(core->dev, "invalid buffer type: %d\n", buffer_type);
+ }
+
+ return dev ? dev : core->dev;
+}
diff --git a/drivers/media/platform/qcom/iris/iris_resources.h b/drivers/media/platform/qcom/iris/iris_resources.h
index 6bfbd2dc6db095ec05e53c894e048285f82446c6..a9a5bddb19c24917de4c5dba52567934b77e5c59 100644
--- a/drivers/media/platform/qcom/iris/iris_resources.h
+++ b/drivers/media/platform/qcom/iris/iris_resources.h
@@ -15,5 +15,6 @@ int iris_unset_icc_bw(struct iris_core *core);
int iris_set_icc_bw(struct iris_core *core, unsigned long icc_bw);
int iris_disable_unprepare_clock(struct iris_core *core, enum platform_clk_type clk_type);
int iris_prepare_enable_clock(struct iris_core *core, enum platform_clk_type clk_type);
+struct device *iris_get_cb_dev(struct iris_inst *inst, enum iris_buffer_type buffer_type);
#endif
diff --git a/drivers/media/platform/qcom/iris/iris_vidc.c b/drivers/media/platform/qcom/iris/iris_vidc.c
index fcbc60016beec693f2ce27927a09a2d51494bc38..064cf0a80748dab1be0515c4c2b6688aeb2b7022 100644
--- a/drivers/media/platform/qcom/iris/iris_vidc.c
+++ b/drivers/media/platform/qcom/iris/iris_vidc.c
@@ -108,7 +108,7 @@ iris_m2m_queue_init(void *priv, struct vb2_queue *src_vq, struct vb2_queue *dst_
src_vq->drv_priv = inst;
src_vq->buf_struct_size = sizeof(struct iris_buffer);
src_vq->min_reqbufs_allocation = MIN_BUFFERS;
- src_vq->dev = inst->core->dev;
+ src_vq->dev = iris_get_cb_dev(inst, BUF_INPUT);
src_vq->lock = &inst->ctx_q_lock;
ret = vb2_queue_init(src_vq);
if (ret)
@@ -122,7 +122,7 @@ iris_m2m_queue_init(void *priv, struct vb2_queue *src_vq, struct vb2_queue *dst_
dst_vq->drv_priv = inst;
dst_vq->buf_struct_size = sizeof(struct iris_buffer);
dst_vq->min_reqbufs_allocation = MIN_BUFFERS;
- dst_vq->dev = inst->core->dev;
+ dst_vq->dev = iris_get_cb_dev(inst, BUF_OUTPUT);
dst_vq->lock = &inst->ctx_q_lock;
return vb2_queue_init(dst_vq);
--
2.34.1
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [PATCH v5 06/13] media: iris: Route buffers to the matching context bank device
2026-09-26 6:34 ` [PATCH v5 06/13] media: iris: Route buffers to the matching context bank device Vikash Garodia
@ 2026-09-26 6:49 ` sashiko-bot
2026-09-26 8:31 ` Vishnu Reddy
0 siblings, 1 reply; 41+ messages in thread
From: sashiko-bot @ 2026-09-26 6:49 UTC (permalink / raw)
To: Vikash Garodia; +Cc: media-ci, devicetree, robh, conor+dt
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] media: use-after-free of context bank devices during deferred V4L2 cleanup
--
commit 720de65140e46882c5d0651161ef771fcb1189a2
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
media: iris: Route buffers to the matching context bank device
The VPU issues DMA through several SMMU streams, and the hardware does
not give every stream the same addressable range. The non-pixel stream
cannot address the low 600MB of IOVA space, while the pixel stream can
address the full range.
Add iris_get_cb_dev(), which maps a buffer type to the owning context
bank device. Bitstream and internal buffers (BIN, ARP, COMV, LINE,
NON_COMV, PERSIST) belong to the non-pixel device, and uncompressed
buffers (DPB, PARTIAL, SCRATCH_1, SCRATCH_2, VPSS) to the pixel device.
BUF_INPUT and BUF_OUTPUT depend on direction and are resolved from
inst->domain: for a decoder the input is non-pixel and the output pixel,
and the other way round for an encoder.
Fall back to core->dev whenever the relevant context bank device is
absent, so platforms still describing "iommus" on the parent iris node
behave exactly as before to maintain backward compatibility.
> diff --git a/drivers/media/platform/qcom/iris/iris_buffer.c b/drivers/media/platform/qcom/iris/iris_buffer.c
> index eb8de60c1177f..6e03d13ac1a79 100644
> --- a/drivers/media/platform/qcom/iris/iris_buffer.c
> +++ b/drivers/media/platform/qcom/iris/iris_buffer.c
> @@ -531,7 +531,7 @@ static int iris_create_internal_buffer(struct iris_inst *inst,
> enum iris_buffer_type buffer_type, u32 index)
> {
> struct iris_buffers *buffers = &inst->buffers[buffer_type];
> - struct iris_core *core = inst->core;
> + struct device *dev = iris_get_cb_dev(inst, buffer_type);
[Severity: High]
Does this acquire the context bank device for DMA mapping without taking a
reference to guarantee its lifetime matches the buffer?
If iris_remove() explicitly calls platform_device_unregister() on these
devices upon sysfs driver unbind, and no standard buffers are active, their
refcount can drop to 0 and they will be freed.
> struct iris_buffer *buffer;
>
> if (!buffers->size)
[ ... ]
> @@ -650,10 +650,10 @@ int iris_queue_internal_buffers(struct iris_inst *inst, u32 plane)
>
> void iris_destroy_internal_buffer(struct iris_inst *inst, struct iris_buffer *buffer)
> {
> - struct iris_core *core = inst->core;
> + struct device *dev = iris_get_cb_dev(inst, buffer->type);
>
> list_del(&buffer->list);
> - dma_free_attrs(core->dev, buffer->buffer_size, buffer->kvaddr,
> + dma_free_attrs(dev, buffer->buffer_size, buffer->kvaddr,
[Severity: High]
Can this result in a use-after-free of the context bank device during
deferred V4L2 cleanup?
If standard buffers are active, videobuf2 holds a reference. However, during
deferred cleanup in iris_close(), v4l2_m2m_ctx_release() frees standard
buffers before iris_destroy_all_internal_buffers() runs. This drops the
final refcount, freeing the devices.
Will this fetch and dereference the freed device pointer, passing it to
dma_free_attrs()? Additionally, does the devm-allocated core also get freed
on unbind, making inst->core a dangling pointer here?
[ ... ]
> diff --git a/drivers/media/platform/qcom/iris/iris_vidc.c b/drivers/media/platform/qcom/iris/iris_vidc.c
> index fcbc60016beec..064cf0a80748d 100644
> --- a/drivers/media/platform/qcom/iris/iris_vidc.c
> +++ b/drivers/media/platform/qcom/iris/iris_vidc.c
> @@ -108,7 +108,7 @@ iris_m2m_queue_init(void *priv, struct vb2_queue *src_vq, struct vb2_queue *dst_
> src_vq->drv_priv = inst;
> src_vq->buf_struct_size = sizeof(struct iris_buffer);
> src_vq->min_reqbufs_allocation = MIN_BUFFERS;
> - src_vq->dev = inst->core->dev;
> + src_vq->dev = iris_get_cb_dev(inst, BUF_INPUT);
[Severity: High]
Does this assign a manually lifetime-managed, short-lived device to the
long-lived vb2_queue context?
> src_vq->lock = &inst->ctx_q_lock;
> ret = vb2_queue_init(src_vq);
> if (ret)
> @@ -122,7 +122,7 @@ iris_m2m_queue_init(void *priv, struct vb2_queue *src_vq, struct vb2_queue *dst_
> dst_vq->drv_priv = inst;
> dst_vq->buf_struct_size = sizeof(struct iris_buffer);
> dst_vq->min_reqbufs_allocation = MIN_BUFFERS;
> - dst_vq->dev = inst->core->dev;
> + dst_vq->dev = iris_get_cb_dev(inst, BUF_OUTPUT);
[Severity: High]
Does this also assign a manually lifetime-managed, short-lived device to the
long-lived vb2_queue context?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260926-vpu_iommu_iova_handling-v5-0-0322ca5dc10c@oss.qualcomm.com?part=6
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH v5 06/13] media: iris: Route buffers to the matching context bank device
2026-09-26 6:49 ` sashiko-bot
@ 2026-09-26 8:31 ` Vishnu Reddy
2026-10-08 10:18 ` Dmitry Baryshkov
0 siblings, 1 reply; 41+ messages in thread
From: Vishnu Reddy @ 2026-09-26 8:31 UTC (permalink / raw)
To: sashiko-reviews, Vikash Garodia; +Cc: media-ci, devicetree, robh, conor+dt
On 9/26/2026 12:19 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] media: use-after-free of context bank devices during deferred V4L2 cleanup
> --
>
> commit 720de65140e46882c5d0651161ef771fcb1189a2
> Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>
> media: iris: Route buffers to the matching context bank device
>
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range.
> Add iris_get_cb_dev(), which maps a buffer type to the owning context
> bank device. Bitstream and internal buffers (BIN, ARP, COMV, LINE,
> NON_COMV, PERSIST) belong to the non-pixel device, and uncompressed
> buffers (DPB, PARTIAL, SCRATCH_1, SCRATCH_2, VPSS) to the pixel device.
> BUF_INPUT and BUF_OUTPUT depend on direction and are resolved from
> inst->domain: for a decoder the input is non-pixel and the output pixel,
> and the other way round for an encoder.
> Fall back to core->dev whenever the relevant context bank device is
> absent, so platforms still describing "iommus" on the parent iris node
> behave exactly as before to maintain backward compatibility.
>
>> diff --git a/drivers/media/platform/qcom/iris/iris_buffer.c b/drivers/media/platform/qcom/iris/iris_buffer.c
>> index eb8de60c1177f..6e03d13ac1a79 100644
>> --- a/drivers/media/platform/qcom/iris/iris_buffer.c
>> +++ b/drivers/media/platform/qcom/iris/iris_buffer.c
>> @@ -531,7 +531,7 @@ static int iris_create_internal_buffer(struct iris_inst *inst,
>> enum iris_buffer_type buffer_type, u32 index)
>> {
>> struct iris_buffers *buffers = &inst->buffers[buffer_type];
>> - struct iris_core *core = inst->core;
>> + struct device *dev = iris_get_cb_dev(inst, buffer_type);
>
> [Severity: High]
> Does this acquire the context bank device for DMA mapping without taking a
> reference to guarantee its lifetime matches the buffer?
>
> If iris_remove() explicitly calls platform_device_unregister() on these
> devices upon sysfs driver unbind, and no standard buffers are active, their
> refcount can drop to 0 and they will be freed.
This is not true. Remove callback cannot complete if driver module->refcnt,
refcounted during open, and not decremented with corresponding close call.
iris_close() would call iris_destroy_internal_buffers() to free up the buffers
before un-registering the device.
>
>> struct iris_buffer *buffer;
>>
>> if (!buffers->size)
>
> [ ... ]
>
>> @@ -650,10 +650,10 @@ int iris_queue_internal_buffers(struct iris_inst *inst, u32 plane)
>>
>> void iris_destroy_internal_buffer(struct iris_inst *inst, struct iris_buffer *buffer)
>> {
>> - struct iris_core *core = inst->core;
>> + struct device *dev = iris_get_cb_dev(inst, buffer->type);
>>
>> list_del(&buffer->list);
>> - dma_free_attrs(core->dev, buffer->buffer_size, buffer->kvaddr,
>> + dma_free_attrs(dev, buffer->buffer_size, buffer->kvaddr,
>
> [Severity: High]
> Can this result in a use-after-free of the context bank device during
> deferred V4L2 cleanup?
>
> If standard buffers are active, videobuf2 holds a reference. However, during
> deferred cleanup in iris_close(), v4l2_m2m_ctx_release() frees standard
> buffers before iris_destroy_all_internal_buffers() runs. This drops the
> final refcount, freeing the devices.
iris_destroy_all_internal_buffers() frees the internal buffers which is managed
within the driver outside the scope of v4l2_m2m_ctx_release().
>
> Will this fetch and dereference the freed device pointer, passing it to
> dma_free_attrs()? Additionally, does the devm-allocated core also get freed
> on unbind, making inst->core a dangling pointer here?
Unbind will not happen until iris_close() completes(explained above), which
avoids this scenario.
>
> [ ... ]
>
>> diff --git a/drivers/media/platform/qcom/iris/iris_vidc.c b/drivers/media/platform/qcom/iris/iris_vidc.c
>> index fcbc60016beec..064cf0a80748d 100644
>> --- a/drivers/media/platform/qcom/iris/iris_vidc.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vidc.c
>> @@ -108,7 +108,7 @@ iris_m2m_queue_init(void *priv, struct vb2_queue *src_vq, struct vb2_queue *dst_
>> src_vq->drv_priv = inst;
>> src_vq->buf_struct_size = sizeof(struct iris_buffer);
>> src_vq->min_reqbufs_allocation = MIN_BUFFERS;
>> - src_vq->dev = inst->core->dev;
>> + src_vq->dev = iris_get_cb_dev(inst, BUF_INPUT);
>
> [Severity: High]
> Does this assign a manually lifetime-managed, short-lived device to the
> long-lived vb2_queue context?
>
>> src_vq->lock = &inst->ctx_q_lock;
>> ret = vb2_queue_init(src_vq);
>> if (ret)
>> @@ -122,7 +122,7 @@ iris_m2m_queue_init(void *priv, struct vb2_queue *src_vq, struct vb2_queue *dst_
>> dst_vq->drv_priv = inst;
>> dst_vq->buf_struct_size = sizeof(struct iris_buffer);
>> dst_vq->min_reqbufs_allocation = MIN_BUFFERS;
>> - dst_vq->dev = inst->core->dev;
>> + dst_vq->dev = iris_get_cb_dev(inst, BUF_OUTPUT);
>
> [Severity: High]
> Does this also assign a manually lifetime-managed, short-lived device to the
> long-lived vb2_queue context?
These devices are long-lived when compare to vb2_queue and are freed only in
iris_remove().
>
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH v5 06/13] media: iris: Route buffers to the matching context bank device
2026-09-26 8:31 ` Vishnu Reddy
@ 2026-10-08 10:18 ` Dmitry Baryshkov
2026-10-09 11:14 ` Vishnu Reddy
0 siblings, 1 reply; 41+ messages in thread
From: Dmitry Baryshkov @ 2026-10-08 10:18 UTC (permalink / raw)
To: Vishnu Reddy
Cc: sashiko-reviews, Vikash Garodia, media-ci, devicetree, robh,
conor+dt
On Sat, Sep 26, 2026 at 02:01:21PM +0530, Vishnu Reddy wrote:
>
>
> On 9/26/2026 12:19 PM, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [High] media: use-after-free of context bank devices during deferred V4L2 cleanup
> > --
> >
> > commit 720de65140e46882c5d0651161ef771fcb1189a2
> > Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> >
> > media: iris: Route buffers to the matching context bank device
> >
> > The VPU issues DMA through several SMMU streams, and the hardware does
> > not give every stream the same addressable range. The non-pixel stream
> > cannot address the low 600MB of IOVA space, while the pixel stream can
> > address the full range.
> > Add iris_get_cb_dev(), which maps a buffer type to the owning context
> > bank device. Bitstream and internal buffers (BIN, ARP, COMV, LINE,
> > NON_COMV, PERSIST) belong to the non-pixel device, and uncompressed
> > buffers (DPB, PARTIAL, SCRATCH_1, SCRATCH_2, VPSS) to the pixel device.
> > BUF_INPUT and BUF_OUTPUT depend on direction and are resolved from
> > inst->domain: for a decoder the input is non-pixel and the output pixel,
> > and the other way round for an encoder.
> > Fall back to core->dev whenever the relevant context bank device is
> > absent, so platforms still describing "iommus" on the parent iris node
> > behave exactly as before to maintain backward compatibility.
> >
> >> diff --git a/drivers/media/platform/qcom/iris/iris_buffer.c b/drivers/media/platform/qcom/iris/iris_buffer.c
> >> index eb8de60c1177f..6e03d13ac1a79 100644
> >> --- a/drivers/media/platform/qcom/iris/iris_buffer.c
> >> +++ b/drivers/media/platform/qcom/iris/iris_buffer.c
> >> @@ -531,7 +531,7 @@ static int iris_create_internal_buffer(struct iris_inst *inst,
> >> enum iris_buffer_type buffer_type, u32 index)
> >> {
> >> struct iris_buffers *buffers = &inst->buffers[buffer_type];
> >> - struct iris_core *core = inst->core;
> >> + struct device *dev = iris_get_cb_dev(inst, buffer_type);
> >
> > [Severity: High]
> > Does this acquire the context bank device for DMA mapping without taking a
> > reference to guarantee its lifetime matches the buffer?
> >
> > If iris_remove() explicitly calls platform_device_unregister() on these
> > devices upon sysfs driver unbind, and no standard buffers are active, their
> > refcount can drop to 0 and they will be freed.
>
> This is not true. Remove callback cannot complete if driver module->refcnt,
> refcounted during open, and not decremented with corresponding close call.
> iris_close() would call iris_destroy_internal_buffers() to free up the buffers
> before un-registering the device.
I don't follow this comment. There is nothing about module removal.
Sashiko here (and in several other comments) tells about using the
`unbind` file in sysfs to unbind the driver from the device. The module
is still present in the memory, the module refcount is not decremented.
>
> >
> >> struct iris_buffer *buffer;
> >>
> >> if (!buffers->size)
> >
> > [ ... ]
> >
> >> @@ -650,10 +650,10 @@ int iris_queue_internal_buffers(struct iris_inst *inst, u32 plane)
> >>
> >> void iris_destroy_internal_buffer(struct iris_inst *inst, struct iris_buffer *buffer)
> >> {
> >> - struct iris_core *core = inst->core;
> >> + struct device *dev = iris_get_cb_dev(inst, buffer->type);
> >>
> >> list_del(&buffer->list);
> >> - dma_free_attrs(core->dev, buffer->buffer_size, buffer->kvaddr,
> >> + dma_free_attrs(dev, buffer->buffer_size, buffer->kvaddr,
> >
> > [Severity: High]
> > Can this result in a use-after-free of the context bank device during
> > deferred V4L2 cleanup?
> >
> > If standard buffers are active, videobuf2 holds a reference. However, during
> > deferred cleanup in iris_close(), v4l2_m2m_ctx_release() frees standard
> > buffers before iris_destroy_all_internal_buffers() runs. This drops the
> > final refcount, freeing the devices.
>
> iris_destroy_all_internal_buffers() frees the internal buffers which is managed
> within the driver outside the scope of v4l2_m2m_ctx_release().
>
> >
> > Will this fetch and dereference the freed device pointer, passing it to
> > dma_free_attrs()? Additionally, does the devm-allocated core also get freed
> > on unbind, making inst->core a dangling pointer here?
>
> Unbind will not happen until iris_close() completes(explained above), which
> avoids this scenario.
>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH v5 06/13] media: iris: Route buffers to the matching context bank device
2026-10-08 10:18 ` Dmitry Baryshkov
@ 2026-10-09 11:14 ` Vishnu Reddy
0 siblings, 0 replies; 41+ messages in thread
From: Vishnu Reddy @ 2026-10-09 11:14 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: sashiko-reviews, Vikash Garodia, media-ci, devicetree, robh,
conor+dt
On 10/8/2026 3:48 PM, Dmitry Baryshkov wrote:
> On Sat, Sep 26, 2026 at 02:01:21PM +0530, Vishnu Reddy wrote:
>>
>> On 9/26/2026 12:19 PM, sashiko-bot@kernel.org wrote:
>>> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>>> - [High] media: use-after-free of context bank devices during deferred V4L2 cleanup
>>> --
>>>
>>> commit 720de65140e46882c5d0651161ef771fcb1189a2
>>> Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>>>
>>> media: iris: Route buffers to the matching context bank device
>>>
>>> The VPU issues DMA through several SMMU streams, and the hardware does
>>> not give every stream the same addressable range. The non-pixel stream
>>> cannot address the low 600MB of IOVA space, while the pixel stream can
>>> address the full range.
>>> Add iris_get_cb_dev(), which maps a buffer type to the owning context
>>> bank device. Bitstream and internal buffers (BIN, ARP, COMV, LINE,
>>> NON_COMV, PERSIST) belong to the non-pixel device, and uncompressed
>>> buffers (DPB, PARTIAL, SCRATCH_1, SCRATCH_2, VPSS) to the pixel device.
>>> BUF_INPUT and BUF_OUTPUT depend on direction and are resolved from
>>> inst->domain: for a decoder the input is non-pixel and the output pixel,
>>> and the other way round for an encoder.
>>> Fall back to core->dev whenever the relevant context bank device is
>>> absent, so platforms still describing "iommus" on the parent iris node
>>> behave exactly as before to maintain backward compatibility.
>>>
>>>> diff --git a/drivers/media/platform/qcom/iris/iris_buffer.c b/drivers/media/platform/qcom/iris/iris_buffer.c
>>>> index eb8de60c1177f..6e03d13ac1a79 100644
>>>> --- a/drivers/media/platform/qcom/iris/iris_buffer.c
>>>> +++ b/drivers/media/platform/qcom/iris/iris_buffer.c
>>>> @@ -531,7 +531,7 @@ static int iris_create_internal_buffer(struct iris_inst *inst,
>>>> enum iris_buffer_type buffer_type, u32 index)
>>>> {
>>>> struct iris_buffers *buffers = &inst->buffers[buffer_type];
>>>> - struct iris_core *core = inst->core;
>>>> + struct device *dev = iris_get_cb_dev(inst, buffer_type);
>>> [Severity: High]
>>> Does this acquire the context bank device for DMA mapping without taking a
>>> reference to guarantee its lifetime matches the buffer?
>>>
>>> If iris_remove() explicitly calls platform_device_unregister() on these
>>> devices upon sysfs driver unbind, and no standard buffers are active, their
>>> refcount can drop to 0 and they will be freed.
>> This is not true. Remove callback cannot complete if driver module->refcnt,
>> refcounted during open, and not decremented with corresponding close call.
>> iris_close() would call iris_destroy_internal_buffers() to free up the buffers
>> before un-registering the device.
> I don't follow this comment. There is nothing about module removal.
> Sashiko here (and in several other comments) tells about using the
> `unbind` file in sysfs to unbind the driver from the device. The module
> is still present in the memory, the module refcount is not decremented.
Thanks for clarifying the comment. Detaching the driver from device at runtime
might leave the interaction with hardware unclosed.
Would prefer adding something like this
.suppress_bind_attrs = true;
Again, this is not just applicable to sub-node devices, but to parent device
too. Sashiko should classify this as a pre-existing issue.
>>>> struct iris_buffer *buffer;
>>>>
>>>> if (!buffers->size)
>>> [ ... ]
>>>
>>>> @@ -650,10 +650,10 @@ int iris_queue_internal_buffers(struct iris_inst *inst, u32 plane)
>>>>
>>>> void iris_destroy_internal_buffer(struct iris_inst *inst, struct iris_buffer *buffer)
>>>> {
>>>> - struct iris_core *core = inst->core;
>>>> + struct device *dev = iris_get_cb_dev(inst, buffer->type);
>>>>
>>>> list_del(&buffer->list);
>>>> - dma_free_attrs(core->dev, buffer->buffer_size, buffer->kvaddr,
>>>> + dma_free_attrs(dev, buffer->buffer_size, buffer->kvaddr,
>>> [Severity: High]
>>> Can this result in a use-after-free of the context bank device during
>>> deferred V4L2 cleanup?
>>>
>>> If standard buffers are active, videobuf2 holds a reference. However, during
>>> deferred cleanup in iris_close(), v4l2_m2m_ctx_release() frees standard
>>> buffers before iris_destroy_all_internal_buffers() runs. This drops the
>>> final refcount, freeing the devices.
>> iris_destroy_all_internal_buffers() frees the internal buffers which is managed
>> within the driver outside the scope of v4l2_m2m_ctx_release().
>>
>>> Will this fetch and dereference the freed device pointer, passing it to
>>> dma_free_attrs()? Additionally, does the devm-allocated core also get freed
>>> on unbind, making inst->core a dangling pointer here?
>> Unbind will not happen until iris_close() completes(explained above), which
>> avoids this scenario.
>>
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH v5 07/13] media: iris: Skip DMA mask setup when the core device has no IOMMU
2026-09-26 6:33 [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (5 preceding siblings ...)
2026-09-26 6:34 ` [PATCH v5 06/13] media: iris: Route buffers to the matching context bank device Vikash Garodia
@ 2026-09-26 6:34 ` Vikash Garodia
2026-09-26 6:34 ` [PATCH v5 08/13] arm64: dts: qcom: hamoa: Add Iris context bank subnodes Vikash Garodia
` (6 subsequent siblings)
13 siblings, 0 replies; 41+ messages in thread
From: Vikash Garodia @ 2026-09-26 6:34 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vikash Garodia,
Vishnu Reddy
Once the streams are described as context bank subnodes, the "iommus"
property no longer sits on the parent iris node. That device then has no
IOMMU domain of its own and never performs DMA directly, so calling
dma_set_mask_and_coherent() on it is meaningless, and on a device with no
IOMMU it can fail and abort probe.
Set the DMA mask only when device_iommu_mapped() reports an IOMMU on the
core device. Platforms that have not been converted still carry "iommus"
on the parent node and keep the existing setup. For converted platforms
the mask is applied to each context bank device instead, in
iris_create_cb_dev().
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
drivers/media/platform/qcom/iris/iris_probe.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
index debd1f0e57038d7abf463e82fd80f887b67750e8..4bdb078d83b5c331869dab2409bc4d10ab302737 100644
--- a/drivers/media/platform/qcom/iris/iris_probe.c
+++ b/drivers/media/platform/qcom/iris/iris_probe.c
@@ -352,9 +352,11 @@ static int iris_probe(struct platform_device *pdev)
dma_mask = core->iris_platform_data->dma_mask;
- ret = dma_set_mask_and_coherent(dev, dma_mask);
- if (ret)
- goto err_vdev_unreg_enc;
+ if (device_iommu_mapped(dev)) {
+ ret = dma_set_mask_and_coherent(dev, dma_mask);
+ if (ret)
+ goto err_vdev_unreg_enc;
+ }
dma_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
dma_set_seg_boundary(&pdev->dev, DMA_BIT_MASK(32));
--
2.34.1
^ permalink raw reply related [flat|nested] 41+ messages in thread* [PATCH v5 08/13] arm64: dts: qcom: hamoa: Add Iris context bank subnodes
2026-09-26 6:33 [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (6 preceding siblings ...)
2026-09-26 6:34 ` [PATCH v5 07/13] media: iris: Skip DMA mask setup when the core device has no IOMMU Vikash Garodia
@ 2026-09-26 6:34 ` Vikash Garodia
2026-09-30 10:32 ` Konrad Dybcio
2026-10-08 10:18 ` Dmitry Baryshkov
2026-09-26 6:34 ` [PATCH v5 09/13] arm64: dts: qcom: sm8550: " Vikash Garodia
` (5 subsequent siblings)
13 siblings, 2 replies; 41+ messages in thread
From: Vikash Garodia @ 2026-09-26 6:34 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vikash Garodia,
Vishnu Reddy
The VPU issues DMA through several SMMU streams, and the hardware does
not give every stream the same addressable range. The non-pixel stream
cannot address the low 600MB of IOVA space, while the pixel stream can
address the full range:
+-----------------------------------------------------------+
| non-pixel stream addressable range (600 MB - 3.5 GB) |
| 0x25800000 - 0xe0000000 |
+-----------------------------------------------------------+
| pixel stream addressable range (0 - 3.5 GB) |
| 0x00000000 - 0xe0000000 |
+-----------------------------------------------------------+
A single "iommus" property on the video-codec node puts every stream in
one IOMMU domain sharing one IOVA allocator, so nothing restricts a
non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
that boundary the hardware faults, which shows up as unhandled SMMU page
faults and spontaneous reboots:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Given that the address range restriction is for specific VPU stream, it
should be ideally be moved to that stream. To achieve the same, a subset
of streams is now represented as subnodes, so that each can be
associated with its respective addressable range. The design was discussed
and agreed by mainatiners here
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
In the past, this limitation was addressed with an iommu-map approach,
with the iris driver dynamically creating the devices. That approach
was later concluded to be a hack to avoid having subnodes, and was NAKed
by the iommu maintainers. It was discussed in detail here:
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
The video-codec node includes address-cells, size-cells and dma-ranges
to declare 1:1 mapping for DMA translation to the parent.
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/hamoa.dtsi | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 4e35254cdd11a87eb5e4817abd09a603522309e2..9819a1f5686ce92c2249cc1dd65a491665fcfb94 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -5468,10 +5468,12 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
reset-names = "bus";
- iommus = <&apps_smmu 0x1940 0>,
- <&apps_smmu 0x1947 0>;
dma-coherent;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ dma-ranges = <0x0 0x0 0x0 0xe0000000>;
+
/*
* IRIS firmware is signed by vendors, only
* enable on boards where the proper signed firmware
@@ -5479,6 +5481,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
*/
status = "disabled";
+ non-pixel {
+ iommus = <&apps_smmu 0x1940 0x0>;
+ iommu-ranges = <0x25800000 0xba800000>;
+ };
+
+ pixel {
+ iommus = <&apps_smmu 0x1947 0x0>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [PATCH v5 08/13] arm64: dts: qcom: hamoa: Add Iris context bank subnodes
2026-09-26 6:34 ` [PATCH v5 08/13] arm64: dts: qcom: hamoa: Add Iris context bank subnodes Vikash Garodia
@ 2026-09-30 10:32 ` Konrad Dybcio
2026-10-08 10:18 ` Dmitry Baryshkov
1 sibling, 0 replies; 41+ messages in thread
From: Konrad Dybcio @ 2026-09-30 10:32 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Stanimir Varbanov, Neil Armstrong, Dmitry Baryshkov,
Bryan O'Donoghue, Stephan Gerhold, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Krzysztof Kozlowski, iommu, Vishnu Reddy
On 9/26/26 8:34 AM, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v5 08/13] arm64: dts: qcom: hamoa: Add Iris context bank subnodes
2026-09-26 6:34 ` [PATCH v5 08/13] arm64: dts: qcom: hamoa: Add Iris context bank subnodes Vikash Garodia
2026-09-30 10:32 ` Konrad Dybcio
@ 2026-10-08 10:18 ` Dmitry Baryshkov
1 sibling, 0 replies; 41+ messages in thread
From: Dmitry Baryshkov @ 2026-10-08 10:18 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Bryan O'Donoghue, Stephan Gerhold,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Abel Vesa,
linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vishnu Reddy
On Sat, Sep 26, 2026 at 12:04:07PM +0530, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | pixel stream addressable range (0 - 3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
> A single "iommus" property on the video-codec node puts every stream in
> one IOMMU domain sharing one IOVA allocator, so nothing restricts a
> non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
> that boundary the hardware faults, which shows up as unhandled SMMU page
> faults and spontaneous reboots:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> Given that the address range restriction is for specific VPU stream, it
> should be ideally be moved to that stream. To achieve the same, a subset
> of streams is now represented as subnodes, so that each can be
> associated with its respective addressable range. The design was discussed
> and agreed by mainatiners here
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
>
> In the past, this limitation was addressed with an iommu-map approach,
> with the iris driver dynamically creating the devices. That approach
> was later concluded to be a hack to avoid having subnodes, and was NAKed
> by the iommu maintainers. It was discussed in detail here:
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
>
> The video-codec node includes address-cells, size-cells and dma-ranges
> to declare 1:1 mapping for DMA translation to the parent.
>
> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/hamoa.dtsi | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH v5 09/13] arm64: dts: qcom: sm8550: Add Iris context bank subnodes
2026-09-26 6:33 [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (7 preceding siblings ...)
2026-09-26 6:34 ` [PATCH v5 08/13] arm64: dts: qcom: hamoa: Add Iris context bank subnodes Vikash Garodia
@ 2026-09-26 6:34 ` Vikash Garodia
2026-09-30 10:32 ` Konrad Dybcio
2026-10-08 10:19 ` Dmitry Baryshkov
2026-09-26 6:34 ` [PATCH v5 10/13] arm64: dts: qcom: lemans: " Vikash Garodia
` (4 subsequent siblings)
13 siblings, 2 replies; 41+ messages in thread
From: Vikash Garodia @ 2026-09-26 6:34 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vikash Garodia,
Vishnu Reddy
The VPU issues DMA through several SMMU streams, and the hardware does
not give every stream the same addressable range. The non-pixel stream
cannot address the low 600MB of IOVA space, while the pixel stream can
address the full range:
+-----------------------------------------------------------+
| non-pixel stream addressable range (600 MB - 3.5 GB) |
| 0x25800000 - 0xe0000000 |
+-----------------------------------------------------------+
| pixel stream addressable range (0 - 3.5 GB) |
| 0x00000000 - 0xe0000000 |
+-----------------------------------------------------------+
A single "iommus" property on the video-codec node puts every stream in
one IOMMU domain sharing one IOVA allocator, so nothing restricts a
non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
that boundary the hardware faults, which shows up as unhandled SMMU page
faults and spontaneous reboots:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Given that the address range restriction is for specific VPU stream, it
should be ideally be moved to that stream. To achieve the same, a subset
of streams is now represented as subnodes, so that each can be
associated with its respective addressable range. The design was discussed
and agreed by mainatiners here
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
In the past, this limitation was addressed with an iommu-map approach,
with the iris driver dynamically creating the devices. That approach
was later concluded to be a hack to avoid having subnodes, and was NAKed
by the iommu maintainers. It was discussed in detail here:
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
The video-codec node includes address-cells, size-cells and dma-ranges
to declare 1:1 mapping for DMA translation to the parent.
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 23604436add303348867f890890f2f7af4f831af..60164b853ae0764cdd79c4680490e66a548b0613 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -3690,8 +3690,6 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
reset-names = "bus";
- iommus = <&apps_smmu 0x1940 0>,
- <&apps_smmu 0x1947 0>;
dma-coherent;
/*
@@ -3701,6 +3699,19 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
*/
status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ dma-ranges = <0x0 0x0 0x0 0xe0000000>;
+
+ non-pixel {
+ iommus = <&apps_smmu 0x1940 0x0>;
+ iommu-ranges = <0x25800000 0xba800000>;
+ };
+
+ pixel {
+ iommus = <&apps_smmu 0x1947 0x0>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [PATCH v5 09/13] arm64: dts: qcom: sm8550: Add Iris context bank subnodes
2026-09-26 6:34 ` [PATCH v5 09/13] arm64: dts: qcom: sm8550: " Vikash Garodia
@ 2026-09-30 10:32 ` Konrad Dybcio
2026-10-08 10:19 ` Dmitry Baryshkov
1 sibling, 0 replies; 41+ messages in thread
From: Konrad Dybcio @ 2026-09-30 10:32 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Stanimir Varbanov, Neil Armstrong, Dmitry Baryshkov,
Bryan O'Donoghue, Stephan Gerhold, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Krzysztof Kozlowski, iommu, Vishnu Reddy
On 9/26/26 8:34 AM, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | pixel stream addressable range (0 - 3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
> A single "iommus" property on the video-codec node puts every stream in
> one IOMMU domain sharing one IOVA allocator, so nothing restricts a
> non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
> that boundary the hardware faults, which shows up as unhandled SMMU page
> faults and spontaneous reboots:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> Given that the address range restriction is for specific VPU stream, it
> should be ideally be moved to that stream. To achieve the same, a subset
> of streams is now represented as subnodes, so that each can be
> associated with its respective addressable range. The design was discussed
> and agreed by mainatiners here
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
>
> In the past, this limitation was addressed with an iommu-map approach,
> with the iris driver dynamically creating the devices. That approach
> was later concluded to be a hack to avoid having subnodes, and was NAKed
> by the iommu maintainers. It was discussed in detail here:
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
>
> The video-codec node includes address-cells, size-cells and dma-ranges
> to declare 1:1 mapping for DMA translation to the parent.
>
> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v5 09/13] arm64: dts: qcom: sm8550: Add Iris context bank subnodes
2026-09-26 6:34 ` [PATCH v5 09/13] arm64: dts: qcom: sm8550: " Vikash Garodia
2026-09-30 10:32 ` Konrad Dybcio
@ 2026-10-08 10:19 ` Dmitry Baryshkov
1 sibling, 0 replies; 41+ messages in thread
From: Dmitry Baryshkov @ 2026-10-08 10:19 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Bryan O'Donoghue, Stephan Gerhold,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Abel Vesa,
linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vishnu Reddy
On Sat, Sep 26, 2026 at 12:04:08PM +0530, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | pixel stream addressable range (0 - 3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
> A single "iommus" property on the video-codec node puts every stream in
> one IOMMU domain sharing one IOVA allocator, so nothing restricts a
> non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
> that boundary the hardware faults, which shows up as unhandled SMMU page
> faults and spontaneous reboots:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> Given that the address range restriction is for specific VPU stream, it
> should be ideally be moved to that stream. To achieve the same, a subset
> of streams is now represented as subnodes, so that each can be
> associated with its respective addressable range. The design was discussed
> and agreed by mainatiners here
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
>
> In the past, this limitation was addressed with an iommu-map approach,
> with the iris driver dynamically creating the devices. That approach
> was later concluded to be a hack to avoid having subnodes, and was NAKed
> by the iommu maintainers. It was discussed in detail here:
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
>
> The video-codec node includes address-cells, size-cells and dma-ranges
> to declare 1:1 mapping for DMA translation to the parent.
>
> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/sm8550.dtsi | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH v5 10/13] arm64: dts: qcom: lemans: Add Iris context bank subnodes
2026-09-26 6:33 [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (8 preceding siblings ...)
2026-09-26 6:34 ` [PATCH v5 09/13] arm64: dts: qcom: sm8550: " Vikash Garodia
@ 2026-09-26 6:34 ` Vikash Garodia
2026-09-30 10:33 ` Konrad Dybcio
2026-10-08 10:19 ` Dmitry Baryshkov
2026-09-26 6:34 ` [PATCH v5 11/13] arm64: dts: qcom: monaco: " Vikash Garodia
` (3 subsequent siblings)
13 siblings, 2 replies; 41+ messages in thread
From: Vikash Garodia @ 2026-09-26 6:34 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vikash Garodia,
Vishnu Reddy
The VPU issues DMA through several SMMU streams, and the hardware does
not give every stream the same addressable range. The non-pixel stream
cannot address the low 600MB of IOVA space, while the pixel stream can
address the full range:
+-----------------------------------------------------------+
| non-pixel stream addressable range (600 MB - 3.5 GB) |
| 0x25800000 - 0xe0000000 |
+-----------------------------------------------------------+
| pixel stream addressable range (0 - 3.5 GB) |
| 0x00000000 - 0xe0000000 |
+-----------------------------------------------------------+
A single "iommus" property on the video-codec node puts every stream in
one IOMMU domain sharing one IOVA allocator, so nothing restricts a
non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
that boundary the hardware faults, which shows up as unhandled SMMU page
faults and spontaneous reboots:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Given that the address range restriction is for specific VPU stream, it
should be ideally be moved to that stream. To achieve the same, a subset
of streams is now represented as subnodes, so that each can be
associated with its respective addressable range. The design was discussed
and agreed by mainatiners here
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
In the past, this limitation was addressed with an iommu-map approach,
with the iris driver dynamically creating the devices. That approach
was later concluded to be a hack to avoid having subnodes, and was NAKed
by the iommu maintainers. It was discussed in detail here:
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
The video-codec node includes address-cells, size-cells and dma-ranges
to declare 1:1 mapping for DMA translation to the parent.
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/lemans.dtsi | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index 695eae1b7256911e656ab1ecdd92aca135d92f39..afed5e43b4fcda8b8400e815d24c5094834677f3 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -4962,12 +4962,23 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
reset-names = "bus";
- iommus = <&apps_smmu 0x0880 0x0400>,
- <&apps_smmu 0x0887 0x0400>;
dma-coherent;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ dma-ranges = <0x0 0x0 0x0 0xe0000000>;
+
status = "disabled";
+ non-pixel {
+ iommus = <&apps_smmu 0x0880 0x0400>;
+ iommu-ranges = <0x25800000 0xba800000>;
+ };
+
+ pixel {
+ iommus = <&apps_smmu 0x0887 0x0400>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [PATCH v5 10/13] arm64: dts: qcom: lemans: Add Iris context bank subnodes
2026-09-26 6:34 ` [PATCH v5 10/13] arm64: dts: qcom: lemans: " Vikash Garodia
@ 2026-09-30 10:33 ` Konrad Dybcio
2026-10-08 10:19 ` Dmitry Baryshkov
1 sibling, 0 replies; 41+ messages in thread
From: Konrad Dybcio @ 2026-09-30 10:33 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Stanimir Varbanov, Neil Armstrong, Dmitry Baryshkov,
Bryan O'Donoghue, Stephan Gerhold, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Krzysztof Kozlowski, iommu, Vishnu Reddy
On 9/26/26 8:34 AM, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | pixel stream addressable range (0 - 3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v5 10/13] arm64: dts: qcom: lemans: Add Iris context bank subnodes
2026-09-26 6:34 ` [PATCH v5 10/13] arm64: dts: qcom: lemans: " Vikash Garodia
2026-09-30 10:33 ` Konrad Dybcio
@ 2026-10-08 10:19 ` Dmitry Baryshkov
1 sibling, 0 replies; 41+ messages in thread
From: Dmitry Baryshkov @ 2026-10-08 10:19 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Bryan O'Donoghue, Stephan Gerhold,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Abel Vesa,
linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vishnu Reddy
On Sat, Sep 26, 2026 at 12:04:09PM +0530, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | pixel stream addressable range (0 - 3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
> A single "iommus" property on the video-codec node puts every stream in
> one IOMMU domain sharing one IOVA allocator, so nothing restricts a
> non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
> that boundary the hardware faults, which shows up as unhandled SMMU page
> faults and spontaneous reboots:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> Given that the address range restriction is for specific VPU stream, it
> should be ideally be moved to that stream. To achieve the same, a subset
> of streams is now represented as subnodes, so that each can be
> associated with its respective addressable range. The design was discussed
> and agreed by mainatiners here
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
>
> In the past, this limitation was addressed with an iommu-map approach,
> with the iris driver dynamically creating the devices. That approach
> was later concluded to be a hack to avoid having subnodes, and was NAKed
> by the iommu maintainers. It was discussed in detail here:
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
>
> The video-codec node includes address-cells, size-cells and dma-ranges
> to declare 1:1 mapping for DMA translation to the parent.
>
> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/lemans.dtsi | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH v5 11/13] arm64: dts: qcom: monaco: Add Iris context bank subnodes
2026-09-26 6:33 [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (9 preceding siblings ...)
2026-09-26 6:34 ` [PATCH v5 10/13] arm64: dts: qcom: lemans: " Vikash Garodia
@ 2026-09-26 6:34 ` Vikash Garodia
2026-09-30 10:33 ` Konrad Dybcio
2026-10-08 10:19 ` Dmitry Baryshkov
2026-09-26 6:34 ` [PATCH v5 12/13] arm64: dts: qcom: sm8650: " Vikash Garodia
` (2 subsequent siblings)
13 siblings, 2 replies; 41+ messages in thread
From: Vikash Garodia @ 2026-09-26 6:34 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vikash Garodia,
Vishnu Reddy
The VPU issues DMA through several SMMU streams, and the hardware does
not give every stream the same addressable range. The non-pixel stream
cannot address the low 600MB of IOVA space, while the pixel stream can
address the full range:
+-----------------------------------------------------------+
| non-pixel stream addressable range (600 MB - 3.5 GB) |
| 0x25800000 - 0xe0000000 |
+-----------------------------------------------------------+
| pixel stream addressable range (0 - 3.5 GB) |
| 0x00000000 - 0xe0000000 |
+-----------------------------------------------------------+
A single "iommus" property on the video-codec node puts every stream in
one IOMMU domain sharing one IOVA allocator, so nothing restricts a
non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
that boundary the hardware faults, which shows up as unhandled SMMU page
faults and spontaneous reboots:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Given that the address range restriction is for specific VPU stream, it
should be ideally be moved to that stream. To achieve the same, a subset
of streams is now represented as subnodes, so that each can be
associated with its respective addressable range. The design was discussed
and agreed by mainatiners here
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
In the past, this limitation was addressed with an iommu-map approach,
with the iris driver dynamically creating the devices. That approach
was later concluded to be a hack to avoid having subnodes, and was NAKed
by the iommu maintainers. It was discussed in detail here:
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
The video-codec node includes address-cells, size-cells and dma-ranges
to declare 1:1 mapping for DMA translation to the parent.
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 395d32d368443e6c73b934b183c3de007ca2e6b5..89ea87a274a159da872facb688cd742d8d28f3c5 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -5403,12 +5403,23 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
reset-names = "bus";
- iommus = <&apps_smmu 0x0880 0x0400>,
- <&apps_smmu 0x0887 0x0400>;
dma-coherent;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ dma-ranges = <0x0 0x0 0x0 0xe0000000>;
+
status = "disabled";
+ non-pixel {
+ iommus = <&apps_smmu 0x0880 0x0400>;
+ iommu-ranges = <0x25800000 0xba800000>;
+ };
+
+ pixel {
+ iommus = <&apps_smmu 0x0887 0x0400>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [PATCH v5 11/13] arm64: dts: qcom: monaco: Add Iris context bank subnodes
2026-09-26 6:34 ` [PATCH v5 11/13] arm64: dts: qcom: monaco: " Vikash Garodia
@ 2026-09-30 10:33 ` Konrad Dybcio
2026-10-08 10:19 ` Dmitry Baryshkov
1 sibling, 0 replies; 41+ messages in thread
From: Konrad Dybcio @ 2026-09-30 10:33 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Stanimir Varbanov, Neil Armstrong, Dmitry Baryshkov,
Bryan O'Donoghue, Stephan Gerhold, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Krzysztof Kozlowski, iommu, Vishnu Reddy
On 9/26/26 8:34 AM, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | pixel stream addressable range (0 - 3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v5 11/13] arm64: dts: qcom: monaco: Add Iris context bank subnodes
2026-09-26 6:34 ` [PATCH v5 11/13] arm64: dts: qcom: monaco: " Vikash Garodia
2026-09-30 10:33 ` Konrad Dybcio
@ 2026-10-08 10:19 ` Dmitry Baryshkov
1 sibling, 0 replies; 41+ messages in thread
From: Dmitry Baryshkov @ 2026-10-08 10:19 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Bryan O'Donoghue, Stephan Gerhold,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Abel Vesa,
linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vishnu Reddy
On Sat, Sep 26, 2026 at 12:04:10PM +0530, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | pixel stream addressable range (0 - 3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
> A single "iommus" property on the video-codec node puts every stream in
> one IOMMU domain sharing one IOVA allocator, so nothing restricts a
> non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
> that boundary the hardware faults, which shows up as unhandled SMMU page
> faults and spontaneous reboots:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> Given that the address range restriction is for specific VPU stream, it
> should be ideally be moved to that stream. To achieve the same, a subset
> of streams is now represented as subnodes, so that each can be
> associated with its respective addressable range. The design was discussed
> and agreed by mainatiners here
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
>
> In the past, this limitation was addressed with an iommu-map approach,
> with the iris driver dynamically creating the devices. That approach
> was later concluded to be a hack to avoid having subnodes, and was NAKed
> by the iommu maintainers. It was discussed in detail here:
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
>
> The video-codec node includes address-cells, size-cells and dma-ranges
> to declare 1:1 mapping for DMA translation to the parent.
>
> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/monaco.dtsi | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH v5 12/13] arm64: dts: qcom: sm8650: Add Iris context bank subnodes
2026-09-26 6:33 [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (10 preceding siblings ...)
2026-09-26 6:34 ` [PATCH v5 11/13] arm64: dts: qcom: monaco: " Vikash Garodia
@ 2026-09-26 6:34 ` Vikash Garodia
2026-09-30 10:33 ` Konrad Dybcio
2026-10-08 10:19 ` Dmitry Baryshkov
2026-09-26 6:34 ` [PATCH v5 13/13] arm64: dts: qcom: sm8750: " Vikash Garodia
2026-09-30 10:33 ` [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Konrad Dybcio
13 siblings, 2 replies; 41+ messages in thread
From: Vikash Garodia @ 2026-09-26 6:34 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vikash Garodia,
Vishnu Reddy
The VPU issues DMA through several SMMU streams, and the hardware does
not give every stream the same addressable range. The non-pixel stream
cannot address the low 600MB of IOVA space, while the pixel stream can
address the full range:
+-----------------------------------------------------------+
| non-pixel stream addressable range (600 MB - 3.5 GB) |
| 0x25800000 - 0xe0000000 |
+-----------------------------------------------------------+
| pixel stream addressable range (0 - 3.5 GB) |
| 0x00000000 - 0xe0000000 |
+-----------------------------------------------------------+
A single "iommus" property on the video-codec node puts every stream in
one IOMMU domain sharing one IOVA allocator, so nothing restricts a
non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
that boundary the hardware faults, which shows up as unhandled SMMU page
faults and spontaneous reboots:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Given that the address range restriction is for specific VPU stream, it
should be ideally be moved to that stream. To achieve the same, a subset
of streams is now represented as subnodes, so that each can be
associated with its respective addressable range. The design was discussed
and agreed by mainatiners here
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
In the past, this limitation was addressed with an iommu-map approach,
with the iris driver dynamically creating the devices. That approach
was later concluded to be a hack to avoid having subnodes, and was NAKed
by the iommu maintainers. It was discussed in detail here:
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
The video-codec node includes address-cells, size-cells and dma-ranges
to declare 1:1 mapping for DMA translation to the parent.
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index 4e317c422d92ed72dca8bd97ac33c89f9b462218..078115d57dacd5d5f407cb4592c989ba0e9f78c4 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -5274,11 +5274,12 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
"xo",
"core";
- iommus = <&apps_smmu 0x1940 0>,
- <&apps_smmu 0x1947 0>;
-
dma-coherent;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ dma-ranges = <0x0 0x0 0x0 0xe0000000>;
+
/*
* IRIS firmware is signed by vendors, only
* enable on boards where the proper signed firmware
@@ -5286,6 +5287,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
*/
status = "disabled";
+ non-pixel {
+ iommus = <&apps_smmu 0x1940 0x0>;
+ iommu-ranges = <0x25800000 0xba800000>;
+ };
+
+ pixel {
+ iommus = <&apps_smmu 0x1947 0x0>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [PATCH v5 12/13] arm64: dts: qcom: sm8650: Add Iris context bank subnodes
2026-09-26 6:34 ` [PATCH v5 12/13] arm64: dts: qcom: sm8650: " Vikash Garodia
@ 2026-09-30 10:33 ` Konrad Dybcio
2026-10-08 10:19 ` Dmitry Baryshkov
1 sibling, 0 replies; 41+ messages in thread
From: Konrad Dybcio @ 2026-09-30 10:33 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Stanimir Varbanov, Neil Armstrong, Dmitry Baryshkov,
Bryan O'Donoghue, Stephan Gerhold, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Krzysztof Kozlowski, iommu, Vishnu Reddy
On 9/26/26 8:34 AM, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v5 12/13] arm64: dts: qcom: sm8650: Add Iris context bank subnodes
2026-09-26 6:34 ` [PATCH v5 12/13] arm64: dts: qcom: sm8650: " Vikash Garodia
2026-09-30 10:33 ` Konrad Dybcio
@ 2026-10-08 10:19 ` Dmitry Baryshkov
1 sibling, 0 replies; 41+ messages in thread
From: Dmitry Baryshkov @ 2026-10-08 10:19 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Bryan O'Donoghue, Stephan Gerhold,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Abel Vesa,
linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vishnu Reddy
On Sat, Sep 26, 2026 at 12:04:11PM +0530, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | pixel stream addressable range (0 - 3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
> A single "iommus" property on the video-codec node puts every stream in
> one IOMMU domain sharing one IOVA allocator, so nothing restricts a
> non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
> that boundary the hardware faults, which shows up as unhandled SMMU page
> faults and spontaneous reboots:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> Given that the address range restriction is for specific VPU stream, it
> should be ideally be moved to that stream. To achieve the same, a subset
> of streams is now represented as subnodes, so that each can be
> associated with its respective addressable range. The design was discussed
> and agreed by mainatiners here
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
>
> In the past, this limitation was addressed with an iommu-map approach,
> with the iris driver dynamically creating the devices. That approach
> was later concluded to be a hack to avoid having subnodes, and was NAKed
> by the iommu maintainers. It was discussed in detail here:
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
>
> The video-codec node includes address-cells, size-cells and dma-ranges
> to declare 1:1 mapping for DMA translation to the parent.
>
> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/sm8650.dtsi | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH v5 13/13] arm64: dts: qcom: sm8750: Add Iris context bank subnodes
2026-09-26 6:33 [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (11 preceding siblings ...)
2026-09-26 6:34 ` [PATCH v5 12/13] arm64: dts: qcom: sm8650: " Vikash Garodia
@ 2026-09-26 6:34 ` Vikash Garodia
2026-09-30 10:33 ` Konrad Dybcio
2026-10-08 10:19 ` Dmitry Baryshkov
2026-09-30 10:33 ` [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Konrad Dybcio
13 siblings, 2 replies; 41+ messages in thread
From: Vikash Garodia @ 2026-09-26 6:34 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Dmitry Baryshkov, Bryan O'Donoghue,
Stephan Gerhold, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vikash Garodia,
Vishnu Reddy
The VPU issues DMA through several SMMU streams, and the hardware does
not give every stream the same addressable range. The non-pixel stream
cannot address the low 600MB of IOVA space, while the pixel stream can
address the full range:
+-----------------------------------------------------------+
| non-pixel stream addressable range (600 MB - 3.5 GB) |
| 0x25800000 - 0xe0000000 |
+-----------------------------------------------------------+
| pixel stream addressable range (0 - 3.5 GB) |
| 0x00000000 - 0xe0000000 |
+-----------------------------------------------------------+
A single "iommus" property on the video-codec node puts every stream in
one IOMMU domain sharing one IOVA allocator, so nothing restricts a
non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
that boundary the hardware faults, which shows up as unhandled SMMU page
faults and spontaneous reboots:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Given that the address range restriction is for specific VPU stream, it
should be ideally be moved to that stream. To achieve the same, a subset
of streams is now represented as subnodes, so that each can be
associated with its respective addressable range. The design was discussed
and agreed by mainatiners here
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
In the past, this limitation was addressed with an iommu-map approach,
with the iris driver dynamically creating the devices. That approach
was later concluded to be a hack to avoid having subnodes, and was NAKed
by the iommu maintainers. It was discussed in detail here:
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
The video-codec node includes address-cells, size-cells and dma-ranges
to declare 1:1 mapping for DMA translation to the parent.
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8750.dtsi | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index 28cf22da854d01413b8e86be3f6330354aad05f2..2e1e07eb5b6aa49850a7a5572ef9e755e298b799 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -3025,8 +3025,6 @@ iris: video-codec@aa00000 {
"vcodec0_core_freerun";
dma-coherent;
- iommus = <&apps_smmu 0x1940 0>,
- <&apps_smmu 0x1947 0>;
interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
&config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
@@ -3059,6 +3057,10 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
"core",
"vcodec0_core";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ dma-ranges = <0x0 0x0 0x0 0xe0000000>;
+
/*
* IRIS firmware is signed by vendors, only
* enable in boards where the proper signed firmware
@@ -3066,6 +3068,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
*/
status = "disabled";
+ non-pixel {
+ iommus = <&apps_smmu 0x1940 0x0>;
+ iommu-ranges = <0x25800000 0xba800000>;
+ };
+
+ pixel {
+ iommus = <&apps_smmu 0x1947 0x0>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
^ permalink raw reply related [flat|nested] 41+ messages in thread* Re: [PATCH v5 13/13] arm64: dts: qcom: sm8750: Add Iris context bank subnodes
2026-09-26 6:34 ` [PATCH v5 13/13] arm64: dts: qcom: sm8750: " Vikash Garodia
@ 2026-09-30 10:33 ` Konrad Dybcio
2026-10-08 10:19 ` Dmitry Baryshkov
1 sibling, 0 replies; 41+ messages in thread
From: Konrad Dybcio @ 2026-09-30 10:33 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Stanimir Varbanov, Neil Armstrong, Dmitry Baryshkov,
Bryan O'Donoghue, Stephan Gerhold, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Krzysztof Kozlowski, iommu, Vishnu Reddy
On 9/26/26 8:34 AM, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
> +-----------------------------------------------------------+
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v5 13/13] arm64: dts: qcom: sm8750: Add Iris context bank subnodes
2026-09-26 6:34 ` [PATCH v5 13/13] arm64: dts: qcom: sm8750: " Vikash Garodia
2026-09-30 10:33 ` Konrad Dybcio
@ 2026-10-08 10:19 ` Dmitry Baryshkov
1 sibling, 0 replies; 41+ messages in thread
From: Dmitry Baryshkov @ 2026-10-08 10:19 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Stanimir Varbanov,
Neil Armstrong, Bryan O'Donoghue, Stephan Gerhold,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Abel Vesa,
linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, iommu, Vishnu Reddy
On Sat, Sep 26, 2026 at 12:04:12PM +0530, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not give every stream the same addressable range. The non-pixel stream
> cannot address the low 600MB of IOVA space, while the pixel stream can
> address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | pixel stream addressable range (0 - 3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
> A single "iommus" property on the video-codec node puts every stream in
> one IOMMU domain sharing one IOVA allocator, so nothing restricts a
> non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
> that boundary the hardware faults, which shows up as unhandled SMMU page
> faults and spontaneous reboots:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> Given that the address range restriction is for specific VPU stream, it
> should be ideally be moved to that stream. To achieve the same, a subset
> of streams is now represented as subnodes, so that each can be
> associated with its respective addressable range. The design was discussed
> and agreed by mainatiners here
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org
>
> In the past, this limitation was addressed with an iommu-map approach,
> with the iris driver dynamically creating the devices. That approach
> was later concluded to be a hack to avoid having subnodes, and was NAKed
> by the iommu maintainers. It was discussed in detail here:
> https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
>
> The video-codec node includes address-cells, size-cells and dma-ranges
> to declare 1:1 mapping for DMA translation to the parent.
>
> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/sm8750.dtsi | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes
2026-09-26 6:33 [PATCH v5 00/13] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (12 preceding siblings ...)
2026-09-26 6:34 ` [PATCH v5 13/13] arm64: dts: qcom: sm8750: " Vikash Garodia
@ 2026-09-30 10:33 ` Konrad Dybcio
13 siblings, 0 replies; 41+ messages in thread
From: Konrad Dybcio @ 2026-09-30 10:33 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Stanimir Varbanov, Neil Armstrong, Dmitry Baryshkov,
Bryan O'Donoghue, Stephan Gerhold, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Abel Vesa
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Krzysztof Kozlowski, iommu, Krzysztof Kozlowski, Vishnu Reddy
On 9/26/26 8:33 AM, Vikash Garodia wrote:
> The VPU issues DMA through several SMMU streams, and the hardware does
> not restricts specific streams with specific addressable range. The
> non-pixel stream is restricted to use 0-600MB of IOVA space, while the
> pixel stream can address the full range:
> +-----------------------------------------------------------+
> | non-pixel stream addressable range (600 MB - 3.5 GB) |
> | 0x25800000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | pixel stream addressable range (0 - 3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
Please address all venus/iris-enabled platforms once this lands
Konrad
^ permalink raw reply [flat|nested] 41+ messages in thread