2011-01-14 22:12:37 +08:00
|
|
|
ccflags-$(CONFIG_DMADEVICES_DEBUG) := -DDEBUG
|
|
|
|
|
ccflags-$(CONFIG_DMADEVICES_VDEBUG) += -DVERBOSE_DEBUG
|
2010-02-10 05:34:54 +08:00
|
|
|
|
2006-05-24 08:50:37 +08:00
|
|
|
obj-$(CONFIG_DMA_ENGINE) += dmaengine.o
|
2012-04-13 19:07:23 +08:00
|
|
|
obj-$(CONFIG_DMA_VIRTUAL_CHANNELS) += virt-dma.o
|
2013-02-13 01:15:02 +08:00
|
|
|
obj-$(CONFIG_DMA_OF) += of-dma.o
|
|
|
|
|
|
2006-05-24 08:50:37 +08:00
|
|
|
obj-$(CONFIG_NET_DMA) += iovlock.o
|
2010-07-21 15:58:10 +08:00
|
|
|
obj-$(CONFIG_INTEL_MID_DMAC) += intel_mid_dma.o
|
2008-07-09 02:58:45 +08:00
|
|
|
obj-$(CONFIG_DMATEST) += dmatest.o
|
2009-07-29 05:32:12 +08:00
|
|
|
obj-$(CONFIG_INTEL_IOATDMA) += ioat/
|
dmaengine: driver for the iop32x, iop33x, and iop13xx raid engines
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: Dan Williams <dan.j.williams@intel.com>
2007-01-03 04:52:26 +08:00
|
|
|
obj-$(CONFIG_INTEL_IOP_ADMA) += iop-adma.o
|
2008-03-01 22:42:48 +08:00
|
|
|
obj-$(CONFIG_FSL_DMA) += fsldma.o
|
2010-02-05 11:42:52 +08:00
|
|
|
obj-$(CONFIG_MPC512X_DMA) += mpc512x_dma.o
|
2012-10-12 23:52:45 +08:00
|
|
|
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
|
2008-07-09 02:58:36 +08:00
|
|
|
obj-$(CONFIG_MV_XOR) += mv_xor.o
|
2008-07-09 02:59:42 +08:00
|
|
|
obj-$(CONFIG_DW_DMAC) += dw_dmac.o
|
2009-07-04 01:24:33 +08:00
|
|
|
obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
|
i.MX31: Image Processing Unit DMA and IRQ drivers
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: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Guennadi Liakhovetski <lg@denx.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2009-01-20 06:36:21 +08:00
|
|
|
obj-$(CONFIG_MX3_IPU) += ipu/
|
2009-04-22 23:40:30 +08:00
|
|
|
obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
|
2012-07-03 04:30:53 +08:00
|
|
|
obj-$(CONFIG_SH_DMAE) += sh/
|
2009-11-20 02:49:17 +08:00
|
|
|
obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
|
2009-12-12 12:24:44 +08:00
|
|
|
obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
|
2010-09-30 21:56:34 +08:00
|
|
|
obj-$(CONFIG_IMX_SDMA) += imx-sdma.o
|
2010-10-06 16:25:55 +08:00
|
|
|
obj-$(CONFIG_IMX_DMA) += imx-dma.o
|
2011-02-27 00:47:42 +08:00
|
|
|
obj-$(CONFIG_MXS_DMA) += mxs-dma.o
|
2010-03-26 02:44:21 +08:00
|
|
|
obj-$(CONFIG_TIMB_DMA) += timb_dma.o
|
2011-10-28 10:22:39 +08:00
|
|
|
obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
|
2012-08-23 09:09:34 +08:00
|
|
|
obj-$(CONFIG_TI_EDMA) += edma.o
|
2010-03-30 21:33:42 +08:00
|
|
|
obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
|
2012-06-06 13:25:27 +08:00
|
|
|
obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o
|
2010-05-24 11:28:19 +08:00
|
|
|
obj-$(CONFIG_PL330_DMA) += pl330.o
|
2010-07-30 16:23:03 +08:00
|
|
|
obj-$(CONFIG_PCH_DMA) += pch_dma.o
|
2010-09-28 21:57:37 +08:00
|
|
|
obj-$(CONFIG_AMBA_PL08X) += amba-pl08x.o
|
2011-05-29 18:10:02 +08:00
|
|
|
obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
|
DMA: sa11x0: add SA-11x0 DMA driver
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: Russell King <rmk+kernel@arm.linux.org.uk>
2012-01-10 05:44:07 +08:00
|
|
|
obj-$(CONFIG_DMA_SA11X0) += sa11x0-dma.o
|
2012-06-15 11:04:08 +08:00
|
|
|
obj-$(CONFIG_MMP_TDMA) += mmp_tdma.o
|
2012-04-13 19:10:24 +08:00
|
|
|
obj-$(CONFIG_DMA_OMAP) += omap-dma.o
|
dmaengine: mmp-pdma support
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: Zhangfei Gao <zhangfei.gao@marvell.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
2012-09-03 11:03:45 +08:00
|
|
|
obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o
|