[PATCH v6 13/19] dt-bindings: dma: ti: Add K3 BCDMA V2

[Sai Sree Kartheek Adivi]

Hi Krzysztof,

On 30/04/26 12:59, Krzysztof Kozlowski wrote:
> On Tue, Apr 28, 2026 at 02:21:42PM +0530, Sai Sree Kartheek Adivi wrote:
>> New binding document for
> I don't see improvements.
>
>> Texas Instruments K3 Block Copy DMA (BCDMA) V2.
>>
>> BCDMA V2 is introduced as part of AM62L.
>>
>> Signed-off-by: Sai Sree Kartheek Adivi <s-adivi at ti.com>
>> ---
>>  .../bindings/dma/ti/ti,am62l-dmss-bcdma.yaml  | 121 ++++++++++++++++++
>>  1 file changed, 121 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/dma/ti/ti,am62l-dmss-bcdma.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/dma/ti/ti,am62l-dmss-bcdma.yaml b/Documentation/devicetree/bindings/dma/ti/ti,am62l-dmss-bcdma.yaml
>> new file mode 100644
>> index 0000000000000..28dcfce5633ce
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/ti/ti,am62l-dmss-bcdma.yaml
>> @@ -0,0 +1,121 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (C) 2024-25 Texas Instruments Incorporated
>> +# Author: Sai Sree Kartheek Adivi <s-adivi at ti.com>
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/dma/ti/ti,am62l-dmss-bcdma.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Texas Instruments K3 DMSS BCDMA V2
>> +
>> +maintainers:
>> +  - Sai Sree Kartheek Adivi <s-adivi at ti.com>
>> +
>> +description:
>> +  The BCDMA V2 is intended to perform similar functions as the TR
>> +  mode channels of K3 UDMA-P.
>> +  BCDMA V2 includes block copy channels and Split channels.
>> +
>> +  Block copy channels mainly used for memory to memory transfers, but with
>> +  optional triggers a block copy channel can service peripherals by accessing
>> +  directly to memory mapped registers or area.
>> +
>> +  Split channels can be used to service PSI-L based peripherals.
>> +  The peripherals can be PSI-L native or legacy, non PSI-L native peripherals
>> +  with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric and the
>> +  legacy peripheral.
>> +
>> +allOf:
>> +  - $ref: /schemas/dma/dma-controller.yaml#
>> +
>> +properties:
>> +  compatible:
>> +    const: ti,am62l-dmss-bcdma
>> +
>> +  reg:
>> +    items:
>> +      - description: BCDMA Control & Status Registers region
>> +      - description: Block Copy Channel Realtime Registers region
>> +      - description: Channel Realtime Registers region
>> +      - description: Ring Realtime Registers region
>> +
>> +  reg-names:
>> +    items:
>> +      - const: gcfg
>> +      - const: bchanrt
>> +      - const: chanrt
>> +      - const: ringrt
>> +
>> +  "#address-cells":
>> +    const: 0
> Why do you need address-cells?
>
>> +
>> +  "#dma-cells":
>> +    const: 4
>> +    description: |
>> +      cell 1: Trigger type for the channel
>> +        0 - disable / no trigger
>> +        1 - internal channel event
>> +        2 - external signal
>> +        3 - timer manager event
>> +
>> +      cell 2: parameter for the trigger:
>> +        if cell 1 is 0 (disable / no trigger):
>> +          Unused, ignored
>> +        if cell 1 is 1 (internal channel event):
>> +          channel number whose TR event should trigger the current channel.
>> +        if cell 1 is 2 or 3 (external signal or timer manager event):
>> +          index of global interfaces that come into the DMA.
>> +
>> +          Please refer to the device documentation for global interface indexes.
>> +
>> +      cell 3: Channel number for the peripheral
>> +
>> +        Please refer to the device documentation for the channel map.
>> +
>> +      cell 4: ASEL value for the channel
>> +
>> +  interrupts:
>> +    minItems: 1
>> +    maxItems: 144
>> +    description:
>> +      Interrupts for DMA channels.
> And interrupts are flexible because?

I understand the issues now:

1. address-cells: remove this property - it should be a fixed hardware

   constant, not a binding property.

2. interrupts: replace minItems/maxItems ranges with a fixed count specific

   to ti,am62l-dmss-bcdma hardware.

The binding should encode hardware facts as fixed properties, not
flexible ranges.

I'll address both in v7. Please let me know if I still misunderstood
something.


Best regards

>
> Best regards,
> Krzysztof
>