16 Nov, 2015

1 commit

  • dma_addr_t may be defined as 32 or 64 bit depending on configuration,
    so it cannot be printed using the normal format strings, as
    gcc correctly warns:

    drivers/dma/at_hdmac.c: In function 'atc_prep_dma_interleaved':
    drivers/dma/at_hdmac.c:731:28: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]

    This changes the format strings to use the special "%pad" format
    string that prints a dma_addr_t, and changes the arguments so we
    pass the address by reference as required.

    Signed-off-by: Arnd Bergmann
    Acked-by: Nicolas Ferre
    Signed-off-by: Vinod Koul

    Arnd Bergmann
     

29 Oct, 2015

1 commit


05 Sep, 2015

1 commit

  • Pull dmaengine updates from Vinod Koul:
    "This time we have aded a new capability for scatter-gathered memset
    using dmaengine APIs. This is supported in xdmac & hdmac drivers

    We have added support for reusing descriptors for examples like video
    buffers etc. Driver will follow

    The behaviour of descriptor ack has been clarified and documented

    New devices added are:
    - dma controller in sun[457]i SoCs
    - lpc18xx dmamux
    - ZTE ZX296702 dma controller
    - Analog Devices AXI-DMAC DMA controller
    - eDMA support for dma-crossbar
    - imx6sx support in imx-sdma driver
    - imx-sdma device to device support

    Other:
    - jz4780 fixes
    - ioatdma large refactor and cleanup for removal of ioat v1 and v2
    which is deprecated and fixes
    - ACPI support in X-Gene DMA engine driver
    - ipu irq fixes
    - mvxor fixes
    - minor fixes spread thru drivers"

    [ The Kconfig and Makefile entries got re-sorted alphabetically, and I
    handled the conflict with the new Intel integrated IDMA driver by
    slightly mis-sorting it on purpose: "IDMA64" got sorted after "IMX" in
    order to keep the Intel entries together. I think it might be a good
    idea to just rename the IDMA64 config entry to INTEL_IDMA64 to make
    the sorting be a true sort, not this mismash.

    Also, this merge disables the COMPILE_TEST for the sun4i DMA
    controller, because it does not compile cleanly at all. - Linus ]

    * tag 'dmaengine-4.3-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (89 commits)
    dmaengine: ioatdma: add Broadwell EP ioatdma PCI dev IDs
    dmaengine :ipu: change ipu_irq_handler() to remove compile warning
    dmaengine: ioatdma: Fix variable array length
    dmaengine: ioatdma: fix sparse "error" with prep lock
    dmaengine: hdmac: Add memset capabilities
    dmaengine: sort the sh Makefile
    dmaengine: sort the sh Kconfig
    dmaengine: sort the dw Kconfig
    dmaengine: sort the Kconfig
    dmaengine: sort the makefile
    drivers/dma: make mv_xor.c driver explicitly non-modular
    dmaengine: Add support for the Analog Devices AXI-DMAC DMA controller
    devicetree: Add bindings documentation for Analog Devices AXI-DMAC
    dmaengine: xgene-dma: Fix the lock to allow client for further submission of requests
    dmaengine: ioatdma: fix coccinelle warning
    dmaengine: ioatdma: fix zero day warning on incompatible pointer type
    dmaengine: tegra-apb: Simplify locking for device using global pause
    dmaengine: tegra-apb: Remove unnecessary return statements and variables
    dmaengine: tegra-apb: Avoid unnecessary channel base address calculation
    dmaengine: tegra-apb: Remove unused variables
    ...

    Linus Torvalds
     

26 Aug, 2015

1 commit

  • Just like for the XDMAC, the SoCs that embed the HDMAC don't have any kind
    of GPU, and need to accelerate a few framebuffer-related operations through
    their DMA controller.

    However, unlike the XDMAC, the HDMAC doesn't have the memset capability
    built-in. That can be easily emulated though, by doing a transfer with a
    fixed address on the variable that holds the value we want to set.

    Signed-off-by: Maxime Ripard
    Signed-off-by: Vinod Koul

    Maxime Ripard
     

31 Jul, 2015

1 commit

  • As claimed by the programmer datasheet and confirmed by the IP designer,
    the Block Transfer Size (BTSIZE) bitfield of the Channel x Control A
    Register (CTRLAx) always refers to a number of Source Width (SRC_WIDTH)
    transfers.

    Both the SRC_WIDTH and BTSIZE bitfields can be extacted from the CTRLAx
    register to compute the DMA residue. So the 'tx_width' field is useless
    and can be removed from the struct at_desc.

    Before this patch, atc_prep_slave_sg() was not consistent: BTSIZE was
    correctly initialized according to the SRC_WIDTH but 'tx_width' was always
    set to reg_width, which was incorrect for MEM_TO_DEV transfers. It led to
    bad DMA residue when 'tx_width' != SRC_WIDTH.

    Also the 'tx_width' field was mostly set only in the first and last
    descriptors. Depending on the kind of DMA transfer, this field remained
    uninitialized for intermediate descriptors. The accurate DMA residue was
    computed only when the currently processed descriptor was the first or the
    last of the chain. This algorithm was a little bit odd. An accurate DMA
    residue can always be computed using the SRC_WIDTH and BTSIZE bitfields
    in the CTRLAx register.

    Finally, the test to check whether the currently processed descriptor is
    the last of the chain was wrong: for cyclic transfer, last_desc->lli.dscr
    is NOT equal to zero, since set_desc_eol() is never called, but logically
    equal to first_desc->txd.phys. This bug has a side effect on the
    drivers/tty/serial/atmel_serial.c driver, which uses cyclic DMA transfer
    to receive data. Since the DMA residue was wrong each time the DMA
    transfer reaches the second (and last) period of the transfer, no more
    data were received by the USART driver till the cyclic DMA transfer loops
    back to the first period.

    Signed-off-by: Cyrille Pitchen
    Acked-by: Torsten Fleischer
    Tested-by: Jirí Prchal
    Acked-by: Nicolas Ferre
    Signed-off-by: Vinod Koul

    Cyrille Pitchen
     

12 Jun, 2015

1 commit

  • The AT91 HDMAC controller supports interleaved transfers through what's
    called the Picture-in-Picture mode, which allows to transfer a squared
    portion of a framebuffer.

    This means that this interleaved transfer only supports interleaved
    transfers which have a transfer size and ICGs that are fixed across all the
    chunks.

    While this is a quite drastic restriction of the interleaved transfers
    compared to what the dmaengine API allows, this is still useful, and our
    driver will only reject transfers that do not conform to this.

    Signed-off-by: Maxime Ripard
    Acked-by: Ludovic Desroches
    Signed-off-by: Vinod Koul

    Maxime Ripard
     

13 Mar, 2015

1 commit

  • This patch fixes the following issues regarding to the calculation of the
    residue:

    1. The residue is always calculated for the current transfer even if the
    cookie is associated to a pending transfer.

    2. For scatter/gather DMA the calculation of the residue for the current
    transfer doesn't include the bytes of the child descriptors that are already
    transferred.
    It only calculates the difference between the transfer's total length minus
    the number of bytes that are already transferred for the current child
    descriptor.
    For example: There is a scatter/gather DMA transfer with a total length of
    1 MByte. Getting the residue several times while the transfer is running shows
    something like that:

    1: residue = 975584
    2: residue = 1002766
    3: residue = 992627
    4: residue = 983767
    5: residue = 985694
    6: residue = 1008094
    7: residue = 1009741
    8: residue = 1011195

    3. The driver stores the residue but never resets it when starting a new
    transfer.
    For example: If there are two subsequent DMA transfers. The first one with
    a total length of 1 MByte and the second one with a total length of 1 kByte.
    Getting the residue for both transfers shows something like that:

    transfer 1: residue = 975584
    transfer 2: residue = 1048380

    Changes from V1:
    * Fixed coding style of the multi-line comments.
    * Improved accuracy of the residue calculation when the transfer for the
    first descriptor is active.

    Changes from V2:
    * Member 'tx_width' of 'struct at_desc' restored, because the transfer width
    can't be derived from the source width when using "slave_sg".
    The transfer width is needed for the calculation of the residue if either
    the transfer of the first or the last descriptor is in progress.
    In the case of a "memory_to_memory_sg" transfer (part of this patch
    series) the transfer width of both descriptors may differ. Thus it is
    required to additionally set 'tx_width' of the last descriptor.
    * Added functions for multiply used calculations.

    Signed-off-by: Torsten Fleischer
    Acked-by: Nicolas Ferre
    Signed-off-by: Vinod Koul

    Torsten Fleischer
     

22 Dec, 2014

1 commit


13 Dec, 2013

1 commit

  • commit 54f8d501e8428 ('dmaengine: remove DMA unmap from drivers')
    refactored some code which resulted in an unused function in the at_hdmac
    driver:

    drivers/dma/at_hdmac_regs.h:350:23: warning: 'chan2parent' defined but
    not used [-Wunused-function]

    Fixes: 54f8d501e8428 ('dmaengine: remove DMA unmap from drivers')
    Signed-off-by: Olof Johansson
    Cc: Bartlomiej Zolnierkiewicz
    Acked-by: Nicolas Ferre
    Acked-by: Bartlomiej Zolnierkiewicz
    Acked-by: Vinod Koul
    Signed-off-by: Dan Williams

    Olof Johansson
     

05 Jul, 2013

2 commits

  • Add support for returning the residue for current transfer cookie by
    reading the transfered buffer size(BTSIZE) in CTRLA register.

    For a single buffer cookie, the descriptor length minus BTSIZE
    can get the residue.

    For a lli cookie, remain_desc will record remain descriptor length
    when last descriptor finish, the remain_desc minus BTSIZE can get the
    current residue.

    If the cookie has completed successfully, the residue will be zero.
    If the cookie is in progress, it will be the number of bytes yet to be transferred.
    If get residue error, the cookie will be turn into error status.

    Check dma fifo to see if data remain, let issue pending finish remain work if there is.
    Signed-off-by: Elen Song
    Signed-off-by: Vinod Koul

    Elen Song
     
  • In one dma transfer, the data transfer width can be configured and it is limited by source or destination peripheral width,
    tx_width will save the transfer width, but for memcpy, either source or destination transfer width is taken as tx_width.

    Signed-off-by: Elen Song
    Signed-off-by: Vinod Koul

    Elen Song
     

30 Apr, 2013

1 commit

  • Update at_hdmac driver to support generic DMA device tree binding. Devices
    can still request channel with dma_request_channel() then it doesn't break
    DMA for non DT boards.

    Signed-off-by: Ludovic Desroches
    Acked-by: Nicolas Ferre
    Acked-by: Jean-Christophe PLAGNIOL-VILLARD
    Acked-by: Arnd Bergmann
    Signed-off-by: Vinod Koul

    Ludovic Desroches
     

08 Jan, 2013

1 commit


14 Sep, 2012

1 commit

  • Platform data for device drivers should be defined in
    include/linux/platform_data/*.h, not in the architecture
    and platform specific directories.

    This moves such data out of the at91 include directories

    Signed-off-by: Arnd Bergmann
    Acked-by: Mark Brown
    Acked-by: Greg Kroah-Hartman
    Acked-by: Nicolas Pitre
    Acked-by: Nicolas Ferre
    Acked-by: Vinod Koul
    Cc: Jean-Christophe Plagniol-Villard
    Cc: Dan Williams

    Arnd Bergmann
     

15 May, 2012

1 commit

  • The maxburst/chunk size was taken from the private slave DMA data structure.
    Use the common API provided by DMA_SLAVE_CONFIG to setup src/dst maxburst
    values.
    The ctrla field is not needed anymore in the slave private structure nor the
    header constants that were located in an architecture specific directory.
    The at91sam9g45_devices.c file that was using this platform data is also
    modified to remove this now useless data.

    Signed-off-by: Nicolas Ferre
    Signed-off-by: Vinod Koul

    Nicolas Ferre
     

21 Mar, 2012

1 commit

  • This patch introduces DMA_SLAVE_CONFIG to at_hdmac Atmel DMA driver.

    It is needed to fix a regression in the use of atmel-mci.c driver on Atmel
    AT91 platforms brouth by e2b35f3:
    "dmaengine/dw_dmac: Fix dw_dmac user drivers to adapt to slave_config changes"

    We remove some parts of the private structure "at_dma_slave" and use the
    information provided by "struct dma_slave_config": source/destination
    peripheral registers and access width.

    AT_DMA_SLAVE_WIDTH_* values used previously are not needed anymore as we
    now use the standard ones. Although some conversion functions are needed to
    match register expected values.

    Some AT91 sub-architecture specific files are slightly touched by this patch
    but it cannot be split because it can break compilation.

    Signed-off-by: Nicolas Ferre
    Signed-off-by: Vinod Koul

    Nicolas Ferre
     

13 Mar, 2012

1 commit


31 Jan, 2012

1 commit

  • commit 463894705e4089d0ff69e7d877312d496ac70e5b deleted redundant
    chan_id and chancnt initialization in dma drivers as this is done
    in dma_async_device_register().

    However, atc_enable_irq() relied on chan_id set before registering
    the device, what left only channel 0 functional for this driver.

    This patch introduces atc_enable/disable_chan_irq() as a variant
    of atc_enable/disable_irq() with the channel as explicit argument.

    Signed-off-by: Nikolaus Voss
    Signed-off-by: Nicolas Ferre
    Cc: stable
    Signed-off-by: Vinod Koul

    Nikolaus Voss
     

28 Nov, 2011

1 commit


10 Nov, 2011

1 commit

  • We remove the use of platform data from DMA controller driver.
    We now use of .id_table to distinguish between compatible
    types. The two implementations allow to determine the
    number of channels and the capabilities of the controller.

    Signed-off-by: Nicolas Ferre
    Acked-by: Grant Likely
    Signed-off-by: Vinod Koul

    Nicolas Ferre
     

19 Aug, 2011

2 commits


09 May, 2011

1 commit


02 May, 2011

3 commits


09 Sep, 2009

1 commit


23 Jul, 2009

2 commits

  • This patch for at_hdmac adds the slave transfers capability to the Atmel DMA
    controller available on some AT91 SOCs. This allow peripheral to memory and
    memory to peripheral transfers with hardware handshaking.

    Slave structure for controller specific information is passed through channel
    private data. This at_dma_slave structure is defined in at_hdmac.h header file
    and relative hardware definition are moved to this file from at_hdmac_regs.h.
    Doing this we allow the channel configuration from platform definition code.

    This work is intensively based on dw_dmac and several slave implementations.

    Signed-off-by: Nicolas Ferre
    Signed-off-by: Dan Williams

    Nicolas Ferre
     
  • This AHB DMA Controller (aka HDMA or DMAC on AT91 systems) is availlable on
    at91sam9rl chip. It will be used on other products in the future.

    This first release covers only the memory-to-memory tranfer type. This is the
    only tranfer type supported by this chip. On other products, it will be used
    also for peripheral DMA transfer (slave API support to come).

    I used dmatest client without problem in different configurations to test it.

    Full documentation for this controller can be found in the SAM9RL datasheet:
    http://www.atmel.com/dyn/products/product_card.asp?part_id=4243

    Signed-off-by: Nicolas Ferre
    Acked-by: Maciej Sosnowski
    Signed-off-by: Dan Williams

    Nicolas Ferre