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