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

Dmitry Baryshkov <[email protected]>
Newsgroups org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-media,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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.