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