Re: [PATCH v2 01/12] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema

Vikash Garodia <[email protected]> Thu, 6 Aug 2026 17:26:51 +0530
Newsgroups org.kernel.vger.linux-media,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.stable
Message-ID <[email protected]>
On 8/6/2026 4:05 PM, Dmitry Baryshkov wrote:
> On Thu, Aug 06, 2026 at 11:36:45AM +0200, Krzysztof Kozlowski wrote:
>> On 06/08/2026 11:22, Dmitry Baryshkov wrote:
>>> On Thu, Aug 06, 2026 at 11:11:09AM +0200, Krzysztof Kozlowski wrote:
>>>> On 06/08/2026 10:46, Dmitry Baryshkov wrote:
>>>>>
>>>>>> dma-ranges tell how this bus - so venus/iris - performs DMA translation
>>>>>> in respective to parent. Address/size-cells are obviously also needed if
>>>>>> this is a bus with addressing.
>>>>>>
>>>>>> But there are no children with addressing, thus what sort of bus would
>>>>>> it be?
>>>>>>
>>>>>> It looks to me that having here both:
>>>>>> 1. dma-ranges + address/size-cells
>>>>>> 2. children without bus addressing
>>>>>> is some sort of abuse of the DT syntax. It is allowed, but does not
>>>>>> really represent hardware.
>>>>>>
>>>>>> IOW, dma-ranges alone feels okay, although unusual, and it states proper
>>>>>> DMA translation for this bus. If you add address/size-cells, it means
>>>>>> this bus HAS addressing and thus YOU MUST use addressing.
>>>>>>
>>>>>> If my understanding is correct, then solution would be to add addressing
>>>>>> to the children (so unit address and "reg" property) or drop
>>>>>> address/size-cells as Rob pointed out. [1]
>>>>>
>>>>> Doesn't dma-ranges require address/size cells? In the end, how can you
>>>>
>>>> I think it does not require, at least how I understood the DT spec,
>>>> unless you provide actual addresses to the property.
>>>>
>>>> IOW, this requires address/size-cells:
>>>> 	dma-ranges = <0 0 0 0 0x10 0>;
>>>>
>>>>> specify the DMA address if the device doesn't have addressing at all (or
>>>>> MMIO-style addressing)?
>>>>
>>>> Yeah, that's why having here children without bus addressing is
>>>> confusing. I would interpret it that, children are not on MMIO bus, thus
>>>> the venus/iris is some sort of proprietary bus with no mapping between
>>>> parent MMIO and children nodes.
>>>>
>>>> If there is no mapping, then we do not have 'ranges' property. But I
>>>> could imagine that such no-mapping bus still provides access to system RAM?
>>>>
>>>> Actually this feels like a huge stretch, so I tend to think that the
>>>> only reasonable option is to have children with MMIO, which would make
>>>> it explicit: Venus/iris is a bus which provides translation of both MMIO
>>>> and DMA addresses to the parent.
>>>
>>> But there are no separate addresses for those subnodes. Would you prefer
>>
>> There might be some or maybe these should be the addresses of DMA?
>>
>>> them to duplicate the addresses of the parent node? Or would the
>>> 'ranges' be enough?
>>
>> I made mistake earlier - 'dma-ranges' without values is not described in
>> DT spec explicitly, but should be treated as 'ranges' without values,
>> thus direct mapping from parent to the child.
> 
> Documentation/devicetree/bindings/iommu/iommu.txt:
> 
>    An empty "dma-ranges" property means that there is a 1:1 mapping from
>    IOMMU to memory.
> 
>>
>> So it also requires address/size-cells, just like 'dma-ranges =
>> <mapping>'. And dtc checks/reports that.
>>
>> I think therefore now that the binding is unusual (because no bus
>> addresses of children) but actually correct.
>>
>>>
>>> Or, thinking about it, if Venus / Iris have 32-bit addressing, then
>>> dma-range should probably define the limited DMA range.
>>
>> That's another point which I also raised to Vikash already - mapping
>> should be restricted to 32-bit if this is how the child devices operate.
> 
> Souds so. Then we need a non-empty dma-ranges.
> 
> 

based on this discussion, below works for schema check and dtc

schema:
   '#address-cells':
     const: 1

   '#size-cells':
     const: 1

   dma-ranges:
     maxItems: 1


Now in the schema examples, soc is added to match the reg/dma-ranges of 
parent (iris)

   examples
      soc {
           #address-cells = <2>;
           #size-cells = <2>;

           video-codec@aa00000 {
             compatible = "qcom,sm8550-iris";
             reg = <0x0 0x0aa00000 0x0 0xf0000>;

DTS

iris {
....
   #address-cells = <1>;
   #size-cells = <1>;
   dma-ranges = <0x0 0x0 0x0 0xe0000000>;

   iris_non_pixel: non-pixel {
	iommus = <&apps_smmu 0x1940 0x0>;
	memory-region = <&iris_resv>;
   };

   pixel {
	iommus = <&apps_smmu 0x1947 0x0>;
   };

Please review if anything is missed out.

Regards,
Vikash