* [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes
2026-07-09 12:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Vikash Garodia
@ 2026-07-09 12:35 ` Vikash Garodia
2026-07-09 12:50 ` Dmitry Baryshkov
2026-07-10 22:02 ` Bryan O'Donoghue
2026-07-09 12:35 ` [RFC PATCH 02/11] media: iris: Add hooks to initialize and tear down context banks Vikash Garodia
` (10 subsequent siblings)
11 siblings, 2 replies; 30+ messages in thread
From: Vikash Garodia @ 2026-07-09 12:35 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vikash Garodia, Vishnu Reddy
VPU hardwares have a limitation where VPU streams are associated with
dedicated addressable address range, as illustrated below
+-----------------------------------------------------------+
| Stream A reserved region (600 MB) |
| 0x00000000 - 0x25800000 |
+-----------------------------------------------------------+
| Stream B reserved region (3.5 GB) |
| 0x00000000 - 0xe0000000 |
+-----------------------------------------------------------+
| Other reserved regions |
+-----------------------------------------------------------+
Mapping a stream outside its expected range can cause unintended
behavior, including device crashes, as reported at:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
To address this limitation, the subset of stream/s are now represented as
sub nodes, so that they can be associated to the respective addressable
range.
The limitation could be exposed when running usecase like concurrent
video sessions. The binding have been validated with higher concurrent
sessions across the SOCs supported under this schema.
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>
---
.../bindings/media/qcom,sm8550-iris.yaml | 66 +++++++++++++++++++++-
1 file changed, 63 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..bf4d24ce90bd38666704274390b98be450f708c0 100644
--- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
@@ -91,6 +91,51 @@ properties:
opp-table:
type: object
+ '#address-cells':
+ const: 2
+
+ '#size-cells':
+ const: 2
+
+ non-pixel:
+ type: object
+ description:
+ Non pixel context bank is needed when video hardware have distinct iommus for non pixel
+ buffers. Non pixel buffers are compressed and internal buffers.
+ properties:
+ iommus:
+ maxItems: 1
+ memory-region:
+ maxItems: 1
+ required:
+ - iommus
+ - memory-region
+ additionalProperties: false
+
+ pixel:
+ type: object
+ description:
+ Pixel context bank is needed when video hardware have distinct iommus for pixel buffers.
+ Pixel buffers are uncompressed buffers.
+ properties:
+ iommus:
+ maxItems: 1
+ required:
+ - iommus
+ additionalProperties: false
+
+ firmware:
+ type: object
+ description:
+ Firmware context bank represents the firmware processing domain of the VPU. Required to boot
+ VPU when no hypervisor is present.
+ properties:
+ iommus:
+ maxItems: 1
+ required:
+ - iommus
+ additionalProperties: false
+
required:
- compatible
- power-domain-names
@@ -98,9 +143,15 @@ required:
- interconnect-names
- resets
- reset-names
- - iommus
- dma-coherent
+oneOf:
+ - required:
+ - iommus
+ - required:
+ - non-pixel
+ - pixel
+
allOf:
- if:
properties:
@@ -177,12 +228,21 @@ 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 = <2>;
+ #size-cells = <2>;
+ iris_non_pixel: non-pixel {
+ iommus = <&apps_smmu 0x1940 0x0000>;
+ memory-region = <&iris_resv>;
+ };
+
+ iris_pixel: pixel {
+ iommus = <&apps_smmu 0x1947 0x0000>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes
2026-07-09 12:35 ` [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu " Vikash Garodia
@ 2026-07-09 12:50 ` Dmitry Baryshkov
2026-07-10 6:02 ` Vikash Garodia
2026-07-10 22:02 ` Bryan O'Donoghue
1 sibling, 1 reply; 30+ messages in thread
From: Dmitry Baryshkov @ 2026-07-09 12:50 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, linux-media,
linux-arm-msm, devicetree, linux-kernel, Vishnu Reddy
On Thu, Jul 09, 2026 at 06:05:47PM +0530, Vikash Garodia wrote:
> VPU hardwares have a limitation where VPU streams are associated with
> dedicated addressable address range, as illustrated below
>
> +-----------------------------------------------------------+
> | Stream A reserved region (600 MB) |
> | 0x00000000 - 0x25800000 |
> +-----------------------------------------------------------+
> | Stream B reserved region (3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | Other reserved regions |
> +-----------------------------------------------------------+
>
> Mapping a stream outside its expected range can cause unintended
> behavior, including device crashes, as reported at:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> To address this limitation, the subset of stream/s are now represented as
> sub nodes, so that they can be associated to the respective addressable
> range.
> The limitation could be exposed when running usecase like concurrent
> video sessions. The binding have been validated with higher concurrent
> sessions across the SOCs supported under this schema.
>
> 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>
> ---
> .../bindings/media/qcom,sm8550-iris.yaml | 66 +++++++++++++++++++++-
> 1 file changed, 63 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..bf4d24ce90bd38666704274390b98be450f708c0 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> @@ -91,6 +91,51 @@ properties:
> opp-table:
> type: object
>
> + '#address-cells':
> + const: 2
> +
> + '#size-cells':
> + const: 2
> +
> + non-pixel:
> + type: object
> + description:
> + Non pixel context bank is needed when video hardware have distinct iommus for non pixel
> + buffers. Non pixel buffers are compressed and internal buffers.
> + properties:
> + iommus:
> + maxItems: 1
> + memory-region:
> + maxItems: 1
> + required:
> + - iommus
> + - memory-region
> + additionalProperties: false
> +
> + pixel:
> + type: object
> + description:
> + Pixel context bank is needed when video hardware have distinct iommus for pixel buffers.
> + Pixel buffers are uncompressed buffers.
> + properties:
> + iommus:
> + maxItems: 1
> + required:
> + - iommus
> + additionalProperties: false
> +
> + firmware:
> + type: object
> + description:
> + Firmware context bank represents the firmware processing domain of the VPU. Required to boot
> + VPU when no hypervisor is present.
> + properties:
> + iommus:
> + maxItems: 1
> + required:
> + - iommus
> + additionalProperties: false
> +
> required:
> - compatible
> - power-domain-names
> @@ -98,9 +143,15 @@ required:
> - interconnect-names
> - resets
> - reset-names
> - - iommus
> - dma-coherent
>
> +oneOf:
> + - required:
> + - iommus
> + - required:
> + - non-pixel
> + - pixel
> +
> allOf:
> - if:
> properties:
> @@ -177,12 +228,21 @@ 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 = <2>;
> + #size-cells = <2>;
I think you need "ranges;" here. Also an empty line before the subnodes.
> + iris_non_pixel: non-pixel {
Drop useless labels.
> + iommus = <&apps_smmu 0x1940 0x0000>;
> + memory-region = <&iris_resv>;
> + };
> +
> + iris_pixel: pixel {
> + iommus = <&apps_smmu 0x1947 0x0000>;
> + };
> +
> iris_opp_table: opp-table {
> compatible = "operating-points-v2";
>
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes
2026-07-09 12:50 ` Dmitry Baryshkov
@ 2026-07-10 6:02 ` Vikash Garodia
2026-07-10 15:53 ` Dmitry Baryshkov
0 siblings, 1 reply; 30+ messages in thread
From: Vikash Garodia @ 2026-07-10 6:02 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-media,
linux-arm-msm, devicetree, linux-kernel, Vishnu Reddy
On 7/9/2026 6:20 PM, Dmitry Baryshkov wrote:
> On Thu, Jul 09, 2026 at 06:05:47PM +0530, Vikash Garodia wrote:
>> VPU hardwares have a limitation where VPU streams are associated with
>> dedicated addressable address range, as illustrated below
>>
>> +-----------------------------------------------------------+
>> | Stream A reserved region (600 MB) |
>> | 0x00000000 - 0x25800000 |
>> +-----------------------------------------------------------+
>> | Stream B reserved region (3.5 GB) |
>> | 0x00000000 - 0xe0000000 |
>> +-----------------------------------------------------------+
>> | Other reserved regions |
>> +-----------------------------------------------------------+
>>
>> Mapping a stream outside its expected range can cause unintended
>> behavior, including device crashes, as reported at:
>> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>>
>> To address this limitation, the subset of stream/s are now represented as
>> sub nodes, so that they can be associated to the respective addressable
>> range.
>> The limitation could be exposed when running usecase like concurrent
>> video sessions. The binding have been validated with higher concurrent
>> sessions across the SOCs supported under this schema.
>>
>> 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>
>> ---
>> .../bindings/media/qcom,sm8550-iris.yaml | 66 +++++++++++++++++++++-
>> 1 file changed, 63 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..bf4d24ce90bd38666704274390b98be450f708c0 100644
>> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>> @@ -91,6 +91,51 @@ properties:
>> opp-table:
>> type: object
>>
>> + '#address-cells':
>> + const: 2
>> +
>> + '#size-cells':
>> + const: 2
>> +
>> + non-pixel:
>> + type: object
>> + description:
>> + Non pixel context bank is needed when video hardware have distinct iommus for non pixel
>> + buffers. Non pixel buffers are compressed and internal buffers.
>> + properties:
>> + iommus:
>> + maxItems: 1
>> + memory-region:
>> + maxItems: 1
>> + required:
>> + - iommus
>> + - memory-region
>> + additionalProperties: false
>> +
>> + pixel:
>> + type: object
>> + description:
>> + Pixel context bank is needed when video hardware have distinct iommus for pixel buffers.
>> + Pixel buffers are uncompressed buffers.
>> + properties:
>> + iommus:
>> + maxItems: 1
>> + required:
>> + - iommus
>> + additionalProperties: false
>> +
>> + firmware:
>> + type: object
>> + description:
>> + Firmware context bank represents the firmware processing domain of the VPU. Required to boot
>> + VPU when no hypervisor is present.
>> + properties:
>> + iommus:
>> + maxItems: 1
>> + required:
>> + - iommus
>> + additionalProperties: false
>> +
>> required:
>> - compatible
>> - power-domain-names
>> @@ -98,9 +143,15 @@ required:
>> - interconnect-names
>> - resets
>> - reset-names
>> - - iommus
>> - dma-coherent
>>
>> +oneOf:
>> + - required:
>> + - iommus
>> + - required:
>> + - non-pixel
>> + - pixel
>> +
>> allOf:
>> - if:
>> properties:
>> @@ -177,12 +228,21 @@ 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 = <2>;
>> + #size-cells = <2>;
>
> I think you need "ranges;" here. Also an empty line before the subnodes.
Could you please elaborate on what would be the use of "ranges;" in this
case ?
>
>> + iris_non_pixel: non-pixel {
>
> Drop useless labels.
Ack, labels can be dropped from schema.
>
>> + iommus = <&apps_smmu 0x1940 0x0000>;
>> + memory-region = <&iris_resv>;
>> + };
>> +
>> + iris_pixel: pixel {
>> + iommus = <&apps_smmu 0x1947 0x0000>;
>> + };
>> +
>> iris_opp_table: opp-table {
>> compatible = "operating-points-v2";
>>
>>
>> --
>> 2.34.1
>>
>
Regards,
Vikash
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes
2026-07-10 6:02 ` Vikash Garodia
@ 2026-07-10 15:53 ` Dmitry Baryshkov
2026-07-11 5:46 ` Vikash Garodia
0 siblings, 1 reply; 30+ messages in thread
From: Dmitry Baryshkov @ 2026-07-10 15:53 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, linux-media,
linux-arm-msm, devicetree, linux-kernel, Vishnu Reddy
On Fri, Jul 10, 2026 at 11:32:20AM +0530, Vikash Garodia wrote:
>
> On 7/9/2026 6:20 PM, Dmitry Baryshkov wrote:
> > On Thu, Jul 09, 2026 at 06:05:47PM +0530, Vikash Garodia wrote:
> > > VPU hardwares have a limitation where VPU streams are associated with
> > > dedicated addressable address range, as illustrated below
> > >
> > > +-----------------------------------------------------------+
> > > | Stream A reserved region (600 MB) |
> > > | 0x00000000 - 0x25800000 |
> > > +-----------------------------------------------------------+
> > > | Stream B reserved region (3.5 GB) |
> > > | 0x00000000 - 0xe0000000 |
> > > +-----------------------------------------------------------+
> > > | Other reserved regions |
> > > +-----------------------------------------------------------+
> > >
> > > Mapping a stream outside its expected range can cause unintended
> > > behavior, including device crashes, as reported at:
> > > https://gitlab.freedesktop.org/drm/msm/-/work_items/100
> > >
> > > To address this limitation, the subset of stream/s are now represented as
> > > sub nodes, so that they can be associated to the respective addressable
> > > range.
> > > The limitation could be exposed when running usecase like concurrent
> > > video sessions. The binding have been validated with higher concurrent
> > > sessions across the SOCs supported under this schema.
> > >
> > > 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>
> > > ---
> > > .../bindings/media/qcom,sm8550-iris.yaml | 66 +++++++++++++++++++++-
> > > 1 file changed, 63 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..bf4d24ce90bd38666704274390b98be450f708c0 100644
> > > --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> > > +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> > > @@ -91,6 +91,51 @@ properties:
> > > opp-table:
> > > type: object
> > > + '#address-cells':
> > > + const: 2
> > > +
> > > + '#size-cells':
> > > + const: 2
> > > +
> > > + non-pixel:
> > > + type: object
> > > + description:
> > > + Non pixel context bank is needed when video hardware have distinct iommus for non pixel
> > > + buffers. Non pixel buffers are compressed and internal buffers.
> > > + properties:
> > > + iommus:
> > > + maxItems: 1
> > > + memory-region:
> > > + maxItems: 1
> > > + required:
> > > + - iommus
> > > + - memory-region
> > > + additionalProperties: false
> > > +
> > > + pixel:
> > > + type: object
> > > + description:
> > > + Pixel context bank is needed when video hardware have distinct iommus for pixel buffers.
> > > + Pixel buffers are uncompressed buffers.
> > > + properties:
> > > + iommus:
> > > + maxItems: 1
> > > + required:
> > > + - iommus
> > > + additionalProperties: false
> > > +
> > > + firmware:
> > > + type: object
> > > + description:
> > > + Firmware context bank represents the firmware processing domain of the VPU. Required to boot
> > > + VPU when no hypervisor is present.
> > > + properties:
> > > + iommus:
> > > + maxItems: 1
> > > + required:
> > > + - iommus
> > > + additionalProperties: false
> > > +
> > > required:
> > > - compatible
> > > - power-domain-names
> > > @@ -98,9 +143,15 @@ required:
> > > - interconnect-names
> > > - resets
> > > - reset-names
> > > - - iommus
> > > - dma-coherent
> > > +oneOf:
> > > + - required:
> > > + - iommus
> > > + - required:
> > > + - non-pixel
> > > + - pixel
> > > +
> > > allOf:
> > > - if:
> > > properties:
> > > @@ -177,12 +228,21 @@ 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 = <2>;
> > > + #size-cells = <2>;
> >
> > I think you need "ranges;" here. Also an empty line before the subnodes.
>
> Could you please elaborate on what would be the use of "ranges;" in this
> case ?
That the subblock has the same address space as the parent. I might be
completely wrong here.
>
> >
> > > + iris_non_pixel: non-pixel {
> >
> > Drop useless labels.
>
> Ack, labels can be dropped from schema.
>
> >
> > > + iommus = <&apps_smmu 0x1940 0x0000>;
> > > + memory-region = <&iris_resv>;
> > > + };
> > > +
> > > + iris_pixel: pixel {
> > > + iommus = <&apps_smmu 0x1947 0x0000>;
> > > + };
> > > +
> > > iris_opp_table: opp-table {
> > > compatible = "operating-points-v2";
> > >
> > > --
> > > 2.34.1
> > >
> >
>
> Regards,
> Vikash
>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes
2026-07-10 15:53 ` Dmitry Baryshkov
@ 2026-07-11 5:46 ` Vikash Garodia
0 siblings, 0 replies; 30+ messages in thread
From: Vikash Garodia @ 2026-07-11 5:46 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-media,
linux-arm-msm, devicetree, linux-kernel, Vishnu Reddy
On 7/10/2026 9:23 PM, Dmitry Baryshkov wrote:
> On Fri, Jul 10, 2026 at 11:32:20AM +0530, Vikash Garodia wrote:
>>
>> On 7/9/2026 6:20 PM, Dmitry Baryshkov wrote:
>>> On Thu, Jul 09, 2026 at 06:05:47PM +0530, Vikash Garodia wrote:
>>>> VPU hardwares have a limitation where VPU streams are associated with
>>>> dedicated addressable address range, as illustrated below
>>>>
>>>> +-----------------------------------------------------------+
>>>> | Stream A reserved region (600 MB) |
>>>> | 0x00000000 - 0x25800000 |
>>>> +-----------------------------------------------------------+
>>>> | Stream B reserved region (3.5 GB) |
>>>> | 0x00000000 - 0xe0000000 |
>>>> +-----------------------------------------------------------+
>>>> | Other reserved regions |
>>>> +-----------------------------------------------------------+
>>>>
>>>> Mapping a stream outside its expected range can cause unintended
>>>> behavior, including device crashes, as reported at:
>>>> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>>>>
>>>> To address this limitation, the subset of stream/s are now represented as
>>>> sub nodes, so that they can be associated to the respective addressable
>>>> range.
>>>> The limitation could be exposed when running usecase like concurrent
>>>> video sessions. The binding have been validated with higher concurrent
>>>> sessions across the SOCs supported under this schema.
>>>>
>>>> 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>
>>>> ---
>>>> .../bindings/media/qcom,sm8550-iris.yaml | 66 +++++++++++++++++++++-
>>>> 1 file changed, 63 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..bf4d24ce90bd38666704274390b98be450f708c0 100644
>>>> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>>>> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>>>> @@ -91,6 +91,51 @@ properties:
>>>> opp-table:
>>>> type: object
>>>> + '#address-cells':
>>>> + const: 2
>>>> +
>>>> + '#size-cells':
>>>> + const: 2
>>>> +
>>>> + non-pixel:
>>>> + type: object
>>>> + description:
>>>> + Non pixel context bank is needed when video hardware have distinct iommus for non pixel
>>>> + buffers. Non pixel buffers are compressed and internal buffers.
>>>> + properties:
>>>> + iommus:
>>>> + maxItems: 1
>>>> + memory-region:
>>>> + maxItems: 1
>>>> + required:
>>>> + - iommus
>>>> + - memory-region
>>>> + additionalProperties: false
>>>> +
>>>> + pixel:
>>>> + type: object
>>>> + description:
>>>> + Pixel context bank is needed when video hardware have distinct iommus for pixel buffers.
>>>> + Pixel buffers are uncompressed buffers.
>>>> + properties:
>>>> + iommus:
>>>> + maxItems: 1
>>>> + required:
>>>> + - iommus
>>>> + additionalProperties: false
>>>> +
>>>> + firmware:
>>>> + type: object
>>>> + description:
>>>> + Firmware context bank represents the firmware processing domain of the VPU. Required to boot
>>>> + VPU when no hypervisor is present.
>>>> + properties:
>>>> + iommus:
>>>> + maxItems: 1
>>>> + required:
>>>> + - iommus
>>>> + additionalProperties: false
>>>> +
>>>> required:
>>>> - compatible
>>>> - power-domain-names
>>>> @@ -98,9 +143,15 @@ required:
>>>> - interconnect-names
>>>> - resets
>>>> - reset-names
>>>> - - iommus
>>>> - dma-coherent
>>>> +oneOf:
>>>> + - required:
>>>> + - iommus
>>>> + - required:
>>>> + - non-pixel
>>>> + - pixel
>>>> +
>>>> allOf:
>>>> - if:
>>>> properties:
>>>> @@ -177,12 +228,21 @@ 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 = <2>;
>>>> + #size-cells = <2>;
>>>
>>> I think you need "ranges;" here. Also an empty line before the subnodes.
>>
>> Could you please elaborate on what would be the use of "ranges;" in this
>> case ?
>
> That the subblock has the same address space as the parent. I might be
> completely wrong here.
Yes, i explored with the same definition of "ranges", but could not see
a use of it in our case. I am dropping this for now, unless there are
suggestion on this on applicability of it in this case.
>
>>
>>>
>>>> + iris_non_pixel: non-pixel {
>>>
>>> Drop useless labels.
>>
>> Ack, labels can be dropped from schema.
>>
>>>
>>>> + iommus = <&apps_smmu 0x1940 0x0000>;
>>>> + memory-region = <&iris_resv>;
>>>> + };
>>>> +
>>>> + iris_pixel: pixel {
>>>> + iommus = <&apps_smmu 0x1947 0x0000>;
>>>> + };
>>>> +
>>>> iris_opp_table: opp-table {
>>>> compatible = "operating-points-v2";
>>>>
>>>> --
>>>> 2.34.1
>>>>
>>>
>>
>> Regards,
>> Vikash
>>
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes
2026-07-09 12:35 ` [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu " Vikash Garodia
2026-07-09 12:50 ` Dmitry Baryshkov
@ 2026-07-10 22:02 ` Bryan O'Donoghue
1 sibling, 0 replies; 30+ messages in thread
From: Bryan O'Donoghue @ 2026-07-10 22:02 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vishnu Reddy
On 09/07/2026 13:35, Vikash Garodia wrote:
> VPU hardwares have a limitation where VPU streams are associated with
VPU hardware has
> dedicated addressable address range, as illustrated below
>
> +-----------------------------------------------------------+
> | Stream A reserved region (600 MB) |
> | 0x00000000 - 0x25800000 |
> +-----------------------------------------------------------+
> | Stream B reserved region (3.5 GB) |
> | 0x00000000 - 0xe0000000 |
> +-----------------------------------------------------------+
> | Other reserved regions |
> +-----------------------------------------------------------+
>
> Mapping a stream outside its expected range can cause unintended
> behavior, including device crashes, as reported at:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> To address this limitation, the subset of stream/s are now represented as
To address this bug surely - to me this is a bugfix we are introducing a
change to stop a crash that leads to a hard reset. Its not a limitation
its a bug.
> sub nodes, so that they can be associated to the respective addressable
> range.
> The limitation could be exposed when running usecase like concurrent
> video sessions.
"The bug is readily reproduced when running concurrent video sessions"
The binding have been validated with higher concurrent
> sessions across the SOCs supported under this schema.
The bindings have been
or
The binding has been
>
> 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>
> ---
> .../bindings/media/qcom,sm8550-iris.yaml | 66 +++++++++++++++++++++-
> 1 file changed, 63 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..bf4d24ce90bd38666704274390b98be450f708c0 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> @@ -91,6 +91,51 @@ properties:
> opp-table:
> type: object
>
> + '#address-cells':
> + const: 2
> +
> + '#size-cells':
> + const: 2
> +
> + non-pixel:
> + type: object
> + description:
> + Non pixel context bank is needed when video hardware have distinct iommus for non pixel
> + buffers. Non pixel buffers are compressed and internal buffers.
Don't describe when it is needed - describe what it is and what it does.
> + properties:
> + iommus:
> + maxItems: 1
> + memory-region:
> + maxItems: 1
> + required:
> + - iommus
> + - memory-region
> + additionalProperties: false
> +
> + pixel:
> + type: object
> + description:
> + Pixel context bank is needed when video hardware have distinct iommus for pixel buffers.
> + Pixel buffers are uncompressed buffers.
Same comment on the necessity of the binding. You're in "justification"
space here but should be in "information" space i.e. inform the reader
what as opposed to justify to the reviewer why, which is how these two
descriptions read.
> + properties:
> + iommus:
> + maxItems: 1
> + required:
> + - iommus
> + additionalProperties: false
> +
> + firmware:
> + type: object
> + description:
> + Firmware context bank represents the firmware processing domain of the VPU. Required to boot
> + VPU when no hypervisor is present.
Yes, this is information not justification.
> + properties:
> + iommus:
> + maxItems: 1
> + required:
> + - iommus
> + additionalProperties: false
> +
> required:
> - compatible
> - power-domain-names
> @@ -98,9 +143,15 @@ required:
> - interconnect-names
> - resets
> - reset-names
> - - iommus
> - dma-coherent
>
> +oneOf:
> + - required:
> + - iommus
> + - required:
> + - non-pixel
> + - pixel
> +
> allOf:
> - if:
> properties:
> @@ -177,12 +228,21 @@ 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 = <2>;
> + #size-cells = <2>;
> + iris_non_pixel: non-pixel {
> + iommus = <&apps_smmu 0x1940 0x0000>;
> + memory-region = <&iris_resv>;
> + };
> +
> + iris_pixel: pixel {
> + iommus = <&apps_smmu 0x1947 0x0000>;
> + };
> +
> iris_opp_table: opp-table {
> compatible = "operating-points-v2";
>
>
> --
> 2.34.1
>
Personally I think this describes a real system behaviour - the question
is, is it a fixed behaviour - i.e. we _always_ expect to see firmware
operate this way - if so it should be represented in DT, if not it
should be represented in a platform descriptor in the driver.
The SIDs are fixed and mean specific things.
It would be possible to encode the SIDs in platform code but, that would
be unusual.
I think this is a good solution TBH.
---
bod
^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 02/11] media: iris: Add hooks to initialize and tear down context banks
2026-07-09 12:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Vikash Garodia
2026-07-09 12:35 ` [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu " Vikash Garodia
@ 2026-07-09 12:35 ` Vikash Garodia
2026-07-09 12:35 ` [RFC PATCH 03/11] media: iris: Add helper to create a context bank device Vikash Garodia
` (9 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Vikash Garodia @ 2026-07-09 12:35 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vikash Garodia, Vishnu Reddy
Add platform hooks to set up and tear down context bank devices.
Different Iris platforms may require different context bank setup, so
let platform data provide the required operations.
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>
---
.../platform/qcom/iris/iris_platform_common.h | 6 ++++++
drivers/media/platform/qcom/iris/iris_probe.c | 24 +++++++++++++++++++++-
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
index c9256f2323dc4521f9eacaeffb0fc08a180de3ff..0d738005fbc3bc0f675165aea0bcf09943441a5d 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_common.h
+++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
@@ -288,6 +288,11 @@ struct iris_firmware_desc {
const char *fwname;
};
+struct iris_context_bank_ops {
+ int (*init)(struct iris_core *core);
+ void (*deinit)(struct iris_core *core);
+};
+
struct iris_platform_data {
/*
* XXX: replace with gen1 / gen2 pointers once we have platforms
@@ -295,6 +300,7 @@ struct iris_platform_data {
*/
const struct iris_firmware_desc *firmware_desc;
+ const struct iris_context_bank_ops *cb_ops;
const struct vpu_ops *vpu_ops;
const struct icc_info *icc_tbl;
unsigned int icc_tbl_size;
diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
index c2dcb50a27824d45d5fbc8b9e22591decbe2a23b..0bce4fb1786bc9371074cb72e082219ded4840e5 100644
--- a/drivers/media/platform/qcom/iris/iris_probe.c
+++ b/drivers/media/platform/qcom/iris/iris_probe.c
@@ -150,6 +150,20 @@ static int iris_init_resources(struct iris_core *core)
return iris_init_resets(core);
}
+static int iris_init_cb_devs(struct iris_core *core)
+{
+ if (core->iris_platform_data->cb_ops)
+ return core->iris_platform_data->cb_ops->init(core);
+
+ return 0;
+}
+
+static void iris_deinit_cb_devs(struct iris_core *core)
+{
+ if (core->iris_platform_data->cb_ops)
+ core->iris_platform_data->cb_ops->deinit(core);
+}
+
static int iris_register_video_device(struct iris_core *core, enum domain_type type)
{
struct video_device *vdev;
@@ -207,6 +221,8 @@ static void iris_remove(struct platform_device *pdev)
v4l2_device_unregister(&core->v4l2_dev);
+ iris_deinit_cb_devs(core);
+
mutex_destroy(&core->lock);
}
@@ -273,10 +289,14 @@ static int iris_probe(struct platform_device *pdev)
iris_session_init_caps(core);
- 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;
@@ -310,6 +330,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] 30+ messages in thread* [RFC PATCH 03/11] media: iris: Add helper to create a context bank device
2026-07-09 12:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Vikash Garodia
2026-07-09 12:35 ` [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu " Vikash Garodia
2026-07-09 12:35 ` [RFC PATCH 02/11] media: iris: Add hooks to initialize and tear down context banks Vikash Garodia
@ 2026-07-09 12:35 ` Vikash Garodia
2026-07-09 12:35 ` [RFC PATCH 04/11] media: iris: Add helper to select relevant " Vikash Garodia
` (8 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Vikash Garodia @ 2026-07-09 12:35 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vikash Garodia, Vishnu Reddy
The subnode in the device tree is registered as a separate device so
that it gets its own IOMMU context. Pixel/non-pixel buffers are mapped
into these iommu domain, to ensure they are within the addressable range.
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_resources.c | 23 +++++++++++++++++++++++
drivers/media/platform/qcom/iris/iris_resources.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/media/platform/qcom/iris/iris_resources.c b/drivers/media/platform/qcom/iris/iris_resources.c
index 773f6548370a257b8ae7332242544266cbbd61a9..f550d194edf58abf0687a4f5df6d06b2af35147d 100644
--- a/drivers/media/platform/qcom/iris/iris_resources.c
+++ b/drivers/media/platform/qcom/iris/iris_resources.c
@@ -141,3 +141,26 @@ int iris_disable_unprepare_clock(struct iris_core *core, enum platform_clk_type
return 0;
}
+
+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.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);
+
+ return &pdev->dev;
+}
diff --git a/drivers/media/platform/qcom/iris/iris_resources.h b/drivers/media/platform/qcom/iris/iris_resources.h
index 6bfbd2dc6db095ec05e53c894e048285f82446c6..ca53c01f60aef2040002f526b8f1b6a9094d1518 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_create_cb_dev(struct iris_core *core, const char *name);
#endif
--
2.34.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* [RFC PATCH 04/11] media: iris: Add helper to select relevant context bank device
2026-07-09 12:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (2 preceding siblings ...)
2026-07-09 12:35 ` [RFC PATCH 03/11] media: iris: Add helper to create a context bank device Vikash Garodia
@ 2026-07-09 12:35 ` Vikash Garodia
2026-07-09 12:35 ` [RFC PATCH 05/11] media: iris: Skip DMA mask setting to core device when IOMMU is not mapped Vikash Garodia
` (7 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Vikash Garodia @ 2026-07-09 12:35 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vikash Garodia, Vishnu Reddy
Associate the context bank device with the respective buffers. Fall back
to core->dev when the platform still describes the IOMMU on the parent
iris node instead of using subnodes. Those platforms would be migrated
gradually.
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_core.h | 4 +++
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 +--
6 files changed, 61 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/qcom/iris/iris_buffer.c b/drivers/media/platform/qcom/iris/iris_buffer.c
index 246ad0abbac3510113e1f760406c81b1461377a3..249c9f1d0d5dadb391f269e9aee5181fe408cd3b 100644
--- a/drivers/media/platform/qcom/iris/iris_buffer.c
+++ b/drivers/media/platform/qcom/iris/iris_buffer.c
@@ -529,7 +529,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)
@@ -545,7 +545,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);
@@ -682,10 +682,10 @@ int iris_queue_internal_buffers(struct iris_inst *inst, u32 plane)
int 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_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_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 f550d194edf58abf0687a4f5df6d06b2af35147d..884715c8c841623f6803ac3d493c9a20520d5087 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
@@ -164,3 +165,43 @@ struct device *iris_create_cb_dev(struct iris_core *core, const char *name)
return &pdev->dev;
}
+
+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 ca53c01f60aef2040002f526b8f1b6a9094d1518..2eef0676a146f1836fc7445a715e43185c645099 100644
--- a/drivers/media/platform/qcom/iris/iris_resources.h
+++ b/drivers/media/platform/qcom/iris/iris_resources.h
@@ -16,5 +16,6 @@ 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_create_cb_dev(struct iris_core *core, const char *name);
+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 14d63dc76c9bacbed3533147cd5325410f9c94bd..26df872fb4fa1cc6b2aacebb7453256864b1462a 100644
--- a/drivers/media/platform/qcom/iris/iris_vidc.c
+++ b/drivers/media/platform/qcom/iris/iris_vidc.c
@@ -107,7 +107,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)
@@ -121,7 +121,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] 30+ messages in thread* [RFC PATCH 05/11] media: iris: Skip DMA mask setting to core device when IOMMU is not mapped
2026-07-09 12:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (3 preceding siblings ...)
2026-07-09 12:35 ` [RFC PATCH 04/11] media: iris: Add helper to select relevant " Vikash Garodia
@ 2026-07-09 12:35 ` Vikash Garodia
2026-07-09 13:10 ` Dmitry Baryshkov
2026-07-09 12:35 ` [RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks Vikash Garodia
` (6 subsequent siblings)
11 siblings, 1 reply; 30+ messages in thread
From: Vikash Garodia @ 2026-07-09 12:35 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vikash Garodia, Vishnu Reddy
The non-pixel and pixel subnodes move the IOMMU streams away from the
iris parent device. As a result, the core device may not have an IOMMU
mapping, and setting its DMA mask is unnecessary.
Legacy platforms that have not migrated to subnodes still associate the
streams with the parent device and still need the DMA mask setup. Call
dma_set_mask_and_coherent() only when an IOMMU is mapped to the iris
core device.
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 0bce4fb1786bc9371074cb72e082219ded4840e5..828e020fc79a7f9c4e8e11c118996f61bcb7715d 100644
--- a/drivers/media/platform/qcom/iris/iris_probe.c
+++ b/drivers/media/platform/qcom/iris/iris_probe.c
@@ -309,9 +309,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] 30+ messages in thread* Re: [RFC PATCH 05/11] media: iris: Skip DMA mask setting to core device when IOMMU is not mapped
2026-07-09 12:35 ` [RFC PATCH 05/11] media: iris: Skip DMA mask setting to core device when IOMMU is not mapped Vikash Garodia
@ 2026-07-09 13:10 ` Dmitry Baryshkov
0 siblings, 0 replies; 30+ messages in thread
From: Dmitry Baryshkov @ 2026-07-09 13:10 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, linux-media,
linux-arm-msm, devicetree, linux-kernel, Vishnu Reddy
On Thu, Jul 09, 2026 at 06:05:51PM +0530, Vikash Garodia wrote:
> The non-pixel and pixel subnodes move the IOMMU streams away from the
> iris parent device. As a result, the core device may not have an IOMMU
> mapping, and setting its DMA mask is unnecessary.
> Legacy platforms that have not migrated to subnodes still associate the
> streams with the parent device and still need the DMA mask setup. Call
> dma_set_mask_and_coherent() only when an IOMMU is mapped to the iris
> core device.
>
> 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(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks
2026-07-09 12:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (4 preceding siblings ...)
2026-07-09 12:35 ` [RFC PATCH 05/11] media: iris: Skip DMA mask setting to core device when IOMMU is not mapped Vikash Garodia
@ 2026-07-09 12:35 ` Vikash Garodia
2026-07-09 13:14 ` Dmitry Baryshkov
2026-07-09 12:35 ` [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes Vikash Garodia
` (5 subsequent siblings)
11 siblings, 1 reply; 30+ messages in thread
From: Vikash Garodia @ 2026-07-09 12:35 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vikash Garodia, Vishnu Reddy
Iris platforms use separate context-bank devices for the pixel and
non-pixel domains. Add platform hooks to create and destroy those
subdevices, and wire them up for the affected platforms.
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/Makefile | 1 +
.../platform/qcom/iris/iris_platform_sm8550.c | 71 ++++++++++++++++++++++
.../platform/qcom/iris/iris_platform_sm8550.h | 24 ++------
.../media/platform/qcom/iris/iris_platform_vpu3x.c | 4 ++
4 files changed, 80 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
index 48e415cbc4390bc596f6239fefa2a2ad2cd3a2bb..fd6bfe7e786be3f8a4885296fb11ba430ded6fd1 100644
--- a/drivers/media/platform/qcom/iris/Makefile
+++ b/drivers/media/platform/qcom/iris/Makefile
@@ -12,6 +12,7 @@ qcom-iris-objs += iris_buffer.o \
iris_hfi_gen2_packet.o \
iris_hfi_gen2_response.o \
iris_hfi_queue.o \
+ iris_platform_sm8550.o \
iris_platform_vpu2.o \
iris_platform_vpu3x.o \
iris_power.o \
diff --git a/drivers/media/platform/qcom/iris/iris_platform_sm8550.c b/drivers/media/platform/qcom/iris/iris_platform_sm8550.c
new file mode 100644
index 0000000000000000000000000000000000000000..bea904a9249bafe1dfa11ff39155d1930402bf7c
--- /dev/null
+++ b/drivers/media/platform/qcom/iris/iris_platform_sm8550.c
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include "iris_core.h"
+#include "iris_platform_common.h"
+#include "iris_platform_sm8550.h"
+
+const char * const sm8550_clk_reset_table[] = { "bus" };
+
+const struct platform_clk_data sm8550_clk_table[] = {
+ {IRIS_AXI_CLK, "iface" },
+ {IRIS_CTRL_CLK, "core" },
+ {IRIS_HW_CLK, "vcodec0_core" },
+};
+
+struct platform_inst_caps platform_inst_cap_sm8550 = {
+ .min_frame_width = 96,
+ .max_frame_width = 8192,
+ .min_frame_height = 96,
+ .max_frame_height = 8192,
+ .max_mbpf = (8192 * 4352) / 256,
+ .mb_cycles_vpp = 200,
+ .mb_cycles_fw = 489583,
+ .mb_cycles_fw_vpp = 66234,
+ .max_frame_rate = MAXIMUM_FPS,
+ .max_operating_rate = MAXIMUM_FPS,
+};
+
+static int sm8550_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 sm8550_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));
+
+ core->p_dev = NULL;
+ core->np_dev = NULL;
+}
+
+const struct iris_context_bank_ops sm8550_cb_ops = {
+ .init = sm8550_init_cb_devs,
+ .deinit = sm8550_deinit_cb_devs,
+};
diff --git a/drivers/media/platform/qcom/iris/iris_platform_sm8550.h b/drivers/media/platform/qcom/iris/iris_platform_sm8550.h
index 3c9dae995bb248f66e200075021b3231b456300a..7205c9e27b1c56acd5a88a861df8eb75517d5a2b 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_sm8550.h
+++ b/drivers/media/platform/qcom/iris/iris_platform_sm8550.h
@@ -6,25 +6,9 @@
#ifndef __IRIS_PLATFORM_SM8550_H__
#define __IRIS_PLATFORM_SM8550_H__
-static const char * const sm8550_clk_reset_table[] = { "bus" };
-
-static const struct platform_clk_data sm8550_clk_table[] = {
- {IRIS_AXI_CLK, "iface" },
- {IRIS_CTRL_CLK, "core" },
- {IRIS_HW_CLK, "vcodec0_core" },
-};
-
-static struct platform_inst_caps platform_inst_cap_sm8550 = {
- .min_frame_width = 96,
- .max_frame_width = 8192,
- .min_frame_height = 96,
- .max_frame_height = 8192,
- .max_mbpf = (8192 * 4352) / 256,
- .mb_cycles_vpp = 200,
- .mb_cycles_fw = 489583,
- .mb_cycles_fw_vpp = 66234,
- .max_frame_rate = MAXIMUM_FPS,
- .max_operating_rate = MAXIMUM_FPS,
-};
+extern const char * const sm8550_clk_reset_table[1];
+extern const struct platform_clk_data sm8550_clk_table[3];
+extern struct platform_inst_caps platform_inst_cap_sm8550;
+extern const struct iris_context_bank_ops sm8550_cb_ops;
#endif
diff --git a/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c b/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
index 2c63adbc55791d5253b14096f9c3ce515f934a4e..68a021c3140eacbf72e63045d39f9b9b8d0e5d97 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
+++ b/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
@@ -91,6 +91,7 @@ static const struct tz_cp_config tz_cp_config_vpu3[] = {
*/
const struct iris_platform_data qcs8300_data = {
.firmware_desc = &iris_vpu30_p4_s6_gen2_desc,
+ .cb_ops = &sm8550_cb_ops,
.vpu_ops = &iris_vpu3_ops,
.icc_tbl = iris_icc_info_vpu3x,
.icc_tbl_size = ARRAY_SIZE(iris_icc_info_vpu3x),
@@ -120,6 +121,7 @@ const struct iris_platform_data qcs8300_data = {
const struct iris_platform_data sm8550_data = {
.firmware_desc = &iris_vpu30_p4_gen2_desc,
+ .cb_ops = &sm8550_cb_ops,
.vpu_ops = &iris_vpu3_ops,
.icc_tbl = iris_icc_info_vpu3x,
.icc_tbl_size = ARRAY_SIZE(iris_icc_info_vpu3x),
@@ -155,6 +157,7 @@ const struct iris_platform_data sm8550_data = {
*/
const struct iris_platform_data sm8650_data = {
.firmware_desc = &iris_vpu33_p4_gen2_desc,
+ .cb_ops = &sm8550_cb_ops,
.vpu_ops = &iris_vpu33_ops,
.icc_tbl = iris_icc_info_vpu3x,
.icc_tbl_size = ARRAY_SIZE(iris_icc_info_vpu3x),
@@ -221,6 +224,7 @@ const struct iris_platform_data sm8750_data = {
*/
const struct iris_platform_data x1p42100_data = {
.firmware_desc = &iris_vpu30_p1_gen2_desc,
+ .cb_ops = &sm8550_cb_ops,
.vpu_ops = &iris_vpu3_ops,
.icc_tbl = iris_icc_info_vpu3x,
.icc_tbl_size = ARRAY_SIZE(iris_icc_info_vpu3x),
--
2.34.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks
2026-07-09 12:35 ` [RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks Vikash Garodia
@ 2026-07-09 13:14 ` Dmitry Baryshkov
2026-07-10 6:32 ` Vikash Garodia
0 siblings, 1 reply; 30+ messages in thread
From: Dmitry Baryshkov @ 2026-07-09 13:14 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, linux-media,
linux-arm-msm, devicetree, linux-kernel, Vishnu Reddy
On Thu, Jul 09, 2026 at 06:05:52PM +0530, Vikash Garodia wrote:
> Iris platforms use separate context-bank devices for the pixel and
> non-pixel domains. Add platform hooks to create and destroy those
> subdevices, and wire them up for the affected platforms.
>
> 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/Makefile | 1 +
> .../platform/qcom/iris/iris_platform_sm8550.c | 71 ++++++++++++++++++++++
> .../platform/qcom/iris/iris_platform_sm8550.h | 24 ++------
> .../media/platform/qcom/iris/iris_platform_vpu3x.c | 4 ++
> 4 files changed, 80 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
> index 48e415cbc4390bc596f6239fefa2a2ad2cd3a2bb..fd6bfe7e786be3f8a4885296fb11ba430ded6fd1 100644
> --- a/drivers/media/platform/qcom/iris/Makefile
> +++ b/drivers/media/platform/qcom/iris/Makefile
> @@ -12,6 +12,7 @@ qcom-iris-objs += iris_buffer.o \
> iris_hfi_gen2_packet.o \
> iris_hfi_gen2_response.o \
> iris_hfi_queue.o \
> + iris_platform_sm8550.o \
No, it's not a separate platform.
> iris_platform_vpu2.o \
> iris_platform_vpu3x.o \
> iris_power.o \
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_sm8550.c b/drivers/media/platform/qcom/iris/iris_platform_sm8550.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..bea904a9249bafe1dfa11ff39155d1930402bf7c
> --- /dev/null
> +++ b/drivers/media/platform/qcom/iris/iris_platform_sm8550.c
> @@ -0,0 +1,71 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include "iris_core.h"
> +#include "iris_platform_common.h"
> +#include "iris_platform_sm8550.h"
> +
> +const char * const sm8550_clk_reset_table[] = { "bus" };
> +
> +const struct platform_clk_data sm8550_clk_table[] = {
> + {IRIS_AXI_CLK, "iface" },
> + {IRIS_CTRL_CLK, "core" },
> + {IRIS_HW_CLK, "vcodec0_core" },
> +};
> +
> +struct platform_inst_caps platform_inst_cap_sm8550 = {
> + .min_frame_width = 96,
> + .max_frame_width = 8192,
> + .min_frame_height = 96,
> + .max_frame_height = 8192,
> + .max_mbpf = (8192 * 4352) / 256,
> + .mb_cycles_vpp = 200,
> + .mb_cycles_fw = 489583,
> + .mb_cycles_fw_vpp = 66234,
> + .max_frame_rate = MAXIMUM_FPS,
> + .max_operating_rate = MAXIMUM_FPS,
> +};
> +
> +static int sm8550_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 sm8550_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));
> +
> + core->p_dev = NULL;
> + core->np_dev = NULL;
> +}
> +
> +const struct iris_context_bank_ops sm8550_cb_ops = {
For a long time I have been asking to fix name prefixes. Now you are
adding one more. No. Please write it as a rule of thumb. All new symbols
in the iris driver should start with iris_.
Moreover, there is nothing sm8550-specific in these hooks. Enable them
for all VPU3.x platforms uniformly.
> + .init = sm8550_init_cb_devs,
> + .deinit = sm8550_deinit_cb_devs,
> +};
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks
2026-07-09 13:14 ` Dmitry Baryshkov
@ 2026-07-10 6:32 ` Vikash Garodia
2026-07-10 16:03 ` Dmitry Baryshkov
0 siblings, 1 reply; 30+ messages in thread
From: Vikash Garodia @ 2026-07-10 6:32 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-media,
linux-arm-msm, devicetree, linux-kernel, Vishnu Reddy
On 7/9/2026 6:44 PM, Dmitry Baryshkov wrote:
> On Thu, Jul 09, 2026 at 06:05:52PM +0530, Vikash Garodia wrote:
>> Iris platforms use separate context-bank devices for the pixel and
>> non-pixel domains. Add platform hooks to create and destroy those
>> subdevices, and wire them up for the affected platforms.
>>
>> 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/Makefile | 1 +
>> .../platform/qcom/iris/iris_platform_sm8550.c | 71 ++++++++++++++++++++++
>> .../platform/qcom/iris/iris_platform_sm8550.h | 24 ++------
>> .../media/platform/qcom/iris/iris_platform_vpu3x.c | 4 ++
>> 4 files changed, 80 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
>> index 48e415cbc4390bc596f6239fefa2a2ad2cd3a2bb..fd6bfe7e786be3f8a4885296fb11ba430ded6fd1 100644
>> --- a/drivers/media/platform/qcom/iris/Makefile
>> +++ b/drivers/media/platform/qcom/iris/Makefile
>> @@ -12,6 +12,7 @@ qcom-iris-objs += iris_buffer.o \
>> iris_hfi_gen2_packet.o \
>> iris_hfi_gen2_response.o \
>> iris_hfi_queue.o \
>> + iris_platform_sm8550.o \
>
> No, it's not a separate platform.
This will be dropped, given that the callback would be made generic for
vpu3x and would be implemented in iris_platform_vpu3x.c
>
>> iris_platform_vpu2.o \
>> iris_platform_vpu3x.o \
>> iris_power.o \
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_sm8550.c b/drivers/media/platform/qcom/iris/iris_platform_sm8550.c
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..bea904a9249bafe1dfa11ff39155d1930402bf7c
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_sm8550.c
>> @@ -0,0 +1,71 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +#include "iris_core.h"
>> +#include "iris_platform_common.h"
>> +#include "iris_platform_sm8550.h"
>> +
>> +const char * const sm8550_clk_reset_table[] = { "bus" };
>> +
>> +const struct platform_clk_data sm8550_clk_table[] = {
>> + {IRIS_AXI_CLK, "iface" },
>> + {IRIS_CTRL_CLK, "core" },
>> + {IRIS_HW_CLK, "vcodec0_core" },
>> +};
>> +
>> +struct platform_inst_caps platform_inst_cap_sm8550 = {
>> + .min_frame_width = 96,
>> + .max_frame_width = 8192,
>> + .min_frame_height = 96,
>> + .max_frame_height = 8192,
>> + .max_mbpf = (8192 * 4352) / 256,
>> + .mb_cycles_vpp = 200,
>> + .mb_cycles_fw = 489583,
>> + .mb_cycles_fw_vpp = 66234,
>> + .max_frame_rate = MAXIMUM_FPS,
>> + .max_operating_rate = MAXIMUM_FPS,
>> +};
>> +
>> +static int sm8550_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 sm8550_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));
>> +
>> + core->p_dev = NULL;
>> + core->np_dev = NULL;
>> +}
>> +
>> +const struct iris_context_bank_ops sm8550_cb_ops = {
>
> For a long time I have been asking to fix name prefixes. Now you are
> adding one more. No. Please write it as a rule of thumb. All new symbols
> in the iris driver should start with iris_.
Ack
>
> Moreover, there is nothing sm8550-specific in these hooks. Enable them
> for all VPU3.x platforms uniformly.
Good observation, will change this something like below;
.cb_ops = &vpu3x_cb_ops,
and the callbacks can be added in iris_platform_vpu3x.c
>
>> + .init = sm8550_init_cb_devs,
>> + .deinit = sm8550_deinit_cb_devs,
>> +};
>
Regards,
Vikash
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks
2026-07-10 6:32 ` Vikash Garodia
@ 2026-07-10 16:03 ` Dmitry Baryshkov
0 siblings, 0 replies; 30+ messages in thread
From: Dmitry Baryshkov @ 2026-07-10 16:03 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, linux-media,
linux-arm-msm, devicetree, linux-kernel, Vishnu Reddy
On Fri, Jul 10, 2026 at 12:02:46PM +0530, Vikash Garodia wrote:
>
>
> On 7/9/2026 6:44 PM, Dmitry Baryshkov wrote:
> > On Thu, Jul 09, 2026 at 06:05:52PM +0530, Vikash Garodia wrote:
> > > Iris platforms use separate context-bank devices for the pixel and
> > > non-pixel domains. Add platform hooks to create and destroy those
> > > subdevices, and wire them up for the affected platforms.
> > >
> > > 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/Makefile | 1 +
> > > .../platform/qcom/iris/iris_platform_sm8550.c | 71 ++++++++++++++++++++++
> > > .../platform/qcom/iris/iris_platform_sm8550.h | 24 ++------
> > > .../media/platform/qcom/iris/iris_platform_vpu3x.c | 4 ++
> > > 4 files changed, 80 insertions(+), 20 deletions(-)
> > >
> > > +const struct iris_context_bank_ops sm8550_cb_ops = {
> >
> > For a long time I have been asking to fix name prefixes. Now you are
> > adding one more. No. Please write it as a rule of thumb. All new symbols
> > in the iris driver should start with iris_.
>
> Ack
>
> >
> > Moreover, there is nothing sm8550-specific in these hooks. Enable them
> > for all VPU3.x platforms uniformly.
>
> Good observation, will change this something like below;
> .cb_ops = &vpu3x_cb_ops,
Please see few lines above, that's a bad name.
Also, is there a reason to introduce a separate struct for those
callbacks? Can we fit them into the existing iris_vpu_ops?
> and the callbacks can be added in iris_platform_vpu3x.c
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes
2026-07-09 12:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (5 preceding siblings ...)
2026-07-09 12:35 ` [RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks Vikash Garodia
@ 2026-07-09 12:35 ` Vikash Garodia
2026-07-09 13:03 ` Dmitry Baryshkov
` (2 more replies)
2026-07-09 12:35 ` [RFC PATCH 08/11] arm64: dts: qcom: sm8550: Move Iris IOMMUs to child nodes Vikash Garodia
` (4 subsequent siblings)
11 siblings, 3 replies; 30+ messages in thread
From: Vikash Garodia @ 2026-07-09 12:35 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vikash Garodia, Vishnu Reddy
The Iris VPU has separate streams with different IOVA constraints. The
non-pixel stream must be limited to the 0-600 MB IOVA range, while the
pixel stream can use the full IOVA space.
Using a single set of IOMMU entries for the Iris node does not describe
these per-stream limits and can allow accesses outside the supported
range, which may lead to device crashes. One such issue was reported at:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Add non-pixel and pixel child nodes, move each stream ID to its
corresponding child node, and add a reserved IOVA range for the
non-pixel stream.
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 | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 60f485a4892e062980d01f0b930af4b02f36513c..a2baa2c9f46dc19c3db11dc784358223a035475f 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -657,6 +657,10 @@ smem_mem: smem@ffe00000 {
hwlocks = <&tcsr_mutex 3>;
no-map;
};
+
+ iris_resv: reservation-iris {
+ iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
+ };
};
qup_opp_table_100mhz: opp-table-qup100mhz {
@@ -5435,10 +5439,11 @@ &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 = <2>;
+ #size-cells = <2>;
+
/*
* IRIS firmware is signed by vendors, only
* enable on boards where the proper signed firmware
@@ -5446,6 +5451,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
*/
status = "disabled";
+ iris_non_pixel: non-pixel {
+ iommus = <&apps_smmu 0x1940 0x0>;
+ memory-region = <&iris_resv>;
+ };
+
+ iris_pixel: pixel {
+ iommus = <&apps_smmu 0x1947 0x0>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes
2026-07-09 12:35 ` [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes Vikash Garodia
@ 2026-07-09 13:03 ` Dmitry Baryshkov
2026-07-10 6:05 ` Vikash Garodia
2026-07-10 10:48 ` Bryan O'Donoghue
2026-07-10 22:46 ` Bryan O'Donoghue
2 siblings, 1 reply; 30+ messages in thread
From: Dmitry Baryshkov @ 2026-07-09 13:03 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, linux-media,
linux-arm-msm, devicetree, linux-kernel, Vishnu Reddy
On Thu, Jul 09, 2026 at 06:05:53PM +0530, Vikash Garodia wrote:
> The Iris VPU has separate streams with different IOVA constraints. The
> non-pixel stream must be limited to the 0-600 MB IOVA range, while the
> pixel stream can use the full IOVA space.
> Using a single set of IOMMU entries for the Iris node does not describe
> these per-stream limits and can allow accesses outside the supported
> range, which may lead to device crashes. One such issue was reported at:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> Add non-pixel and pixel child nodes, move each stream ID to its
> corresponding child node, and add a reserved IOVA range for the
> non-pixel stream.
>
> 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 | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> index 60f485a4892e062980d01f0b930af4b02f36513c..a2baa2c9f46dc19c3db11dc784358223a035475f 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> @@ -657,6 +657,10 @@ smem_mem: smem@ffe00000 {
> hwlocks = <&tcsr_mutex 3>;
> no-map;
> };
> +
> + iris_resv: reservation-iris {
> + iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
> + };
> };
>
> qup_opp_table_100mhz: opp-table-qup100mhz {
> @@ -5435,10 +5439,11 @@ &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 = <2>;
> + #size-cells = <2>;
> +
> /*
> * IRIS firmware is signed by vendors, only
> * enable on boards where the proper signed firmware
> @@ -5446,6 +5451,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
> */
> status = "disabled";
>
> + iris_non_pixel: non-pixel {
> + iommus = <&apps_smmu 0x1940 0x0>;
> + memory-region = <&iris_resv>;
> + };
> +
> + iris_pixel: pixel {
Unused label. Also, shouldn't you specify the IOMMU region for this one
too?
> + iommus = <&apps_smmu 0x1947 0x0>;
> + };
> +
> iris_opp_table: opp-table {
> compatible = "operating-points-v2";
>
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes
2026-07-09 13:03 ` Dmitry Baryshkov
@ 2026-07-10 6:05 ` Vikash Garodia
2026-07-10 21:05 ` Dmitry Baryshkov
0 siblings, 1 reply; 30+ messages in thread
From: Vikash Garodia @ 2026-07-10 6:05 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-media,
linux-arm-msm, devicetree, linux-kernel, Vishnu Reddy
On 7/9/2026 6:33 PM, Dmitry Baryshkov wrote:
> On Thu, Jul 09, 2026 at 06:05:53PM +0530, Vikash Garodia wrote:
>> The Iris VPU has separate streams with different IOVA constraints. The
>> non-pixel stream must be limited to the 0-600 MB IOVA range, while the
>> pixel stream can use the full IOVA space.
>> Using a single set of IOMMU entries for the Iris node does not describe
>> these per-stream limits and can allow accesses outside the supported
>> range, which may lead to device crashes. One such issue was reported at:
>> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>>
>> Add non-pixel and pixel child nodes, move each stream ID to its
>> corresponding child node, and add a reserved IOVA range for the
>> non-pixel stream.
>>
>> 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 | 18 ++++++++++++++++--
>> 1 file changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> index 60f485a4892e062980d01f0b930af4b02f36513c..a2baa2c9f46dc19c3db11dc784358223a035475f 100644
>> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> @@ -657,6 +657,10 @@ smem_mem: smem@ffe00000 {
>> hwlocks = <&tcsr_mutex 3>;
>> no-map;
>> };
>> +
>> + iris_resv: reservation-iris {
>> + iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
>> + };
>> };
>>
>> qup_opp_table_100mhz: opp-table-qup100mhz {
>> @@ -5435,10 +5439,11 @@ &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 = <2>;
>> + #size-cells = <2>;
>> +
>> /*
>> * IRIS firmware is signed by vendors, only
>> * enable on boards where the proper signed firmware
>> @@ -5446,6 +5451,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>> */
>> status = "disabled";
>>
>> + iris_non_pixel: non-pixel {
>> + iommus = <&apps_smmu 0x1940 0x0>;
>> + memory-region = <&iris_resv>;
>> + };
>> +
>> + iris_pixel: pixel {
>
> Unused label.
Kept it for consistency with others, it can be dropped though.
> Also, shouldn't you specify the IOMMU region for this one
> too?
There is no iova restriction for pixel domain, hence region is not
needed there.
>
>> + iommus = <&apps_smmu 0x1947 0x0>;
>> + };
>> +
>> iris_opp_table: opp-table {
>> compatible = "operating-points-v2";
>>
>>
>> --
>> 2.34.1
>>
>
Regards,
Vikash
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes
2026-07-10 6:05 ` Vikash Garodia
@ 2026-07-10 21:05 ` Dmitry Baryshkov
0 siblings, 0 replies; 30+ messages in thread
From: Dmitry Baryshkov @ 2026-07-10 21:05 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, linux-media,
linux-arm-msm, devicetree, linux-kernel, Vishnu Reddy
On Fri, Jul 10, 2026 at 11:35:45AM +0530, Vikash Garodia wrote:
> On 7/9/2026 6:33 PM, Dmitry Baryshkov wrote:
> > On Thu, Jul 09, 2026 at 06:05:53PM +0530, Vikash Garodia wrote:
> > > The Iris VPU has separate streams with different IOVA constraints. The
> > > non-pixel stream must be limited to the 0-600 MB IOVA range, while the
> > > pixel stream can use the full IOVA space.
> > > Using a single set of IOMMU entries for the Iris node does not describe
> > > these per-stream limits and can allow accesses outside the supported
> > > range, which may lead to device crashes. One such issue was reported at:
> > > https://gitlab.freedesktop.org/drm/msm/-/work_items/100
> > >
> > > Add non-pixel and pixel child nodes, move each stream ID to its
> > > corresponding child node, and add a reserved IOVA range for the
> > > non-pixel stream.
> > >
> > > 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 | 18 ++++++++++++++++--
> > > 1 file changed, 16 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > > index 60f485a4892e062980d01f0b930af4b02f36513c..a2baa2c9f46dc19c3db11dc784358223a035475f 100644
> > > --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > > @@ -657,6 +657,10 @@ smem_mem: smem@ffe00000 {
> > > hwlocks = <&tcsr_mutex 3>;
> > > no-map;
> > > };
> > > +
> > > + iris_resv: reservation-iris {
> > > + iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
> > > + };
> > > };
> > > qup_opp_table_100mhz: opp-table-qup100mhz {
> > > @@ -5435,10 +5439,11 @@ &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 = <2>;
> > > + #size-cells = <2>;
> > > +
> > > /*
> > > * IRIS firmware is signed by vendors, only
> > > * enable on boards where the proper signed firmware
> > > @@ -5446,6 +5451,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
> > > */
> > > status = "disabled";
> > > + iris_non_pixel: non-pixel {
> > > + iommus = <&apps_smmu 0x1940 0x0>;
> > > + memory-region = <&iris_resv>;
> > > + };
> > > +
> > > + iris_pixel: pixel {
> >
> > Unused label.
>
> Kept it for consistency with others, it can be dropped though.
Consistency would be to have only the useful labels.
> > Also, shouldn't you specify the IOMMU region for this one
> > too?
>
> There is no iova restriction for pixel domain, hence region is not needed
> there.
Ok. I was under impression that SIDs are generated based on the address.
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes
2026-07-09 12:35 ` [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes Vikash Garodia
2026-07-09 13:03 ` Dmitry Baryshkov
@ 2026-07-10 10:48 ` Bryan O'Donoghue
2026-07-10 22:46 ` Bryan O'Donoghue
2 siblings, 0 replies; 30+ messages in thread
From: Bryan O'Donoghue @ 2026-07-10 10:48 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vishnu Reddy
On 09/07/2026 13:35, Vikash Garodia wrote:
> The Iris VPU has separate streams with different IOVA constraints. The
> non-pixel stream must be limited to the 0-600 MB IOVA range, while the
> pixel stream can use the full IOVA space.
> Using a single set of IOMMU entries for the Iris node does not describe
> these per-stream limits and can allow accesses outside the supported
> range, which may lead to device crashes. One such issue was reported at:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> Add non-pixel and pixel child nodes, move each stream ID to its
> corresponding child node, and add a reserved IOVA range for the
> non-pixel stream.
>
> 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>
In light of this patch, we should put a pause on Daniel's workaround.
---
bod
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes
2026-07-09 12:35 ` [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes Vikash Garodia
2026-07-09 13:03 ` Dmitry Baryshkov
2026-07-10 10:48 ` Bryan O'Donoghue
@ 2026-07-10 22:46 ` Bryan O'Donoghue
2 siblings, 0 replies; 30+ messages in thread
From: Bryan O'Donoghue @ 2026-07-10 22:46 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vishnu Reddy
On 09/07/2026 13:35, Vikash Garodia wrote:
> The Iris VPU has separate streams with different IOVA constraints. The
> non-pixel stream must be limited to the 0-600 MB IOVA range, while the
> pixel stream can use the full IOVA space.
> Using a single set of IOMMU entries for the Iris node does not describe
> these per-stream limits and can allow accesses outside the supported
> range, which may lead to device crashes. One such issue was reported at:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> Add non-pixel and pixel child nodes, move each stream ID to its
> corresponding child node, and add a reserved IOVA range for the
> non-pixel stream.
>
> 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>
The thing of it is, this _is_ a bugfix - perhaps its not one that can be
backported, actually scratch that, this isn't possible to land in
-stable realistically.
So what is needed here is a strategy for fixing -stable.
That could be apply Daniel's patch and backport it with Fixes: - with
mainline then say applying this change and reverting Daniel's patch
or
That could mean some other solution for -stable - up for debate - what's
not up for debate is this series needs to _address_ what happens to
stable for all of the target platforms - and then transition mainline to
the new and shiny way.
That could mean
- Applying Daniel's fix with Fixes: and cc-stable
- That patch needs to be extended to _each_ Iris platform containing
this bug... all of them I think.
- Updating bindings
- Updating DT with new method simultaneously reverting Daniel's fix
And I do mean doing that in one progressive series - a fixup for
mainline alone isn't enough.
So we backport a fix from mainline and then make mainline better still.
Or whatever something like that.
Either way just fixing in mainline is not good enough for each of the
targeted upstream DTS we need a solution for -stable too, keeping in
mind new kernels need to work with old bindings.
---
bod
^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 08/11] arm64: dts: qcom: sm8550: Move Iris IOMMUs to child nodes
2026-07-09 12:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (6 preceding siblings ...)
2026-07-09 12:35 ` [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes Vikash Garodia
@ 2026-07-09 12:35 ` Vikash Garodia
2026-07-09 12:35 ` [RFC PATCH 09/11] arm64: dts: qcom: lemans: " Vikash Garodia
` (3 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Vikash Garodia @ 2026-07-09 12:35 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vikash Garodia, Vishnu Reddy
The Iris VPU has separate streams with different IOVA constraints. The
non-pixel stream must be limited to the 0-600 MB IOVA range, while the
pixel stream can use the full IOVA space.
Using a single set of IOMMU entries for the Iris node does not describe
these per-stream limits and can allow accesses outside the supported
range, which may lead to device crashes. One such issue was reported at:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Add non-pixel and pixel child nodes, move each stream ID to its
corresponding child node, and add a reserved IOVA range for the
non-pixel stream.
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/qcs8550.dtsi | 4 ++++
arch/arm64/boot/dts/qcom/sm8550.dtsi | 18 ++++++++++++++++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs8550.dtsi b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
index f0acdd0b1e9384e684a90f7f49cf63633cd70d53..db0f539bc3d0a2e83b58b3929a05f0e44d9d513f 100644
--- a/arch/arm64/boot/dts/qcom/qcs8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
@@ -158,5 +158,9 @@ mpss_dsm_mem: mpss-dsm-region@d4d00000 {
reg = <0x0 0xd4d00000 0x0 0x3300000>;
no-map;
};
+
+ iris_resv: reservation-iris {
+ iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
+ };
};
};
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 83136efb7724c3d74f9f377b1c8291d7378ac4a8..347d4a03b1ba419a2856a7c8ae98d6b26e90ad6b 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -1087,6 +1087,10 @@ hyp_ext_reserved_mem: hyp-ext-reserved-region@ff700000 {
reg = <0 0xff700000 0 0x100000>;
no-map;
};
+
+ iris_resv: reservation-iris {
+ iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
+ };
};
smp2p-adsp {
@@ -3690,10 +3694,11 @@ &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 = <2>;
+ #size-cells = <2>;
+
/*
* IRIS firmware is signed by vendors, only
* enable on boards where the proper signed firmware
@@ -3701,6 +3706,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
*/
status = "disabled";
+ iris_non_pixel: non-pixel {
+ iommus = <&apps_smmu 0x1940 0x0>;
+ memory-region = <&iris_resv>;
+ };
+
+ iris_pixel: pixel {
+ iommus = <&apps_smmu 0x1947 0x0>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* [RFC PATCH 09/11] arm64: dts: qcom: lemans: Move Iris IOMMUs to child nodes
2026-07-09 12:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (7 preceding siblings ...)
2026-07-09 12:35 ` [RFC PATCH 08/11] arm64: dts: qcom: sm8550: Move Iris IOMMUs to child nodes Vikash Garodia
@ 2026-07-09 12:35 ` Vikash Garodia
2026-07-09 12:35 ` [RFC PATCH 10/11] arm64: dts: qcom: monaco: " Vikash Garodia
` (2 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Vikash Garodia @ 2026-07-09 12:35 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vikash Garodia, Vishnu Reddy
The Iris VPU has separate streams with different IOVA constraints. The
non-pixel stream must be limited to the 0-600 MB IOVA range, while the
pixel stream can use the full IOVA space.
Using a single set of IOMMU entries for the Iris node does not describe
these per-stream limits and can allow accesses outside the supported
range, which may lead to device crashes. One such issue was reported at:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Add non-pixel and pixel child nodes, move each stream ID to its
corresponding child node, and add a reserved IOVA range for the
non-pixel stream.
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 | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index a10322c5bc35754042640d56ecb556a5ed5cf281..90c300461b5029b4084b8b28130cd826155e4cbb 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -879,6 +879,10 @@ cpucp_fw_mem: cpucp-fw@db200000 {
reg = <0x0 0xdb200000 0x0 0x100000>;
no-map;
};
+
+ iris_resv: reservation-iris {
+ iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
+ };
};
smp2p-adsp {
@@ -4978,12 +4982,22 @@ &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 = <2>;
+ #size-cells = <2>;
+
status = "disabled";
+ iris_non_pixel: non-pixel {
+ iommus = <&apps_smmu 0x0880 0x0400>;
+ memory-region = <&iris_resv>;
+ };
+
+ iris_pixel: pixel {
+ iommus = <&apps_smmu 0x0887 0x0400>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* [RFC PATCH 10/11] arm64: dts: qcom: monaco: Move Iris IOMMUs to child nodes
2026-07-09 12:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (8 preceding siblings ...)
2026-07-09 12:35 ` [RFC PATCH 09/11] arm64: dts: qcom: lemans: " Vikash Garodia
@ 2026-07-09 12:35 ` Vikash Garodia
2026-07-09 12:35 ` [RFC PATCH 11/11] arm64: dts: qcom: sm8650: " Vikash Garodia
2026-07-10 10:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Bryan O'Donoghue
11 siblings, 0 replies; 30+ messages in thread
From: Vikash Garodia @ 2026-07-09 12:35 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vikash Garodia, Vishnu Reddy
The Iris VPU has separate streams with different IOVA constraints. The
non-pixel stream must be limited to the 0-600 MB IOVA range, while the
pixel stream can use the full IOVA space.
Using a single set of IOMMU entries for the Iris node does not describe
these per-stream limits and can allow accesses outside the supported
range, which may lead to device crashes. One such issue was reported at:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Add non-pixel and pixel child nodes, move each stream ID to its
corresponding child node, and add a reserved IOVA range for the
non-pixel stream.
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 | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index e0243901abe9c5748fcd3c448a0203374fb96c3e..d3c464571d5eee18fccb0e6b522ff0400e664cc4 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -831,6 +831,10 @@ video_mem: video-region@9be82000 {
reg = <0x0 0x9be82000 0x0 0x700000>;
no-map;
};
+
+ iris_resv: reservation-iris {
+ iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
+ };
};
smp2p-adsp {
@@ -5423,12 +5427,22 @@ &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 = <2>;
+ #size-cells = <2>;
+
status = "disabled";
+ iris_non_pixel: non-pixel {
+ iommus = <&apps_smmu 0x0880 0x0400>;
+ memory-region = <&iris_resv>;
+ };
+
+ iris_pixel: pixel {
+ iommus = <&apps_smmu 0x0887 0x0400>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* [RFC PATCH 11/11] arm64: dts: qcom: sm8650: Move Iris IOMMUs to child nodes
2026-07-09 12:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (9 preceding siblings ...)
2026-07-09 12:35 ` [RFC PATCH 10/11] arm64: dts: qcom: monaco: " Vikash Garodia
@ 2026-07-09 12:35 ` Vikash Garodia
2026-07-10 10:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Bryan O'Donoghue
11 siblings, 0 replies; 30+ messages in thread
From: Vikash Garodia @ 2026-07-09 12:35 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vikash Garodia, Vishnu Reddy
The Iris VPU has separate streams with different IOVA constraints. The
non-pixel stream must be limited to the 0-600 MB IOVA range, while the
pixel stream can use the full IOVA space.
Using a single set of IOMMU entries for the Iris node does not describe
these per-stream limits and can allow accesses outside the supported
range, which may lead to device crashes. One such issue was reported at:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100
Add non-pixel and pixel child nodes, move each stream ID to its
corresponding child node, and add a reserved IOVA range for the
non-pixel stream.
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 | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index 447b788fcbb96efc8b26a52a0606bc53dd29adfb..f9c03de1317f1c6a8e52bd897997ef7bd826926b 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -1849,6 +1849,10 @@ llcc_lpi_mem: llcc-lpi@ff800000 {
reg = <0 0xff800000 0 0x600000>;
no-map;
};
+
+ iris_resv: reservation-iris {
+ iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
+ };
};
smp2p-adsp {
@@ -5219,11 +5223,11 @@ &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 = <2>;
+ #size-cells = <2>;
+
/*
* IRIS firmware is signed by vendors, only
* enable on boards where the proper signed firmware
@@ -5231,6 +5235,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
*/
status = "disabled";
+ iris_non_pixel: non-pixel {
+ iommus = <&apps_smmu 0x1940 0x0>;
+ memory-region = <&iris_resv>;
+ };
+
+ iris_pixel: pixel {
+ iommus = <&apps_smmu 0x1947 0x0>;
+ };
+
iris_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.34.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes
2026-07-09 12:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Vikash Garodia
` (10 preceding siblings ...)
2026-07-09 12:35 ` [RFC PATCH 11/11] arm64: dts: qcom: sm8650: " Vikash Garodia
@ 2026-07-10 10:35 ` Bryan O'Donoghue
2026-07-10 13:36 ` Vikash Garodia
11 siblings, 1 reply; 30+ messages in thread
From: Bryan O'Donoghue @ 2026-07-10 10:35 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vishnu Reddy
On 09/07/2026 13:35, Vikash Garodia wrote:
> Mapping a stream outside its expected range can cause unintended
> behavior, including device crashes, as reported at:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>
> Daniel, who reported the crash issue, have also raised a patch to workaround
> the issue. While the patch partially handles the limitation, it is inefficient
> in a way that it keep iris hardwares away from using the 600MB address space
> for all the different streams.
>
> To address this limitation, the subset of stream/s are now represented as
> sub nodes, so that they can be associated to the respective addressable
> range.
> In the past, this limitation was tried with iommu-map approach, with iris
> driver dynamically creating the devices. The approach was later concluded
> as an hack to avoid having sub nodes. It was discussed in detail in the
> discussionhttps://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
>
> It was agreed by maintainers to proceed with sub node approach to address
> the VPU hardware limitation.
What's the addressable range with sub-nodes ?
The original problem you were trying to solve was the total addressable
size - this other problem here segmenting the linear allocation space is
adjacent but not the same thing.
Without digging through all of the patches here - my question is does
the original sub-node addressable space problem get resolved in your
proposal here ?
---
bod
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes
2026-07-10 10:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Bryan O'Donoghue
@ 2026-07-10 13:36 ` Vikash Garodia
2026-07-10 13:38 ` Bryan O'Donoghue
0 siblings, 1 reply; 30+ messages in thread
From: Vikash Garodia @ 2026-07-10 13:36 UTC (permalink / raw)
To: Bryan O'Donoghue, Dikshita Agarwal, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vishnu Reddy
On 7/10/2026 4:05 PM, Bryan O'Donoghue wrote:
> On 09/07/2026 13:35, Vikash Garodia wrote:
>> Mapping a stream outside its expected range can cause unintended
>> behavior, including device crashes, as reported at:
>> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>>
>> Daniel, who reported the crash issue, have also raised a patch to
>> workaround
>> the issue. While the patch partially handles the limitation, it is
>> inefficient
>> in a way that it keep iris hardwares away from using the 600MB address
>> space
>> for all the different streams.
>>
>> To address this limitation, the subset of stream/s are now represented as
>> sub nodes, so that they can be associated to the respective addressable
>> range.
>> In the past, this limitation was tried with iommu-map approach, with iris
>> driver dynamically creating the devices. The approach was later concluded
>> as an hack to avoid having sub nodes. It was discussed in detail in the
>> discussionhttps://lore.kernel.org/all/c7b956a9-d3e8-4e18-
>> b780-5d08f5cd2ca1@kernel.org/
>>
>> It was agreed by maintainers to proceed with sub node approach to address
>> the VPU hardware limitation.
>
> What's the addressable range with sub-nodes ?
>
> The original problem you were trying to solve was the total addressable
> size - this other problem here segmenting the linear allocation space is
> adjacent but not the same thing.
>
> Without digging through all of the patches here - my question is does
> the original sub-node addressable space problem get resolved in your
> proposal here ?
The proposal solves both the problem we have so far - total addressable
size as well as which segment (or range) in that is _not_ addressable.
Regards,
Vikash
>
> ---
> bod
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes
2026-07-10 13:36 ` Vikash Garodia
@ 2026-07-10 13:38 ` Bryan O'Donoghue
2026-07-10 14:02 ` Vikash Garodia
0 siblings, 1 reply; 30+ messages in thread
From: Bryan O'Donoghue @ 2026-07-10 13:38 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vishnu Reddy
On 10/07/2026 14:36, Vikash Garodia wrote:
>> What's the addressable range with sub-nodes ?
>>
>> The original problem you were trying to solve was the total addressable
>> size - this other problem here segmenting the linear allocation space is
>> adjacent but not the same thing.
>>
>> Without digging through all of the patches here - my question is does
>> the original sub-node addressable space problem get resolved in your
>> proposal here ?
> The proposal solves both the problem we have so far - total addressable
> size as well as which segment (or range) in that is_not_ addressable.
So if I can distill this.
You're proposing two objects in the DT one for each relevant IOMMU SID
and then the driver will register two different devices to get the full
range addresses ?
---
bod
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes
2026-07-10 13:38 ` Bryan O'Donoghue
@ 2026-07-10 14:02 ` Vikash Garodia
0 siblings, 0 replies; 30+ messages in thread
From: Vikash Garodia @ 2026-07-10 14:02 UTC (permalink / raw)
To: Bryan O'Donoghue, Dikshita Agarwal, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Vishnu Reddy
On 7/10/2026 7:08 PM, Bryan O'Donoghue wrote:
> On 10/07/2026 14:36, Vikash Garodia wrote:
>>> What's the addressable range with sub-nodes ?
>>>
>>> The original problem you were trying to solve was the total addressable
>>> size - this other problem here segmenting the linear allocation space is
>>> adjacent but not the same thing.
>>>
>>> Without digging through all of the patches here - my question is does
>>> the original sub-node addressable space problem get resolved in your
>>> proposal here ?
>> The proposal solves both the problem we have so far - total addressable
>> size as well as which segment (or range) in that is_not_ addressable.
>
> So if I can distill this.
>
> You're proposing two objects in the DT one for each relevant IOMMU SID
> and then the driver will register two different devices to get the full
> range addresses ?
yes, alongwith the _non_ addressable range specific to that object, to
avoid the device crash.
>
> ---
> bod
^ permalink raw reply [flat|nested] 30+ messages in thread