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

[Ze Huang]

On 5/28/25 12:25 AM, Rob Herring wrote:
> 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

Different devices on the SoC may have distinct DMA address translations.
A common dma-ranges in the parent node may not represent this accurately.