diff mbox

[v7,1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation

Message ID 1461740729-30715-1-git-send-email-appanad@xilinx.com (mailing list archive)
State New, archived
Headers show

Commit Message

Appana Durga Kedareswara rao April 27, 2016, 7:05 a.m. UTC
Device-tree binding documentation for Xilinx zynqmp dma engine used in
Zynq UltraScale+ MPSoC.

Signed-off-by: Punnaiah Choudary Kalluri <punnaia@xilinx.com>
Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
---
Changes in v7:
- None.
Changes in v6:
- Removed desc-axi-cache/dst-axi-cache/src-axi-cache properties
  from the binding doc as it allow broken combinations when dma-coherent
  is set as suggested by Rob.
- Fixed minor comments given by Rob related coding(lower case DT node name).
Changes in v5:
- Use dma-coherent flag for coherent transfers as suggested by rob.
- Removed unnecessary properties from binding doc as suggested by Rob.
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- None.


 .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt  | 44 ++++++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt

Comments

Lars-Peter Clausen April 27, 2016, 7:11 a.m. UTC | #1
On 04/27/2016 09:05 AM, Kedareswara rao Appana wrote:
[...]
> +- xlnx,include-sg	: Indicates the controller to operate in simple or
> +			  scatter gather dma mode
> +- xlnx,ratectrl		: Scheduling interval in terms of clock cycles for
> +			  source AXI transaction
> +- xlnx,overfetch	: Tells whether the channel is allowed to over
> +			  fetch the data
> +- xlnx,src-issue	: Number of AXI outstanding transactions on source side
> +- xlnx,src-burst-len	: AXI length for data read. Support only power of
> +			  2 byte values.
> +- xlnx,dst-burst-len	: AXI length for data write. Support only power of

These are all software runtime configuration parameters that you'd want to
change at runtime depending on which peripheral you are targeting with a
specific DMA transfer. These really do not belong into the devicetree.
Appana Durga Kedareswara rao April 27, 2016, 7:33 a.m. UTC | #2
Hi Lars,

> -----Original Message-----
> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
> Sent: Wednesday, April 27, 2016 12:42 PM
> To: Appana Durga Kedareswara Rao <appanad@xilinx.com>;
> robh+dt@kernel.org; pawel.moll@arm.com; mark.rutland@arm.com;
> ijc+devicetree@hellion.org.uk; galak@codeaurora.org; Michal Simek
> <michals@xilinx.com>; Soren Brinkmann <sorenb@xilinx.com>;
> vinod.koul@intel.com; dan.j.williams@intel.com; Appana Durga Kedareswara
> Rao <appanad@xilinx.com>; moritz.fischer@ettus.com;
> laurent.pinchart@ideasonboard.com; luis@debethencourt.com; Anirudha
> Sarangi <anirudh@xilinx.com>; Punnaiah Choudary Kalluri
> <punnaia@xilinx.com>
> Cc: devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; dmaengine@vger.kernel.org
> Subject: Re: [PATCH v7 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma
> device tree binding documentation
> 
> On 04/27/2016 09:05 AM, Kedareswara rao Appana wrote:
> [...]
> > +- xlnx,include-sg	: Indicates the controller to operate in simple or
> > +			  scatter gather dma mode
> > +- xlnx,ratectrl		: Scheduling interval in terms of clock cycles for
> > +			  source AXI transaction
> > +- xlnx,overfetch	: Tells whether the channel is allowed to over
> > +			  fetch the data
> > +- xlnx,src-issue	: Number of AXI outstanding transactions on source
> side
> > +- xlnx,src-burst-len	: AXI length for data read. Support only power of
> > +			  2 byte values.
> > +- xlnx,dst-burst-len	: AXI length for data write. Support only power of
> 
> These are all software runtime configuration parameters that you'd want to
> change at runtime depending on which peripheral you are targeting with a
> specific DMA transfer. These really do not belong into the devicetree.

You mean to have a separate config structure in the driver and handle the above parameters
Through that structure???

I understand that above will work for slave dma transfer types what about memory to memory
Transfers where we don't have provision to the use this parameters...

Regards,
Kedar.
Lars-Peter Clausen April 27, 2016, 12:40 p.m. UTC | #3
On 04/27/2016 09:33 AM, Appana Durga Kedareswara Rao wrote:
> Hi Lars,
> 
>> -----Original Message-----
>> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
>> Sent: Wednesday, April 27, 2016 12:42 PM
>> To: Appana Durga Kedareswara Rao <appanad@xilinx.com>;
>> robh+dt@kernel.org; pawel.moll@arm.com; mark.rutland@arm.com;
>> ijc+devicetree@hellion.org.uk; galak@codeaurora.org; Michal Simek
>> <michals@xilinx.com>; Soren Brinkmann <sorenb@xilinx.com>;
>> vinod.koul@intel.com; dan.j.williams@intel.com; Appana Durga Kedareswara
>> Rao <appanad@xilinx.com>; moritz.fischer@ettus.com;
>> laurent.pinchart@ideasonboard.com; luis@debethencourt.com; Anirudha
>> Sarangi <anirudh@xilinx.com>; Punnaiah Choudary Kalluri
>> <punnaia@xilinx.com>
>> Cc: devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> kernel@vger.kernel.org; dmaengine@vger.kernel.org
>> Subject: Re: [PATCH v7 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma
>> device tree binding documentation
>>
>> On 04/27/2016 09:05 AM, Kedareswara rao Appana wrote:
>> [...]
>>> +- xlnx,include-sg	: Indicates the controller to operate in simple or
>>> +			  scatter gather dma mode
>>> +- xlnx,ratectrl		: Scheduling interval in terms of clock cycles for
>>> +			  source AXI transaction
>>> +- xlnx,overfetch	: Tells whether the channel is allowed to over
>>> +			  fetch the data
>>> +- xlnx,src-issue	: Number of AXI outstanding transactions on source
>> side
>>> +- xlnx,src-burst-len	: AXI length for data read. Support only power of
>>> +			  2 byte values.
>>> +- xlnx,dst-burst-len	: AXI length for data write. Support only power of
>>
>> These are all software runtime configuration parameters that you'd want to
>> change at runtime depending on which peripheral you are targeting with a
>> specific DMA transfer. These really do not belong into the devicetree.
> 
> You mean to have a separate config structure in the driver and handle the above parameters
> Through that structure???
> 
> I understand that above will work for slave dma transfer types what about memory to memory
> Transfers where we don't have provision to the use this parameters...

These parameters are just as application specific as e.g. the DMA
source/destination address or the DMA transfer length. If you want to use
the DMA controller in a different configuration you'd have to re-compile the
DTB and reboot your board, that is not really practical. Especially
considering that you'd typically have multiple applications using the DMA
controller in different configurations concurrently. In general if I have to
reconfigure the DT depending on what application software is running
something is fundamentally broken.

Derive these parameters at runtime depending on the requested transfer. E.g.
some transfer types only work in SG mode, others only work in non-SG modes.
For those which can work in both modes choose the one that is more
efficient. Similar for the other parameters.

- Lars
Appana Durga Kedareswara rao April 28, 2016, 9 a.m. UTC | #4
Hi Lars,

	Thanks for the review...

> -----Original Message-----
> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
> Sent: Wednesday, April 27, 2016 6:10 PM
> To: Appana Durga Kedareswara Rao <appanad@xilinx.com>;
> robh+dt@kernel.org; pawel.moll@arm.com; mark.rutland@arm.com;
> ijc+devicetree@hellion.org.uk; galak@codeaurora.org; Michal Simek
> <michals@xilinx.com>; Soren Brinkmann <sorenb@xilinx.com>;
> vinod.koul@intel.com; dan.j.williams@intel.com; moritz.fischer@ettus.com;
> laurent.pinchart@ideasonboard.com; luis@debethencourt.com; Anirudha
> Sarangi <anirudh@xilinx.com>; Punnaiah Choudary Kalluri
> <punnaia@xilinx.com>
> Cc: devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; dmaengine@vger.kernel.org
> Subject: Re: [PATCH v7 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma
> device tree binding documentation
> 
> On 04/27/2016 09:33 AM, Appana Durga Kedareswara Rao wrote:
> > Hi Lars,
> >
> >> -----Original Message-----
> >> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
> >> Sent: Wednesday, April 27, 2016 12:42 PM
> >> To: Appana Durga Kedareswara Rao <appanad@xilinx.com>;
> >> robh+dt@kernel.org; pawel.moll@arm.com; mark.rutland@arm.com;
> >> ijc+devicetree@hellion.org.uk; galak@codeaurora.org; Michal Simek
> >> <michals@xilinx.com>; Soren Brinkmann <sorenb@xilinx.com>;
> >> vinod.koul@intel.com; dan.j.williams@intel.com; Appana Durga
> >> Kedareswara Rao <appanad@xilinx.com>; moritz.fischer@ettus.com;
> >> laurent.pinchart@ideasonboard.com; luis@debethencourt.com; Anirudha
> >> Sarangi <anirudh@xilinx.com>; Punnaiah Choudary Kalluri
> >> <punnaia@xilinx.com>
> >> Cc: devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> >> linux- kernel@vger.kernel.org; dmaengine@vger.kernel.org
> >> Subject: Re: [PATCH v7 1/2] Documentation: DT: dma: Add Xilinx zynqmp
> >> dma device tree binding documentation
> >>
> >> On 04/27/2016 09:05 AM, Kedareswara rao Appana wrote:
> >> [...]
> >>> +- xlnx,include-sg	: Indicates the controller to operate in simple or
> >>> +			  scatter gather dma mode
> >>> +- xlnx,ratectrl		: Scheduling interval in terms of clock cycles for
> >>> +			  source AXI transaction
> >>> +- xlnx,overfetch	: Tells whether the channel is allowed to over
> >>> +			  fetch the data
> >>> +- xlnx,src-issue	: Number of AXI outstanding transactions on source
> >> side
> >>> +- xlnx,src-burst-len	: AXI length for data read. Support only power of
> >>> +			  2 byte values.
> >>> +- xlnx,dst-burst-len	: AXI length for data write. Support only power of
> >>
> >> These are all software runtime configuration parameters that you'd
> >> want to change at runtime depending on which peripheral you are
> >> targeting with a specific DMA transfer. These really do not belong into the
> devicetree.
> >
> > You mean to have a separate config structure in the driver and handle
> > the above parameters Through that structure???
> >
> > I understand that above will work for slave dma transfer types what
> > about memory to memory Transfers where we don't have provision to the use
> this parameters...
> 
> These parameters are just as application specific as e.g. the DMA
> source/destination address or the DMA transfer length. If you want to use the
> DMA controller in a different configuration you'd have to re-compile the DTB
> and reboot your board, that is not really practical. Especially considering that
> you'd typically have multiple applications using the DMA controller in different
> configurations concurrently. In general if I have to reconfigure the DT depending
> on what application software is running something is fundamentally broken.
> 
> Derive these parameters at runtime depending on the requested transfer. E.g.
> some transfer types only work in SG mode, others only work in non-SG modes.
> For those which can work in both modes choose the one that is more efficient.
> Similar for the other parameters.

Ok will fix in the next version...
Will use module_params for the above properties.

Regards,
Kedar.

> 
> - Lars
Lars-Peter Clausen April 28, 2016, 9:10 a.m. UTC | #5
On 04/28/2016 11:00 AM, Appana Durga Kedareswara Rao wrote:
> Hi Lars,
> 
> 	Thanks for the review...
> 
>> -----Original Message-----
>> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
>> Sent: Wednesday, April 27, 2016 6:10 PM
>> To: Appana Durga Kedareswara Rao <appanad@xilinx.com>;
>> robh+dt@kernel.org; pawel.moll@arm.com; mark.rutland@arm.com;
>> ijc+devicetree@hellion.org.uk; galak@codeaurora.org; Michal Simek
>> <michals@xilinx.com>; Soren Brinkmann <sorenb@xilinx.com>;
>> vinod.koul@intel.com; dan.j.williams@intel.com; moritz.fischer@ettus.com;
>> laurent.pinchart@ideasonboard.com; luis@debethencourt.com; Anirudha
>> Sarangi <anirudh@xilinx.com>; Punnaiah Choudary Kalluri
>> <punnaia@xilinx.com>
>> Cc: devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> kernel@vger.kernel.org; dmaengine@vger.kernel.org
>> Subject: Re: [PATCH v7 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma
>> device tree binding documentation
>>
>> On 04/27/2016 09:33 AM, Appana Durga Kedareswara Rao wrote:
>>> Hi Lars,
>>>
>>>> -----Original Message-----
>>>> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
>>>> Sent: Wednesday, April 27, 2016 12:42 PM
>>>> To: Appana Durga Kedareswara Rao <appanad@xilinx.com>;
>>>> robh+dt@kernel.org; pawel.moll@arm.com; mark.rutland@arm.com;
>>>> ijc+devicetree@hellion.org.uk; galak@codeaurora.org; Michal Simek
>>>> <michals@xilinx.com>; Soren Brinkmann <sorenb@xilinx.com>;
>>>> vinod.koul@intel.com; dan.j.williams@intel.com; Appana Durga
>>>> Kedareswara Rao <appanad@xilinx.com>; moritz.fischer@ettus.com;
>>>> laurent.pinchart@ideasonboard.com; luis@debethencourt.com; Anirudha
>>>> Sarangi <anirudh@xilinx.com>; Punnaiah Choudary Kalluri
>>>> <punnaia@xilinx.com>
>>>> Cc: devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>>>> linux- kernel@vger.kernel.org; dmaengine@vger.kernel.org
>>>> Subject: Re: [PATCH v7 1/2] Documentation: DT: dma: Add Xilinx zynqmp
>>>> dma device tree binding documentation
>>>>
>>>> On 04/27/2016 09:05 AM, Kedareswara rao Appana wrote:
>>>> [...]
>>>>> +- xlnx,include-sg	: Indicates the controller to operate in simple or
>>>>> +			  scatter gather dma mode
>>>>> +- xlnx,ratectrl		: Scheduling interval in terms of clock cycles for
>>>>> +			  source AXI transaction
>>>>> +- xlnx,overfetch	: Tells whether the channel is allowed to over
>>>>> +			  fetch the data
>>>>> +- xlnx,src-issue	: Number of AXI outstanding transactions on source
>>>> side
>>>>> +- xlnx,src-burst-len	: AXI length for data read. Support only power of
>>>>> +			  2 byte values.
>>>>> +- xlnx,dst-burst-len	: AXI length for data write. Support only power of
>>>>
>>>> These are all software runtime configuration parameters that you'd
>>>> want to change at runtime depending on which peripheral you are
>>>> targeting with a specific DMA transfer. These really do not belong into the
>> devicetree.
>>>
>>> You mean to have a separate config structure in the driver and handle
>>> the above parameters Through that structure???
>>>
>>> I understand that above will work for slave dma transfer types what
>>> about memory to memory Transfers where we don't have provision to the use
>> this parameters...
>>
>> These parameters are just as application specific as e.g. the DMA
>> source/destination address or the DMA transfer length. If you want to use the
>> DMA controller in a different configuration you'd have to re-compile the DTB
>> and reboot your board, that is not really practical. Especially considering that
>> you'd typically have multiple applications using the DMA controller in different
>> configurations concurrently. In general if I have to reconfigure the DT depending
>> on what application software is running something is fundamentally broken.
>>
>> Derive these parameters at runtime depending on the requested transfer. E.g.
>> some transfer types only work in SG mode, others only work in non-SG modes.
>> For those which can work in both modes choose the one that is more efficient.
>> Similar for the other parameters.
> 
> Ok will fix in the next version...
> Will use module_params for the above properties.

Sorry, but that is just as broken. You need to derive those parameters from
the DMA transfer as they are transfer specific.
Vinod Koul May 2, 2016, 10:09 a.m. UTC | #6
On Thu, Apr 28, 2016 at 11:10:34AM +0200, Lars-Peter Clausen wrote:
> >> -----Original Message-----
> >> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
> >> Sent: Wednesday, April 27, 2016 6:10 PM
> >> To: Appana Durga Kedareswara Rao <appanad@xilinx.com>;
> >> robh+dt@kernel.org; pawel.moll@arm.com; mark.rutland@arm.com;
> >> ijc+devicetree@hellion.org.uk; galak@codeaurora.org; Michal Simek
> >> <michals@xilinx.com>; Soren Brinkmann <sorenb@xilinx.com>;
> >> vinod.koul@intel.com; dan.j.williams@intel.com; moritz.fischer@ettus.com;
> >> laurent.pinchart@ideasonboard.com; luis@debethencourt.com; Anirudha
> >> Sarangi <anirudh@xilinx.com>; Punnaiah Choudary Kalluri
> >> <punnaia@xilinx.com>
> >> Cc: devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> >> kernel@vger.kernel.org; dmaengine@vger.kernel.org
> >> Subject: Re: [PATCH v7 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma
> >> device tree binding documentation
> >>
> >> On 04/27/2016 09:33 AM, Appana Durga Kedareswara Rao wrote:
> >>> Hi Lars,
> >>>
> >>>> -----Original Message-----
> >>>> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
> >>>> Sent: Wednesday, April 27, 2016 12:42 PM
> >>>> To: Appana Durga Kedareswara Rao <appanad@xilinx.com>;
> >>>> robh+dt@kernel.org; pawel.moll@arm.com; mark.rutland@arm.com;
> >>>> ijc+devicetree@hellion.org.uk; galak@codeaurora.org; Michal Simek
> >>>> <michals@xilinx.com>; Soren Brinkmann <sorenb@xilinx.com>;
> >>>> vinod.koul@intel.com; dan.j.williams@intel.com; Appana Durga
> >>>> Kedareswara Rao <appanad@xilinx.com>; moritz.fischer@ettus.com;
> >>>> laurent.pinchart@ideasonboard.com; luis@debethencourt.com; Anirudha
> >>>> Sarangi <anirudh@xilinx.com>; Punnaiah Choudary Kalluri
> >>>> <punnaia@xilinx.com>
> >>>> Cc: devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> >>>> linux- kernel@vger.kernel.org; dmaengine@vger.kernel.org
> >>>> Subject: Re: [PATCH v7 1/2] Documentation: DT: dma: Add Xilinx zynqmp

PLEASE strip the crap from your MUA, better use a linux MUA


> >>>>> +- xlnx,include-sg	: Indicates the controller to operate in simple or
> >>>>> +			  scatter gather dma mode
> >>>>> +- xlnx,ratectrl		: Scheduling interval in terms of clock cycles for
> >>>>> +			  source AXI transaction
> >>>>> +- xlnx,overfetch	: Tells whether the channel is allowed to over
> >>>>> +			  fetch the data
> >>>>> +- xlnx,src-issue	: Number of AXI outstanding transactions on source
> >>>> side
> >>>>> +- xlnx,src-burst-len	: AXI length for data read. Support only power of
> >>>>> +			  2 byte values.
> >>>>> +- xlnx,dst-burst-len	: AXI length for data write. Support only power of
> >>>>
> >>>> These are all software runtime configuration parameters that you'd
> >>>> want to change at runtime depending on which peripheral you are
> >>>> targeting with a specific DMA transfer. These really do not belong into the
> >> devicetree.
> >>>
> >>> You mean to have a separate config structure in the driver and handle
> >>> the above parameters Through that structure???
> >>>
> >>> I understand that above will work for slave dma transfer types what
> >>> about memory to memory Transfers where we don't have provision to the use
> >> this parameters...
> >>
> >> These parameters are just as application specific as e.g. the DMA
> >> source/destination address or the DMA transfer length. If you want to use the
> >> DMA controller in a different configuration you'd have to re-compile the DTB
> >> and reboot your board, that is not really practical. Especially considering that
> >> you'd typically have multiple applications using the DMA controller in different
> >> configurations concurrently. In general if I have to reconfigure the DT depending
> >> on what application software is running something is fundamentally broken.
> >>
> >> Derive these parameters at runtime depending on the requested transfer. E.g.
> >> some transfer types only work in SG mode, others only work in non-SG modes.
> >> For those which can work in both modes choose the one that is more efficient.
> >> Similar for the other parameters.
> > 
> > Ok will fix in the next version...
> > Will use module_params for the above properties.
> 
> Sorry, but that is just as broken. You need to derive those parameters from
> the DMA transfer as they are transfer specific.

Right, for memcpy you should derive the parameters. Frankly burst size
and lengths, rate control should be set to maximun to achives best
performance on mecpy.  People want memcpy to be done asap
Appana Durga Kedareswara rao May 3, 2016, 9:12 a.m. UTC | #7
Hi Vinod,

> 
> PLEASE strip the crap from your MUA, better use a linux MUA

OK will fix Sorry for the noise...

> 
> 
> > >>>>> +- xlnx,include-sg	: Indicates the controller to operate in simple
> or
> > >>>>> +			  scatter gather dma mode
> > >>>>> +- xlnx,ratectrl		: Scheduling interval in terms of clock cycles for
> > >>>>> +			  source AXI transaction
> > >>>>> +- xlnx,overfetch	: Tells whether the channel is allowed to over
> > >>>>> +			  fetch the data
> > >>>>> +- xlnx,src-issue	: Number of AXI outstanding transactions on source
> > >>>> side
> > >>>>> +- xlnx,src-burst-len	: AXI length for data read. Support only power
> of
> > >>>>> +			  2 byte values.
> > >>>>> +- xlnx,dst-burst-len	: AXI length for data write. Support only power
> of
> > >>>>
> > >>>> These are all software runtime configuration parameters that you'd
> > >>>> want to change at runtime depending on which peripheral you are
> > >>>> targeting with a specific DMA transfer. These really do not belong into

> > Sorry, but that is just as broken. You need to derive those parameters from
> > the DMA transfer as they are transfer specific.
> 
> Right, for memcpy you should derive the parameters. Frankly burst size
> and lengths, rate control should be set to maximun to achives best
> performance on mecpy.  People want memcpy to be done asap

Ok Will fix in the next version of the patch...

Regards,
Kedar.
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
new file mode 100644
index 0000000..f0f0b54
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
@@ -0,0 +1,44 @@ 
+Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
+memory to device and device to memory transfers. It also has flow
+control and rate control support for slave/peripheral dma access.
+
+Required properties:
+- compatible		: Should be "xlnx,zynqmp-dma-1.0"
+- reg			: Memory map for gdma/adma module access.
+- interrupt-parent	: Interrupt controller the interrupt is routed through
+- interrupts		: Should contain DMA channel interrupt.
+- xlnx,bus-width	: Axi buswidth in bits. Should contain 128 or 64
+- clock-names		: List of input clocks "clk_main", "clk_apb"
+			  (see clock bindings for details)
+
+Optional properties:
+- xlnx,include-sg	: Indicates the controller to operate in simple or
+			  scatter gather dma mode
+- xlnx,ratectrl		: Scheduling interval in terms of clock cycles for
+			  source AXI transaction
+- xlnx,overfetch	: Tells whether the channel is allowed to over
+			  fetch the data
+- xlnx,src-issue	: Number of AXI outstanding transactions on source side
+- xlnx,src-burst-len	: AXI length for data read. Support only power of
+			  2 byte values.
+- xlnx,dst-burst-len	: AXI length for data write. Support only power of
+			  2 byte values.
+- dma-coherent		: Present if dma operations are coherent.
+
+Example:
+++++++++
+fpd_dma_chan1: dma@fd500000 {
+	compatible = "xlnx,zynqmp-dma-1.0";
+	reg = <0x0 0xFD500000 0x1000>;
+	interrupt-parent = <&gic>;
+	interrupts = <0 117 4>;
+	clock-names = "clk_main", "clk_apb";
+	xlnx,bus-width = <128>;
+	xlnx,include-sg;
+	xlnx,overfetch;
+	dma-coherent;
+	xlnx,ratectrl = <0>;
+	xlnx,src-issue = <16>;
+	xlnx,src-burst-len = <4>;
+	xlnx,dst-burst-len = <4>;
+};