linux-kernel - Re: [PATCH 1/5] dt-bindings: media: qcom,sm8550-iris: add non_pixel and resv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <85137a8e-45be-3bb2-d094-79754fa2a8be@quicinc.com>
Date: Tue, 24 Jun 2025 21:41:35 +0530
From: Vikash Garodia <quic_vgarodia@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
CC: Dikshita Agarwal <quic_dikshita@...cinc.com>,
        Abhinav Kumar
	<abhinav.kumar@...ux.dev>,
        Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, <linux-media@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/5] dt-bindings: media: qcom,sm8550-iris: add non_pixel
 and resv_region properties


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@...cinc.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
>>
>