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.1On 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
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 >> >
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
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
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
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
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
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
© 2016 - 2025 Red Hat, Inc.