Re: [PATCH v4 2/4] dt-bindings: soc: spacemit: Add K1 MBUS controller

[Rob Herring <robh@kernel.org>]

On Tue, May 27, 2025 at 07:13:05PM +0800, Ze Huang wrote:
> On Tue, May 27, 2025 at 08:51:19AM +0200, Krzysztof Kozlowski wrote:
> > On Mon, May 26, 2025 at 10:40:18PM GMT, Ze Huang wrote:
> > > Some devices on the SpacemiT K1 SoC perform DMA through a memory bus
> > > (MBUS) that is not their immediate parent in the device tree. This bus
> > > uses a different address mapping than the CPU.
> > > 
> > > To express this topology properly, devices are expected to use the
> > > interconnects with name "dma-mem" to reference the MBUS controller.
> > 
> > I don't get it, sorry. Devices performing DMA through foo-bar should use
> > dmas property for foo-bar DMA controller. Interconnects is not for that.
> > 
> 
> Hi Krzysztof,
> 
> Sorry for not clarifying this earlier - let me provide some context.
> 
> The purpose of this node is to describe the address translation used for DMA
> device to memory transactions. I’m using the "interconnects" property with the
> reserved name "dma-mem" [1] in consumer devices to express this relationship.
> The actual translation is handled by the `of_translate_dma_address()` [2].
> This support was introduced in the series linked in [3].
> 
> This setup is similar to what we see on platforms like Allwinner sun5i,
> sun8i-r40, and NVIDIA Tegra. [4][5]
> 
> I considered reusing the existing Allwinner MBUS driver and bindings.
> However, the Allwinner MBUS includes additional functionality such as
> bandwidth monitoring and frequency control - features that are either
> absent or undocumented on the SpacemiT K1 SoC.

The interconnect binding is for when you have those software controls. 
If you only have address translation, then 'dma-ranges' in a parent node 
is all you need.

Rob

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv