Re: [PATCHv4] DMAEngine: Define interleaved transfer request api
From: Williams, Dan J
Date: Wed Oct 05 2011 - 14:15:08 EST
On Mon, Oct 3, 2011 at 9:19 AM, Jassi Brar <jaswinder.singh@xxxxxxxxxx> wrote:
> On 3 October 2011 21:43, Russell King <rmk@xxxxxxxxxxxxxxxx> wrote:
>> On Mon, Oct 03, 2011 at 11:54:23AM +0530, Jassi Brar wrote:
>>> On 2 October 2011 06:03, Barry Song <21cnbao@xxxxxxxxx> wrote:
>>> > 2011/10/2 Jassi Brar <jaswinder.singh@xxxxxxxxxx>
>>> >> > For example, it can't use
>>> >> > MEM_TO_MEM to map, it still need to know whether the memory is source
>>> >> > or dest.
>>> >> MEM_TO_MEM means "From Memory Source To Memory Destination"
>>> >> Map Src buffer with DMA_TO_DEVICE and Dst buffer with DMA_FROM_DEVICE
>>> >> MEM_TO_DEV means "From Memory Source To FIFO Destination"
>>> >> Map Src buffer with DMA_TO_DEVICE.
>>> >> DEV_TO_MEM means "From FIFO Source To Memory Destination"
>>> >> Map Dst buffer with DMA_FROM_DEVICE
>>> >> DEV_TO_DEV means "From FIFO Source To FIFO Destination"
>>> >> What else would you want to know ?
>>> > that is the problem. for example, drivers can't use MEM_TO_MEM as a
>>> > flag to do dma mapping. so xfer_direction can't cover all that
>>> > dma_data_direction can do. that's why you need both
>>> > dma_data_direction and xfer_direction with some similar flags in them.
>>> The client drivers map the src/dst buffers and the dmac driver unmaps
>>> them by default(!). For which, the dmac driver doesn't look at anything
>>> other than
>>> bits of 'enum dma_ctrl_flags'.
>>> For this unmap'ing purpose, the usage of dma_data_direction is already
>>> internal to the dmac driver.
>> No. Slave DMA engine drivers do *not* (and if they do, they should *not*)
>> honour the unmapping of submitted buffers.
>> The unmapping of these buffers by the DMA engine driver is intended to be
>> done for the async_tx API and not slave DMA.
> The proposed api is usable by both Slave as well as Async(Memcpy etc).
> So it *does* matter here.
Support for automatic unmapping is really only useful for simple cases
like net_dma where all operations in the chain are to distinct
buffers. Trying to support it for async_tx contributed to the current
brokenness with respect to overlapping mappings for operation chaining
in the async-tx raid case. So I would like to rip out unmap support
from the dma drivers, but before we can do that we need to teach raid
and net_dma how to manage the mappings themselves. The raid lift is a
bit bigger because it needs to handle the cases of cpu-memcpy +
dma-xor-pq versus dma-memcpy + dma-xor-pq (I would drop support for
dma-memcpy + cpu-xor-pq and just make this case all cpu).
This new operation type strikes me as being in a similar vein to
commit a08abd8c "async_tx: structify submission arguments, add
scribble", in that we convert multiple submission arguments into one
description template. With some tweaks it could probably even cover
the DMA_CYCLIC, but probably could not cover the raid ops. In general
I'm concerned about operation type proliferation, so if we added this
one I'd like to see others removed.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/