Re: [PATCH v2 01/12] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema
Dmitry Baryshkov <[email protected]> Thu, 6 Aug 2026 13:35:43 +0300
| 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 | <npojagmk7x24wpbqcmzg4mijscqz63aluh6lj5uaciztzl53wl@ld342uighqaa> |
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. -- With best wishes Dmitry