1. 14 9月, 2012 1 次提交
    • Z
      dmaengine: mmp-pdma support · c8acd6aa
      Zhangfei Gao 提交于
      1. virtual channel vs. physical channel
      Virtual channel is managed by dmaengine
      Physical channel handling resource, such as irq
      Physical channel is alloced dynamically as descending priority,
      freed immediately when irq done.
      The availble highest priority physically channel will alwayes be alloced
      
      Issue pending list -> alloc highest dma physically channel available -> dma done -> free physically channel
      
      2. list: running list & pending list
      submit: desc list -> pending list
      issue_pending_list: if (IDLE) pending list -> running list; free pending list (RUN)
      irq: free running list (IDLE)
           check pendlist -> pending list -> running list; free pending list (RUN)
      
      3. irq:
      Each list generate one irq, calling callback
      One list may contain several desc chain, in such case, make sure only the last desc list generate irq.
      
      4. async
      Submit will add desc chain to pending list, which can be multi-called
      If multi desc chain is submitted, only the last desc would generate irq -> call back
      If IDLE, issue_pending_list start pending_list, transforming pendlist to running list
      If RUN, irq will start pending list
      
      5. test
      5.1 pxa3xx_nand on pxa910
      5.2 insmod dmatest.ko (threads_per_chan=y)
      By default drivers/dma/dmatest.c test every channel and test memcpy with 1 threads per channel
      Signed-off-by: NZhangfei Gao <zhangfei.gao@marvell.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
      c8acd6aa
  2. 01 9月, 2012 1 次提交
  3. 31 7月, 2012 1 次提交
  4. 13 7月, 2012 1 次提交
  5. 01 7月, 2012 1 次提交
  6. 20 6月, 2012 1 次提交
  7. 08 6月, 2012 1 次提交
  8. 07 3月, 2012 1 次提交
    • R
      DMA: sa11x0: add SA-11x0 DMA driver · 6365bead
      Russell King 提交于
      Add support for the SA-11x0 DMA driver, which replaces the private
      API version in arch/arm/mach-sa1100/dma.c.
      
      We model this as a set of virtual DMA channels, one for each request
      signal, and assign the virtual DMA channel to a physical DMA channel
      when there is work to be done.  This allows DMA users to claim their
      channels, and hold them while not in use, without affecting the
      availability of the physical channels.
      
      Another advantage over this approach, compared to the private version,
      is that a channel can be reconfigured on the fly without having to
      release and re-request it - which for the IrDA driver, allows us to
      use DMA for SIR mode transmit without eating up three physical
      channels.  As IrDA is half-duplex, we actually only need one physical
      channel, and this architecture allows us to achieve that.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6365bead
  9. 18 11月, 2011 1 次提交
  10. 09 6月, 2011 1 次提交
  11. 06 6月, 2011 1 次提交
  12. 17 3月, 2011 1 次提交
  13. 02 3月, 2011 1 次提交
    • S
      dmaengine: mxs-dma: add dma support for i.MX23/28 · a580b8c5
      Shawn Guo 提交于
      This patch adds dma support for Freescale MXS-based SoC i.MX23/28,
      including apbh-dma and apbx-dma.
      
      * apbh-dma and apbx-dma are supported in the driver as two mxs-dma
        instances.
      
      * apbh-dma is different between mx23 and mx28, hardware version
        register is used to differentiate.
      
      * mxs-dma supports pio function besides data transfer.  The driver
        uses dma_data_direction DMA_NONE to identify the pio mode, and
        steals sgl and sg_len to get pio words and numbers from clients.
      
      * mxs dmaengine has some very specific features, like sense function
        and the special NAND support (nand_lock, nand_wait4ready).  These
        are too specific to implemented in generic dmaengine driver.
      
      * The driver refers to imx-sdma and only a single descriptor is
        statically assigned to each channel.
      Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      a580b8c5
  14. 03 12月, 2010 1 次提交
  15. 08 10月, 2010 1 次提交
  16. 06 10月, 2010 1 次提交
    • S
      dmaengine: Add Freescale i.MX SDMA support · 1ec1e82f
      Sascha Hauer 提交于
      This patch adds support for the Freescale i.MX SDMA engine.
      
      The SDMA engine is a scatter/gather DMA engine which is implemented
      as a seperate coprocessor. SDMA needs its own firmware which is
      requested using the standard request_firmware mechanism. The firmware
      has different entry points for each peripheral type, so drivers
      have to pass the peripheral type to the DMA engine which in turn
      picks the correct firmware entry point from a table contained in
      the firmware image itself.
      The original Freescale code also supports support for transfering
      data to the internal SRAM which needs different entry points to
      the firmware. Support for this is currently not implemented. Also,
      support for the ASRC (asymmetric sample rate converter) is skipped.
      
      I took a very simple approach to implement dmaengine support. Only
      a single descriptor is statically assigned to a each channel. This
      means that transfers can't be queued up but only a single transfer
      is in progress. This simplifies implementation a lot and is sufficient
      for the usual device/memory transfers.
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      Reviewed-by: NLinus Walleij <linus.ml.walleij@gmail.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      1ec1e82f
  17. 30 9月, 2010 1 次提交
    • L
      dmaengine: driver for the ARM PL080/PL081 PrimeCells v5 · e8689e63
      Linus Walleij 提交于
      This creates a DMAengine driver for the ARM PL080/PL081 PrimeCells
      based on the implementation earlier submitted by Peter Pearse.
      This is working like a charm for memcpy and slave DMA to the PL011
      PrimeCell on the PB11MPCore.
      
      This DMA controller is used in mostly unmodified form in the ARM
      RealView and Versatile platforms, in the ST-Ericsson Nomadik, and
      in the ST SPEAr platform.
      
      It has been converted to use the header from the Samsung PL080
      derivate instead of its own defintions. The Samsungs have a custom
      driver in their mach-* folders though, atleast we can share the
      register definitions.
      
      Cc: Peter Pearse <peter.pearse@arm.com>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: Alessandro Rubini <rubini@unipv.it>
      Acked-by: NViresh Kumar <viresh.kumar@st.com>
      Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
      [GFP_KERNEL to GFP_NOWAIT in pl08x_prep_dma_memcpy]
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      e8689e63
  18. 05 8月, 2010 1 次提交
  19. 28 7月, 2010 1 次提交
    • V
      intel_mid: Add Mrst & Mfld DMA Drivers · b3c567e4
      Vinod Koul 提交于
      This patch add DMA drivers for DMA controllers in Langwell chipset
      of Intel(R) Moorestown platform and DMA controllers in Penwell of
      Intel(R) Medfield platfrom
      
      This patch adds support for Moorestown DMAC1 and DMAC2 controllers.
      It also add support for Medfiled GP DMA and DMAC1 controllers.
      These controllers supports memory to peripheral and peripheral to
      memory transfers. It support only single block transfers.
      
      This driver is based on Kernel DMA engine
      Anyone who wishes to use this controller should use DMA engine APIs
      
      This controller exposes DMA_SLAVE capabilities and notifies the client drivers
      of DMA transaction completion
      
      Config option required to be enabled CONFIG_INTEL_MID_DMAC=y
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      b3c567e4
  20. 24 5月, 2010 1 次提交
  21. 15 4月, 2010 1 次提交
  22. 26 3月, 2010 1 次提交
  23. 02 3月, 2010 2 次提交
  24. 12 12月, 2009 1 次提交
  25. 20 11月, 2009 1 次提交
  26. 09 9月, 2009 1 次提交
  27. 29 7月, 2009 1 次提交
  28. 23 7月, 2009 1 次提交
  29. 17 6月, 2009 1 次提交
  30. 20 1月, 2009 1 次提交
    • G
      i.MX31: Image Processing Unit DMA and IRQ drivers · 5296b56d
      Guennadi Liakhovetski 提交于
      i.MX3x SoCs contain an Image Processing Unit, consisting of a Control
      Module (CM), Display Interface (DI), Synchronous Display Controller (SDC),
      Asynchronous Display Controller (ADC), Image Converter (IC), Post-Filter
      (PF), Camera Sensor Interface (CSI), and an Image DMA Controller (IDMAC).
      CM contains, among other blocks, an Interrupt Generator (IG) and a Clock
      and Reset Control Unit (CRCU). This driver serves IDMAC and IG. They are
      supported over dmaengine and irq-chip APIs respectively.
      
      IDMAC is a specialised DMA controller, its DMA channels cannot be used for
      general-purpose operations, even though it might be possible to configure
      a memory-to-memory channel for memcpy operation. This driver will not work
      with generic dmaengine clients, clients, wishing to use it must use
      respective wrapper structures, they also must specify which channels they
      require, as channels are hard-wired to specific IPU functions.
      Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NGuennadi Liakhovetski <lg@denx.de>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      5296b56d
  31. 09 7月, 2008 3 次提交
    • H
      dmaengine: Driver for the Synopsys DesignWare DMA controller · 3bfb1d20
      Haavard Skinnemoen 提交于
      This adds a driver for the Synopsys DesignWare DMA controller (aka
      DMACA on AVR32 systems.) This DMA controller can be found integrated
      on the AT32AP7000 chip and is primarily meant for peripheral DMA
      transfer, but can also be used for memory-to-memory transfers.
      
      This patch is based on a driver from David Brownell which was based on
      an older version of the DMA Engine framework. It also implements the
      proposed extensions to the DMA Engine API for slave DMA operations.
      
      The dmatest client shows no problems, but there may still be room for
      improvement performance-wise. DMA slave transfer performance is
      definitely "good enough"; reading 100 MiB from an SD card running at ~20
      MHz yields ~7.2 MiB/s average transfer rate.
      
      Full documentation for this controller can be found in the Synopsys
      DW AHB DMAC Databook:
      
      http://www.synopsys.com/designware/docs/iip/DW_ahb_dmac/latest/doc/dw_ahb_dmac_db.pdf
      
      The controller has lots of implementation options, so it's usually a
      good idea to check the data sheet of the chip it's intergrated on as
      well. The AT32AP7000 data sheet can be found here:
      
      http://www.atmel.com/dyn/products/datasheets.asp?family_id=682
      
      
      Changes since v4:
        * Use client_count instead of dma_chan_is_in_use()
        * Add missing include
        * Unmap buffers unless client told us not to
      
      Changes since v3:
        * Update to latest DMA engine and DMA slave APIs
        * Embed the hw descriptor into the sw descriptor
        * Clean up and update MODULE_DESCRIPTION, copyright date, etc.
      
      Changes since v2:
        * Dequeue all pending transfers in terminate_all()
        * Rename dw_dmac.h -> dw_dmac_regs.h
        * Define and use controller-specific dma_slave data
        * Fix up a few outdated comments
        * Define hardware registers as structs (doesn't generate better
          code, unfortunately, but it looks nicer.)
        * Get number of channels from platform_data instead of hardcoding it
          based on CONFIG_WHATEVER_CPU.
        * Give slave clients exclusive access to the channel
      
      Acked-by: Maciej Sosnowski <maciej.sosnowski@intel.com>,
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      3bfb1d20
    • H
      dmatest: Simple DMA memcpy test client · 4a776f0a
      Haavard Skinnemoen 提交于
      This client tests DMA memcpy using various lengths and various offsets
      into the source and destination buffers. It will initialize both
      buffers with a repeatable pattern and verify that the DMA engine copies
      the requested region and nothing more. It will also verify that the
      bytes aren't swapped around, and that the source buffer isn't modified.
      
      The dmatest module can be configured to test a specific device, a
      specific channel. It can also test multiple channels at the same time,
      and it can start multiple threads competing for the same channel.
      
      Changes since v2:
        * Support testing multiple channels at the same time
        * Support testing with multiple threads competing for the same channel
        * Use counting test patterns in order to catch byte ordering issues
      
      Changes since v1:
        * Remove extra dashes around "help"
        * Remove "default n" from Kconfig
        * Turn TEST_BUF_SIZE into a module parameter
        * Return DMA_NAK instead of DMA_DUP
        * Print unhandled events
        * Support testing specific channels and devices
        * Move to the end of the Makefile
      Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      4a776f0a
    • S
      dmaengine: DMA engine driver for Marvell XOR engine · ff7b0479
      Saeed Bishara 提交于
      The XOR engine found in Marvell's SoCs and system controllers
      provides XOR and DMA operation, iSCSI CRC32C calculation, memory
      initialization, and memory ECC error cleanup operation support.
      
      This driver implements the DMA engine API and supports the following
      capabilities:
      - memcpy
      - xor
      - memset
      
      The XOR engine can be used by DMA engine clients implemented in the
      kernel, one of those clients is the RAID module.  In that case, I
      observed 20% improvement in the raid5 write throughput, and 40%
      decrease in the CPU utilization when doing array construction, those
      results obtained on an 5182 running at 500Mhz.
      
      When enabling the NET DMA client, the performance decreased, so
      meanwhile it is recommended to keep this client off.
      Signed-off-by: NSaeed Bishara <saeed@marvell.com>
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      ff7b0479
  32. 05 3月, 2008 1 次提交
  33. 17 10月, 2007 3 次提交
  34. 13 7月, 2007 1 次提交
    • D
      dmaengine: driver for the iop32x, iop33x, and iop13xx raid engines · c2110923
      Dan Williams 提交于
      The Intel(R) IOP series of i/o processors integrate an Xscale core with
      raid acceleration engines.  The capabilities per platform are:
      
      iop219:
       (2) copy engines
      iop321:
       (2) copy engines
       (1) xor and block fill engine
      iop33x:
       (2) copy and crc32c engines
       (1) xor, xor zero sum, pq, pq zero sum, and block fill engine
      iop34x (iop13xx):
       (2) copy, crc32c, xor, xor zero sum, and block fill engines
       (1) copy, crc32c, xor, xor zero sum, pq, pq zero sum, and block fill engine
      
      The driver supports the features of the async_tx api:
      * asynchronous notification of operation completion
      * implicit (interupt triggered) handling of inter-channel transaction
        dependencies
      
      The driver adapts to the platform it is running by two methods.
      1/ #include <asm/arch/adma.h> which defines the hardware specific
         iop_chan_* and iop_desc_* routines as a series of static inline
         functions
      2/ The private platform data attached to the platform_device defines the
         capabilities of the channels
      
      20070626: Callbacks are run in a tasklet.  Given the recent discussion on
      LKML about killing tasklets in favor of workqueues I did a quick conversion
      of the driver.  Raid5 resync performance dropped from 50MB/s to 30MB/s, so
      the tasklet implementation remains until a generic softirq interface is
      available.
      
      Changelog:
      * fixed a slot allocation bug in do_iop13xx_adma_xor that caused too few
      slots to be requested eventually leading to data corruption
      * enabled the slot allocation routine to attempt to free slots before
      returning -ENOMEM
      * switched the cleanup routine to solely use the software chain and the
      status register to determine if a descriptor is complete.  This is
      necessary to support other IOP engines that do not have status writeback
      capability
      * make the driver iop generic
      * modified the allocation routines to understand allocating a group of
      slots for a single operation
      * added a null xor initialization operation for the xor only channel on
      iop3xx
      * support xor operations on buffers larger than the hardware maximum
      * split the do_* routines into separate prep, src/dest set, submit stages
      * added async_tx support (dependent operations initiation at cleanup time)
      * simplified group handling
      * added interrupt support (callbacks via tasklets)
      * brought the pending depth inline with ioat (i.e. 4 descriptors)
      * drop dma mapping methods, suggested by Chris Leech
      * don't use inline in C files, Adrian Bunk
      * remove static tasklet declarations
      * make iop_adma_alloc_slots easier to read and remove chances for a
        corrupted descriptor chain
      * fix locking bug in iop_adma_alloc_chan_resources, Benjamin Herrenschmidt
      * convert capabilities over to dma_cap_mask_t
      * fixup sparse warnings
      * add descriptor flush before iop_chan_enable
      * checkpatch.pl fixes
      * gpl v2 only correction
      * move set_src, set_dest, submit to async_tx methods
      * move group_list and phys to async_tx
      
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      c2110923
  35. 18 6月, 2006 1 次提交