On Fri, Apr 22, 2016 at 12:36 AM, Appana Durga Kedareswara Rao <[email protected]> wrote: > Hi Rob, > > Thanks for the review... > >> -----Original Message----- >> From: Rob Herring [mailto:[email protected]] >> Sent: Thursday, April 21, 2016 7:12 PM >> To: Appana Durga Kedareswara Rao <[email protected]> >> Cc: [email protected]; [email protected]; >> [email protected]; [email protected]; Michal Simek >> <[email protected]>; Soren Brinkmann <[email protected]>; >> [email protected]; [email protected]; Appana Durga Kedareswara >> Rao <[email protected]>; [email protected]; >> [email protected]; [email protected]; Anirudha >> Sarangi <[email protected]>; Punnaiah Choudary Kalluri >> <[email protected]>; [email protected]; linux-arm- >> [email protected]; [email protected]; >> [email protected] >> Subject: Re: [PATCH v6 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma >> device tree binding documentation >> >> On Fri, Apr 15, 2016 at 02:22:53PM +0530, Kedareswara rao Appana wrote: >> > Device-tree binding documentation for Xilinx zynqmp dma engine used in >> > Zynq UltraScale+ MPSoC. >> > >> > Signed-off-by: Punnaiah Choudary Kalluri <[email protected]> >> > Signed-off-by: Kedareswara rao Appana <[email protected]> >> > --- >> > 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 >> > >> > 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 >> >> I think how this is getting used by the driver is wrong. >> {src,dst}_addr_widths are supposed to be a bitmask of supported slave >> device register widths. You aren't doing a bitmask and you are also >> saying you only support slaves with 8 or 16 byte data registers which is >> somewhat rare. It may happen to work because 128/8 == BIT(4). However, >> the documentation for the field is contradictory in that it says 1,2,4 >> or 8 byte widths are supported, but the enum has more sizes. > > > The DMA supports an AXI bus width of 128/64 bits only. > Please refer IP data sheet. > http://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf > Page No: 359(DMA Over fetch section).
I understand that. That should not really matter if the AXI master properly sets byte lane strobes other than defining max burst length which you already have defined elsewhere. > That's why during probe we are making the dma_device supported source and > destination address widths accordingly based on the DT property. > > Snap shot of driver code from the probe: > struct dma_device *p; > p->dst_addr_widths = zdev->chan->bus_width / 8; > p->src_addr_widths = zdev->chan->bus_width / 8; Read what I wrote before and read the documentation for these fields. They are bitmasks. Rob
