[PATCH v4 2/4] dt-bindings: soc: spacemit: Add K1 MBUS controller
Rob Herring
robh at kernel.org
Tue May 27 09:25:39 PDT 2025
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
More information about the linux-riscv
mailing list