[PATCH 0/5] Introduce "non_pixel" sub node within iris video node

[PATCH 0/5] Introduce "non_pixel" sub node within iris video node

[Vikash Garodia]

This series introduces a sub node "non_pixel" within iris video node.
Video driver registers this sub node as a platform device and configure 
it for DMA operations. All non pixel buffers, i.e bitstream, HFI queues 
and internal buffers related to bitstream processing, would be managed 
by this non_pixel device.

Purpose to add this sub-node:
Iris device limits the IOVA to an addressable range of 4GiB, and even 
within that range, some of the space is used by IO registers, thereby 
limiting the available IOVA to even lesser. For certain video usecase, 
this limited range in not sufficient enough, hence it brings the need to 
extend the possibility of higher IOVA range.

Video hardware is designed to emit different stream-ID for pixel and 
non_pixel buffers, thereby introduce a non_pixel sub node to handle 
non_pixel stream-ID into a separate platform device.
With this, both iris and non_pixel device can have IOVA range of 
approximately 0-4GiB individually for each device, thereby doubling the 
range of addressable IOVA.

Tested on SM8550 and SA8775p hardwares.

Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
---
Vikash Garodia (5):
      dt-bindings: media: qcom,sm8550-iris: add non_pixel and resv_region properties
      media: iris: register and configure non-pixel node as platform device
      media: iris: use np_dev as preferred DMA device in HFI queue management
      media: iris: select appropriate DMA device for internal buffers
      media: iris: configure DMA device for vb2 queue on OUTPUT plane

 .../bindings/media/qcom,sm8550-iris.yaml           | 35 +++++++++++++++
 drivers/media/platform/qcom/iris/iris_buffer.c     | 15 ++++++-
 drivers/media/platform/qcom/iris/iris_core.h       |  2 +
 drivers/media/platform/qcom/iris/iris_hfi_queue.c  | 20 ++++++---
 drivers/media/platform/qcom/iris/iris_probe.c      | 50 +++++++++++++++++++++-
 drivers/media/platform/qcom/iris/iris_vb2.c        |  4 ++
 6 files changed, 116 insertions(+), 10 deletions(-)
---
base-commit: 8d2b7fde56597ca912f5daaf3ab58915458ba1fc
change-id: 20250619-video_cb-ea872d6e6627

Best regards,
-- 
Vikash Garodia <quic_vgarodia@quicinc.com>

[PATCH 1/5] dt-bindings: media: qcom,sm8550-iris: add non_pixel and resv_region properties

[Vikash Garodia]

Existing definition limits the IOVA to an addressable range of 4GiB, and
even within that range, some of the space is used by IO registers,
thereby limiting the available IOVA to even lesser. Video hardware is
designed to emit different stream-ID for pixel and non_pixel buffers,
thereby introduce a non_pixel sub node to handle non_pixel stream-ID.

With this, both iris and non_pixel device can have IOVA range of 0-4GiB
individually. Certain video usecases like higher video concurrency needs
IOVA higher than 4GiB.

Add the "resv_region" property, which defines reserved IOVA regions that
are *excluded* from addressable range. Video hardware generates
different stream IDs based on the range of IOVA addresses. Thereby IOVA
addresses for firmware and data buffers need to be non overlapping. For
ex. 0x0-0x25800000 address range is reserved for firmware stream-ID,
while non_pixel (bitstream ) stream-ID can be generated by hardware only
when bitstream buffers IOVA address is from 0x25800000-0xe0000000.

Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
---
 .../bindings/media/qcom,sm8550-iris.yaml           | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
index c79bf2101812d83b99704f38b7348a9f728dff44..a1e83bae3c36f3a4c58b212ef457905e38091b97 100644
--- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
@@ -65,10 +65,45 @@ properties:
       - const: core
 
   iommus:
+    minItems: 1
     maxItems: 2
 
   dma-coherent: true
 
+  resv_region:
+    type: object
+    additionalProperties: false
+
+    description:
+      Reserve region specifies regions which should be excluded from IOVA.
+
+    properties:
+      iommu-addresses:
+        minItems: 1
+        maxItems: 4
+
+    required:
+      - iommu-addresses
+
+  non_pixel:
+    type: object
+    additionalProperties: false
+
+    description:
+      Non pixel context bank is needed when video hardware have distinct iommus
+      for non pixel buffers.
+
+    properties:
+      iommus:
+        maxItems: 1
+
+      memory-region:
+        maxItems: 1
+
+    required:
+      - iommus
+      - memory-region
+
   operating-points-v2: true
 
   opp-table:

-- 
2.34.1

Re: [PATCH 1/5] dt-bindings: media: qcom,sm8550-iris: add non_pixel and resv_region properties

[Krzysztof Kozlowski]

On 20/06/2025 08:20, Vikash Garodia wrote:
> Existing definition limits the IOVA to an addressable range of 4GiB, and
> even within that range, some of the space is used by IO registers,
> thereby limiting the available IOVA to even lesser. Video hardware is
> designed to emit different stream-ID for pixel and non_pixel buffers,
> thereby introduce a non_pixel sub node to handle non_pixel stream-ID.
> 
> With this, both iris and non_pixel device can have IOVA range of 0-4GiB
> individually. Certain video usecases like higher video concurrency needs
> IOVA higher than 4GiB.
> 
> Add the "resv_region" property, which defines reserved IOVA regions that
> are *excluded* from addressable range. Video hardware generates
> different stream IDs based on the range of IOVA addresses. Thereby IOVA
> addresses for firmware and data buffers need to be non overlapping. For
> ex. 0x0-0x25800000 address range is reserved for firmware stream-ID,
> while non_pixel (bitstream ) stream-ID can be generated by hardware only
> when bitstream buffers IOVA address is from 0x25800000-0xe0000000.
> 
> Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
> ---
>  .../bindings/media/qcom,sm8550-iris.yaml           | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> index c79bf2101812d83b99704f38b7348a9f728dff44..a1e83bae3c36f3a4c58b212ef457905e38091b97 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> @@ -65,10 +65,45 @@ properties:
>        - const: core
>  
>    iommus:
> +    minItems: 1

As discussed in other patchset, this needs clear explanation, so
imperfect patch won't be used in future discussions as argument to take
more of such things.

>      maxItems: 2
>  
>    dma-coherent: true
>  
> +  resv_region:

DTS coding style. Anyway, regions go with memory-region bindings. Use that.

Best regards,
Krzysztof

Re: [PATCH 1/5] dt-bindings: media: qcom,sm8550-iris: add non_pixel and resv_region properties

[Konrad Dybcio]

On 6/20/25 8:39 AM, Krzysztof Kozlowski wrote:
> On 20/06/2025 08:20, Vikash Garodia wrote:
>> Existing definition limits the IOVA to an addressable range of 4GiB, and
>> even within that range, some of the space is used by IO registers,
>> thereby limiting the available IOVA to even lesser. Video hardware is
>> designed to emit different stream-ID for pixel and non_pixel buffers,
>> thereby introduce a non_pixel sub node to handle non_pixel stream-ID.
>>
>> With this, both iris and non_pixel device can have IOVA range of 0-4GiB
>> individually. Certain video usecases like higher video concurrency needs
>> IOVA higher than 4GiB.
>>
>> Add the "resv_region" property, which defines reserved IOVA regions that
>> are *excluded* from addressable range. Video hardware generates
>> different stream IDs based on the range of IOVA addresses. Thereby IOVA
>> addresses for firmware and data buffers need to be non overlapping. For
>> ex. 0x0-0x25800000 address range is reserved for firmware stream-ID,
>> while non_pixel (bitstream ) stream-ID can be generated by hardware only
>> when bitstream buffers IOVA address is from 0x25800000-0xe0000000.
>>
>> Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
>> ---
>>  .../bindings/media/qcom,sm8550-iris.yaml           | 35 ++++++++++++++++++++++
>>  1 file changed, 35 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>> index c79bf2101812d83b99704f38b7348a9f728dff44..a1e83bae3c36f3a4c58b212ef457905e38091b97 100644
>> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>> @@ -65,10 +65,45 @@ properties:
>>        - const: core
>>  
>>    iommus:
>> +    minItems: 1
> 
> As discussed in other patchset, this needs clear explanation, so
> imperfect patch won't be used in future discussions as argument to take
> more of such things.
> 
>>      maxItems: 2
>>  
>>    dma-coherent: true
>>  
>> +  resv_region:
> 
> DTS coding style. Anyway, regions go with memory-region bindings. Use that.

On a tangent, FWIW this is a discussion related to this patchset that
never got much attention:

https://lore.kernel.org/linux-devicetree/9439182e-3338-4d57-aa02-b621bc9498a3@oss.qualcomm.com/

Konrad

Re: [PATCH 1/5] dt-bindings: media: qcom,sm8550-iris: add non_pixel and resv_region properties

[Krzysztof Kozlowski]

On 20/06/2025 19:27, Konrad Dybcio wrote:
> On 6/20/25 8:39 AM, Krzysztof Kozlowski wrote:
>> On 20/06/2025 08:20, Vikash Garodia wrote:
>>> Existing definition limits the IOVA to an addressable range of 4GiB, and
>>> even within that range, some of the space is used by IO registers,
>>> thereby limiting the available IOVA to even lesser. Video hardware is
>>> designed to emit different stream-ID for pixel and non_pixel buffers,
>>> thereby introduce a non_pixel sub node to handle non_pixel stream-ID.
>>>
>>> With this, both iris and non_pixel device can have IOVA range of 0-4GiB
>>> individually. Certain video usecases like higher video concurrency needs
>>> IOVA higher than 4GiB.
>>>
>>> Add the "resv_region" property, which defines reserved IOVA regions that
>>> are *excluded* from addressable range. Video hardware generates
>>> different stream IDs based on the range of IOVA addresses. Thereby IOVA
>>> addresses for firmware and data buffers need to be non overlapping. For
>>> ex. 0x0-0x25800000 address range is reserved for firmware stream-ID,
>>> while non_pixel (bitstream ) stream-ID can be generated by hardware only
>>> when bitstream buffers IOVA address is from 0x25800000-0xe0000000.
>>>
>>> Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
>>> ---
>>>  .../bindings/media/qcom,sm8550-iris.yaml           | 35 ++++++++++++++++++++++
>>>  1 file changed, 35 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>>> index c79bf2101812d83b99704f38b7348a9f728dff44..a1e83bae3c36f3a4c58b212ef457905e38091b97 100644
>>> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>>> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>>> @@ -65,10 +65,45 @@ properties:
>>>        - const: core
>>>  
>>>    iommus:
>>> +    minItems: 1
>>
>> As discussed in other patchset, this needs clear explanation, so
>> imperfect patch won't be used in future discussions as argument to take
>> more of such things.
>>
>>>      maxItems: 2
>>>  
>>>    dma-coherent: true
>>>  
>>> +  resv_region:
>>
>> DTS coding style. Anyway, regions go with memory-region bindings. Use that.
> 
> On a tangent, FWIW this is a discussion related to this patchset that
> never got much attention:
> 
> https://lore.kernel.org/linux-devicetree/9439182e-3338-4d57-aa02-b621bc9498a3@oss.qualcomm.com/


There is no patchset above, just email describing a problem. It did not
get attention maybe because of usual kernel process: show the code, we
do not have time to comment on every problem or idea.

Best regards,
Krzysztof

Re: [PATCH 1/5] dt-bindings: media: qcom,sm8550-iris: add non_pixel and resv_region properties

[Rob Herring]

On Fri, Jun 20, 2025 at 07:27:03PM +0200, Konrad Dybcio wrote:
> On 6/20/25 8:39 AM, Krzysztof Kozlowski wrote:
> > On 20/06/2025 08:20, Vikash Garodia wrote:
> >> Existing definition limits the IOVA to an addressable range of 4GiB, and
> >> even within that range, some of the space is used by IO registers,
> >> thereby limiting the available IOVA to even lesser. Video hardware is
> >> designed to emit different stream-ID for pixel and non_pixel buffers,
> >> thereby introduce a non_pixel sub node to handle non_pixel stream-ID.
> >>
> >> With this, both iris and non_pixel device can have IOVA range of 0-4GiB
> >> individually. Certain video usecases like higher video concurrency needs
> >> IOVA higher than 4GiB.
> >>
> >> Add the "resv_region" property, which defines reserved IOVA regions that
> >> are *excluded* from addressable range. Video hardware generates
> >> different stream IDs based on the range of IOVA addresses. Thereby IOVA
> >> addresses for firmware and data buffers need to be non overlapping. For
> >> ex. 0x0-0x25800000 address range is reserved for firmware stream-ID,
> >> while non_pixel (bitstream ) stream-ID can be generated by hardware only
> >> when bitstream buffers IOVA address is from 0x25800000-0xe0000000.
> >>
> >> Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
> >> ---
> >>  .../bindings/media/qcom,sm8550-iris.yaml           | 35 ++++++++++++++++++++++
> >>  1 file changed, 35 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> >> index c79bf2101812d83b99704f38b7348a9f728dff44..a1e83bae3c36f3a4c58b212ef457905e38091b97 100644
> >> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> >> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> >> @@ -65,10 +65,45 @@ properties:
> >>        - const: core
> >>  
> >>    iommus:
> >> +    minItems: 1
> > 
> > As discussed in other patchset, this needs clear explanation, so
> > imperfect patch won't be used in future discussions as argument to take
> > more of such things.
> > 
> >>      maxItems: 2
> >>  
> >>    dma-coherent: true
> >>  
> >> +  resv_region:
> > 
> > DTS coding style. Anyway, regions go with memory-region bindings. Use that.
> 
> On a tangent, FWIW this is a discussion related to this patchset that
> never got much attention:
> 
> https://lore.kernel.org/linux-devicetree/9439182e-3338-4d57-aa02-b621bc9498a3@oss.qualcomm.com/

Send !patches to devicetree-spec if you want any chance of it being 
seen. If it is not a patch in PW from the firehose that's the 
devicetree list, then I likely never read it. 

But I don't have any clue how iommu-addresses works to give guidance. 
I'd propose something that works for you if you really want some 
discussion.

Rob

Re: [PATCH 1/5] dt-bindings: media: qcom,sm8550-iris: add non_pixel and resv_region properties

[Vikash Garodia]

On 6/20/2025 12:09 PM, Krzysztof Kozlowski wrote:
> On 20/06/2025 08:20, Vikash Garodia wrote:
>> Existing definition limits the IOVA to an addressable range of 4GiB, and
>> even within that range, some of the space is used by IO registers,
>> thereby limiting the available IOVA to even lesser. Video hardware is
>> designed to emit different stream-ID for pixel and non_pixel buffers,
>> thereby introduce a non_pixel sub node to handle non_pixel stream-ID.
>>
>> With this, both iris and non_pixel device can have IOVA range of 0-4GiB
>> individually. Certain video usecases like higher video concurrency needs
>> IOVA higher than 4GiB.
>>
>> Add the "resv_region" property, which defines reserved IOVA regions that
>> are *excluded* from addressable range. Video hardware generates
>> different stream IDs based on the range of IOVA addresses. Thereby IOVA
>> addresses for firmware and data buffers need to be non overlapping. For
>> ex. 0x0-0x25800000 address range is reserved for firmware stream-ID,
>> while non_pixel (bitstream ) stream-ID can be generated by hardware only
>> when bitstream buffers IOVA address is from 0x25800000-0xe0000000.
>>
>> Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
>> ---
>>  .../bindings/media/qcom,sm8550-iris.yaml           | 35 ++++++++++++++++++++++
>>  1 file changed, 35 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>> index c79bf2101812d83b99704f38b7348a9f728dff44..a1e83bae3c36f3a4c58b212ef457905e38091b97 100644
>> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>> @@ -65,10 +65,45 @@ properties:
>>        - const: core
>>  
>>    iommus:
>> +    minItems: 1
> 
> As discussed in other patchset, this needs clear explanation, so
> imperfect patch won't be used in future discussions as argument to take
> more of such things.
ACK.
> 
>>      maxItems: 2
>>  
>>    dma-coherent: true
>>  
>> +  resv_region:
> 
> DTS coding style. Anyway, regions go with memory-region bindings. Use that.
Sorry for a basic query here - I was reading through memory-region bindings in
[1]. My requirement is exactly same as the schema defined in [2] ex. adsp_resv.
Would it be more appropriate to extend reserved-memory.yaml, something like
below in iris yaml
allOf:
  - $ref: reserved-memory.yaml

Or any other approach to reference to [2] in iris yaml ?

[1]https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reserved-memory/memory-region.yaml

[2]https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reserved-memory/reserved-memory.yaml

Regards,
Vikash
> 
> Best regards,
> Krzysztof

Re: [PATCH 1/5] dt-bindings: media: qcom,sm8550-iris: add non_pixel and resv_region properties

[Krzysztof Kozlowski]

On 20/06/2025 08:20, Vikash Garodia wrote:
> Existing definition limits the IOVA to an addressable range of 4GiB, and
> even within that range, some of the space is used by IO registers,
> thereby limiting the available IOVA to even lesser. Video hardware is
> designed to emit different stream-ID for pixel and non_pixel buffers,
> thereby introduce a non_pixel sub node to handle non_pixel stream-ID.
> 
> With this, both iris and non_pixel device can have IOVA range of 0-4GiB
> individually. Certain video usecases like higher video concurrency needs
> IOVA higher than 4GiB.
> 
> Add the "resv_region" property, which defines reserved IOVA regions that
> are *excluded* from addressable range. Video hardware generates
> different stream IDs based on the range of IOVA addresses. Thereby IOVA
> addresses for firmware and data buffers need to be non overlapping. For
> ex. 0x0-0x25800000 address range is reserved for firmware stream-ID,
> while non_pixel (bitstream ) stream-ID can be generated by hardware only
> when bitstream buffers IOVA address is from 0x25800000-0xe0000000.
> 
Also, use correct subject prefixes.

Best regards,
Krzysztof

Re: [PATCH 1/5] dt-bindings: media: qcom,sm8550-iris: add non_pixel and resv_region properties

[Dmitry Baryshkov]

On Fri, Jun 20, 2025 at 11:50:51AM +0530, Vikash Garodia wrote:
> Existing definition limits the IOVA to an addressable range of 4GiB, and
> even within that range, some of the space is used by IO registers,
> thereby limiting the available IOVA to even lesser. Video hardware is
> designed to emit different stream-ID for pixel and non_pixel buffers,
> thereby introduce a non_pixel sub node to handle non_pixel stream-ID.
> 
> With this, both iris and non_pixel device can have IOVA range of 0-4GiB
> individually. Certain video usecases like higher video concurrency needs
> IOVA higher than 4GiB.
> 
> Add the "resv_region" property, which defines reserved IOVA regions that
> are *excluded* from addressable range. Video hardware generates
> different stream IDs based on the range of IOVA addresses. Thereby IOVA
> addresses for firmware and data buffers need to be non overlapping. For
> ex. 0x0-0x25800000 address range is reserved for firmware stream-ID,
> while non_pixel (bitstream ) stream-ID can be generated by hardware only
> when bitstream buffers IOVA address is from 0x25800000-0xe0000000.
> 
> Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
> ---
>  .../bindings/media/qcom,sm8550-iris.yaml           | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> index c79bf2101812d83b99704f38b7348a9f728dff44..a1e83bae3c36f3a4c58b212ef457905e38091b97 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> @@ -65,10 +65,45 @@ properties:
>        - const: core
>  
>    iommus:
> +    minItems: 1
>      maxItems: 2
>  
>    dma-coherent: true
>  
> +  resv_region:

Ugh. Underscores...

> +    type: object
> +    additionalProperties: false
> +
> +    description:
> +      Reserve region specifies regions which should be excluded from IOVA.
> +
> +    properties:
> +      iommu-addresses:

Missing type / ref. Also they are only described for reserved memory
regions.

> +        minItems: 1
> +        maxItems: 4
> +
> +    required:
> +      - iommu-addresses
> +
> +  non_pixel:
> +    type: object
> +    additionalProperties: false


I still think that these usecases should be described with iommu-maps
rather than subnodes. You have a limited set of usecases: "non-pixel",
secure buffers, etc. Define an ID for each of those and then allocate a
subdevice internally, mapping it to a corresponding set of IOMMUs.

> +
> +    description:
> +      Non pixel context bank is needed when video hardware have distinct iommus
> +      for non pixel buffers.

What does non-pixel mean? Compressed data?

> +
> +    properties:
> +      iommus:
> +        maxItems: 1
> +
> +      memory-region:
> +        maxItems: 1
> +
> +    required:
> +      - iommus
> +      - memory-region
> +
>    operating-points-v2: true
>  
>    opp-table:
> 
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

Re: [PATCH 1/5] dt-bindings: media: qcom,sm8550-iris: add non_pixel and resv_region properties

[Vikash Garodia]

On 6/21/2025 3:09 AM, Dmitry Baryshkov wrote:
> On Fri, Jun 20, 2025 at 11:50:51AM +0530, Vikash Garodia wrote:
>> Existing definition limits the IOVA to an addressable range of 4GiB, and
>> even within that range, some of the space is used by IO registers,
>> thereby limiting the available IOVA to even lesser. Video hardware is
>> designed to emit different stream-ID for pixel and non_pixel buffers,
>> thereby introduce a non_pixel sub node to handle non_pixel stream-ID.
>>
>> With this, both iris and non_pixel device can have IOVA range of 0-4GiB
>> individually. Certain video usecases like higher video concurrency needs
>> IOVA higher than 4GiB.
>>
>> Add the "resv_region" property, which defines reserved IOVA regions that
>> are *excluded* from addressable range. Video hardware generates
>> different stream IDs based on the range of IOVA addresses. Thereby IOVA
>> addresses for firmware and data buffers need to be non overlapping. For
>> ex. 0x0-0x25800000 address range is reserved for firmware stream-ID,
>> while non_pixel (bitstream ) stream-ID can be generated by hardware only
>> when bitstream buffers IOVA address is from 0x25800000-0xe0000000.
>>
>> Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
>> ---
>>  .../bindings/media/qcom,sm8550-iris.yaml           | 35 ++++++++++++++++++++++
>>  1 file changed, 35 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>> index c79bf2101812d83b99704f38b7348a9f728dff44..a1e83bae3c36f3a4c58b212ef457905e38091b97 100644
>> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>> @@ -65,10 +65,45 @@ properties:
>>        - const: core
>>  
>>    iommus:
>> +    minItems: 1
>>      maxItems: 2
>>  
>>    dma-coherent: true
>>  
>> +  resv_region:
> 
> Ugh. Underscores...
ACK
> 
>> +    type: object
>> +    additionalProperties: false
>> +
>> +    description:
>> +      Reserve region specifies regions which should be excluded from IOVA.
>> +
>> +    properties:
>> +      iommu-addresses:
> 
> Missing type / ref. Also they are only described for reserved memory
> regions.
yes, looks like we can drop them from iris schema and rather reference it from
reserved-memory schema. Awaiting comments on the ongoing discussion here [1]

[1] https://lore.kernel.org/all/4c6233d9-be7b-baf3-fb05-3ea007e35330@quicinc.com/
> 
>> +        minItems: 1
>> +        maxItems: 4
>> +
>> +    required:
>> +      - iommu-addresses
>> +
>> +  non_pixel:
>> +    type: object
>> +    additionalProperties: false
> 
> 
> I still think that these usecases should be described with iommu-maps
> rather than subnodes. You have a limited set of usecases: "non-pixel",
> secure buffers, etc. Define an ID for each of those and then allocate a
> subdevice internally, mapping it to a corresponding set of IOMMUs.
In secure buffers category, there would be 3 categories -
pixel/non-pixel/internal. Adding it up with non secure, we would be having 4 sub
nodes eventually.
Reading about the usage of iommu-maps, I see there are below limitations. If you
could suggest a way to handle these,
1. let say there are 4 stream-ids, iommu-maps does not provide a way to tell
which stream-id is for which sub hardware block(device) within video, so that
driver can use it for mapping the corresponding buffers.
2. defining the masks for different stream-ids.
3. IOVA address regions - Different stream-ids have non-mappable range, which i
am specifying via iommu-addresses in sub nodes.

Again, iommu-maps was invented for PCIe case where different stream-id can be
routed to different iommus. In this case, all stream-id would be managed by same
iommu.

Regards,
Vikash
> 
>> +
>> +    description:
>> +      Non pixel context bank is needed when video hardware have distinct iommus
>> +      for non pixel buffers.
> 
> What does non-pixel mean? Compressed data?
> 
>> +
>> +    properties:
>> +      iommus:
>> +        maxItems: 1
>> +
>> +      memory-region:
>> +        maxItems: 1
>> +
>> +    required:
>> +      - iommus
>> +      - memory-region
>> +
>>    operating-points-v2: true
>>  
>>    opp-table:
>>
>> -- 
>> 2.34.1
>>
> 

[PATCH 2/5] media: iris: register and configure non-pixel node as platform device

[Vikash Garodia]

Register "non_pixel" child node as a platform device, and configure its
DMA via of_dma_configure(). This ensures proper IOMMU attachment and DMA
setup for the "non_pixel" device.
All non pixel memory, i.e bitstream buffers, HFI queues and internal
buffers related to bitstream processing, would be managed by non_pixel
device.

Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
---
 drivers/media/platform/qcom/iris/iris_core.h  |  2 ++
 drivers/media/platform/qcom/iris/iris_probe.c | 50 ++++++++++++++++++++++++++-
 2 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/iris/iris_core.h b/drivers/media/platform/qcom/iris/iris_core.h
index aeeac32a1f6d9a9fa7027e8e3db4d95f021c552e..757efd16870876bd2b1d5b1e4103b2d2326b5f49 100644
--- a/drivers/media/platform/qcom/iris/iris_core.h
+++ b/drivers/media/platform/qcom/iris/iris_core.h
@@ -65,6 +65,7 @@ struct icc_info {
  * @sys_error_handler: a delayed work for handling system fatal error
  * @instances: a list_head of all instances
  * @inst_fw_caps: an array of supported instance capabilities
+ * @np_dev: device to represent non pixel node
  */
 
 struct iris_core {
@@ -105,6 +106,7 @@ struct iris_core {
 	struct delayed_work			sys_error_handler;
 	struct list_head			instances;
 	struct platform_inst_fw_cap		inst_fw_caps[INST_FW_CAP_MAX];
+	struct device				*np_dev;
 };
 
 int iris_core_init(struct iris_core *core);
diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
index 9a7ce142f7007ffcda0bd422c1983f2374bb0d92..8fe87e30bd40f3c67ec41305c7d73520fbc9db7b 100644
--- a/drivers/media/platform/qcom/iris/iris_probe.c
+++ b/drivers/media/platform/qcom/iris/iris_probe.c
@@ -6,6 +6,8 @@
 #include <linux/clk.h>
 #include <linux/interconnect.h>
 #include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
 #include <linux/pm_domain.h>
 #include <linux/pm_opp.h>
 #include <linux/pm_runtime.h>
@@ -127,6 +129,46 @@ static int iris_init_resets(struct iris_core *core)
 				     core->iris_platform_data->controller_rst_tbl_size);
 }
 
+static int iris_init_non_pixel_node(struct iris_core *core)
+{
+	struct platform_device_info info;
+	struct platform_device *pdev;
+	struct device_node *np_node;
+	int ret;
+
+	np_node = of_get_child_by_name(core->dev->of_node, "non_pixel");
+	if (!np_node)
+		return 0;
+
+	memset(&info, 0, sizeof(info));
+	info.fwnode = &np_node->fwnode;
+	info.parent = core->dev;
+	info.name = np_node->name;
+	info.dma_mask = DMA_BIT_MASK(32);
+
+	pdev = platform_device_register_full(&info);
+	if (IS_ERR(pdev)) {
+		of_node_put(np_node);
+		return PTR_ERR(pdev);
+	}
+	pdev->dev.of_node = np_node;
+
+	ret = of_dma_configure(&pdev->dev, np_node, true);
+	if (ret)
+		goto err_unregister;
+
+	core->np_dev = &pdev->dev;
+
+	of_node_put(np_node);
+
+	return 0;
+
+err_unregister:
+	platform_device_unregister(pdev);
+	of_node_put(np_node);
+	return ret;
+}
+
 static int iris_init_resources(struct iris_core *core)
 {
 	int ret;
@@ -143,7 +185,11 @@ static int iris_init_resources(struct iris_core *core)
 	if (ret)
 		return ret;
 
-	return iris_init_resets(core);
+	ret = iris_init_resets(core);
+	if (ret)
+		return ret;
+
+	return iris_init_non_pixel_node(core);
 }
 
 static int iris_register_video_device(struct iris_core *core)
@@ -188,6 +234,8 @@ static void iris_remove(struct platform_device *pdev)
 
 	iris_core_deinit(core);
 
+	platform_device_unregister(to_platform_device(core->np_dev));
+
 	video_unregister_device(core->vdev_dec);
 
 	v4l2_device_unregister(&core->v4l2_dev);

-- 
2.34.1

[PATCH 3/5] media: iris: use np_dev as preferred DMA device in HFI queue management

[Vikash Garodia]

Update HFI interface queues to use np_dev(preferred non-pixel device)
for DMA memory allocation and deallocation if available. This allows
platforms with separate DMA domain for non-pixel to use the appropriate
device handle when managing HFI queues and SFR regions.

Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
---
 drivers/media/platform/qcom/iris/iris_hfi_queue.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/qcom/iris/iris_hfi_queue.c b/drivers/media/platform/qcom/iris/iris_hfi_queue.c
index fac7df0c4d1aec647aeca275ab19651c9ba23733..a31ebe947f525f0d7c09f8b786939d01b62532c3 100644
--- a/drivers/media/platform/qcom/iris/iris_hfi_queue.c
+++ b/drivers/media/platform/qcom/iris/iris_hfi_queue.c
@@ -247,24 +247,27 @@ static void iris_hfi_queue_deinit(struct iris_iface_q_info *iface_q)
 int iris_hfi_queues_init(struct iris_core *core)
 {
 	struct iris_hfi_queue_table_header *q_tbl_hdr;
+	struct device *dev;
 	u32 queue_size;
 
+	dev = core->np_dev ? core->np_dev : core->dev;
+
 	/* 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, sizeof(*q_tbl_hdr), core->iface_q_table_vaddr,
+		dev_err(dev, "sfr alloc and map failed\n");
+		dma_free_attrs(dev, sizeof(*q_tbl_hdr), core->iface_q_table_vaddr,
 			       core->iface_q_table_daddr, DMA_ATTR_WRITE_COMBINE);
 		return -ENOMEM;
 	}
@@ -292,6 +295,7 @@ int iris_hfi_queues_init(struct iris_core *core)
 
 void iris_hfi_queues_deinit(struct iris_core *core)
 {
+	struct device *dev;
 	u32 queue_size;
 
 	if (!core->iface_q_table_vaddr)
@@ -301,7 +305,9 @@ 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,
+	dev = core->np_dev ? core->np_dev : core->dev;
+
+	dma_free_attrs(dev, SFR_SIZE, core->sfr_vaddr,
 		       core->sfr_daddr, DMA_ATTR_WRITE_COMBINE);
 
 	core->sfr_vaddr = NULL;
@@ -310,7 +316,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;

-- 
2.34.1

[PATCH 4/5] media: iris: select appropriate DMA device for internal buffers

[Vikash Garodia]

When a non-pixel device (np_dev) exists, it is preferred for DMA
operations for internal buffers which are specific to bitstream data
processing. DPB(decoded picture buffer) buffers are internal buffers
associated with pixel buffers, hence they are not part of "non_pixel"
device.

Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
---
 drivers/media/platform/qcom/iris/iris_buffer.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/qcom/iris/iris_buffer.c b/drivers/media/platform/qcom/iris/iris_buffer.c
index e5c5a564fcb81e77746df8c4797a10a07f2ae946..0bf6041936175d03a51985be148e78894fc3e990 100644
--- a/drivers/media/platform/qcom/iris/iris_buffer.c
+++ b/drivers/media/platform/qcom/iris/iris_buffer.c
@@ -265,6 +265,7 @@ static int iris_create_internal_buffer(struct iris_inst *inst,
 	struct iris_buffers *buffers = &inst->buffers[buffer_type];
 	struct iris_core *core = inst->core;
 	struct iris_buffer *buffer;
+	struct device *dev;
 
 	if (!buffers->size)
 		return 0;
@@ -280,7 +281,11 @@ static int iris_create_internal_buffer(struct iris_inst *inst,
 	buffer->dma_attrs = DMA_ATTR_WRITE_COMBINE | DMA_ATTR_NO_KERNEL_MAPPING;
 	list_add_tail(&buffer->list, &buffers->list);
 
-	buffer->kvaddr = dma_alloc_attrs(core->dev, buffer->buffer_size,
+	dev = core->np_dev ? core->np_dev : core->dev;
+	if (buffer->type == BUF_DPB)
+		dev = core->dev;
+
+	buffer->kvaddr = dma_alloc_attrs(dev, buffer->buffer_size,
 					 &buffer->device_addr, GFP_KERNEL, buffer->dma_attrs);
 	if (!buffer->kvaddr)
 		return -ENOMEM;
@@ -367,9 +372,15 @@ 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;
+
+	dev = core->np_dev ? core->np_dev : core->dev;
+
+	if (buffer->type == BUF_DPB)
+		dev = core->dev;
 
 	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);
 

-- 
2.34.1

[PATCH 5/5] media: iris: configure DMA device for vb2 queue on OUTPUT plane

[Vikash Garodia]

While setting up the vb2 queues, assign "non_pixel" device to manage
OUTPUT plane buffers i.e bitstream buffers incase of decoder. It prefers
the non_pixel device(np_dev) when available, falling back to core->dev
otherwise.

Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
---
 drivers/media/platform/qcom/iris/iris_vb2.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/platform/qcom/iris/iris_vb2.c b/drivers/media/platform/qcom/iris/iris_vb2.c
index cdf11feb590b5cb7804db3fcde7282fb1f9f1a1e..01cc337970400d48063c558c1ac039539dbcbaba 100644
--- a/drivers/media/platform/qcom/iris/iris_vb2.c
+++ b/drivers/media/platform/qcom/iris/iris_vb2.c
@@ -159,6 +159,10 @@ int iris_vb2_queue_setup(struct vb2_queue *q,
 	*num_planes = 1;
 	sizes[0] = f->fmt.pix_mp.plane_fmt[0].sizeimage;
 
+	if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT ||
+	    q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
+		q->dev = core->np_dev ? core->np_dev : core->dev;
+
 unlock:
 	mutex_unlock(&inst->lock);
 

-- 
2.34.1