diff options
| author | Dan Williams <dan.j.williams@intel.com> | 2008-02-02 19:49:57 -0700 |
|---|---|---|
| committer | Dan Williams <dan.j.williams@intel.com> | 2008-02-06 10:12:17 -0700 |
| commit | 0036731c88fdb5bf4f04a796a30b5e445fc57f54 (patch) | |
| tree | 66982e4a9fdb92fedadca35c0ccaa0b9a75e9d2e /drivers/dma/Kconfig | |
| parent | d909b347591a23c5a2c324fbccd4c9c966f31c67 (diff) | |
async_tx: kill tx_set_src and tx_set_dest methods
The tx_set_src and tx_set_dest methods were originally implemented to allow
an array of addresses to be passed down from async_xor to the dmaengine
driver while minimizing stack overhead. Removing these methods allows
drivers to have all transaction parameters available at 'prep' time, saves
two function pointers in struct dma_async_tx_descriptor, and reduces the
number of indirect branches..
A consequence of moving this data to the 'prep' routine is that
multi-source routines like async_xor need temporary storage to convert an
array of linear addresses into an array of dma addresses. In order to keep
the same stack footprint of the previous implementation the input array is
reused as storage for the dma addresses. This requires that
sizeof(dma_addr_t) be less than or equal to sizeof(void *). As a
consequence CONFIG_DMADEVICES now depends on !CONFIG_HIGHMEM64G. It also
requires that drivers be able to make descriptor resources available when
the 'prep' routine is polled.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@intel.com>
Diffstat (limited to 'drivers/dma/Kconfig')
| -rw-r--r-- | drivers/dma/Kconfig | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index c46b7c219ee9..a703deffb795 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -5,6 +5,7 @@ menuconfig DMADEVICES bool "DMA Engine support" depends on (PCI && X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX + depends on !HIGHMEM64G help DMA engines can do asynchronous data transfers without involving the host CPU. Currently, this framework can be |