[PATCH v2 1/8] dt-bindings: dma: marvell,mmp-dma: Add SpacemiT K1 PDMA support

[Krzysztof Kozlowski]

On 01/07/2025 11:52, Guodong Xu wrote:
> Hi, Krzysztof
> 
> On Tue, Jul 1, 2025 at 3:35 PM Krzysztof Kozlowski <krzk at kernel.org> wrote:
>>
>> On 01/07/2025 07:36, Guodong Xu wrote:
>>> Add "spacemit,k1-pdma" compatible string to support SpacemiT K1 PDMA
>>> controller. This variant requires:
>>
>> Why is this marvell? This should be explained here, it's really unexpected.
>>
> 
> SpacemiT K1 SoC uses the same DMA controller as Marvell MMP. They share most
> of the registers (and address offsets) and only enhanced in addressing space
> capability (from 32bit to 64bit).

I hope you got the last comment...

> 
> Also, spacemit,k1-pdma and marvell,pdma-1.0 use the same driver (mmp_pdma.c),
> that's the reason why I chose keeping them in the same binding file.

That's moderate reason. I explained here further - don't grow old
bindings with completely new devices, because you keep growing old,
poorer patterns. You have a new device, you can make it right.


...

>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            const: spacemit,k1-pdma
>>> +    then:
>>> +      required:
>>> +        - clocks
>>> +        - resets
>>> +    else:
>>> +      properties:
>>> +        clocks: false
>>> +        resets: false
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            enum:
>>> +              - marvell,pdma-1.0
>>> +              - spacemit,k1-pdma
>>> +    then:
>>> +      properties:
>>> +        '#dma-cells':
>>> +          const: 2
>>> +          description:
>>> +            The first cell contains the DMA request number for the peripheral
>>> +            device. The second cell is currently unused but must be present for
>>> +            backward compatibility.
>>> +    else:
>>> +      properties:
>>> +        '#dma-cells':
>>> +          const: 1
>>> +          description:
>>> +            The cell contains the DMA request number for the peripheral device.
>>
>>
>> It's getting complicated. I suggest to make your own schema. Then you
>> would also switch to preferred 'sram' property instead of that legacy
>> 'asram'.
>>
>> Really, ancient schemas should not be grown for new, completely
> 
> The reason that they share the same device driver may not be strong enough
> compared to what you said here.

If DMA maintainer(s) reject complexity in driver, then it is fine. But
till that happens, you should rather come with a clean new binding and
don't grow legacy.


Best regards,
Krzysztof