Re: [PATCHv4] DMAEngine: Define interleaved transfer request api
From: Jassi Brar
Date: Mon Oct 03 2011 - 02:24:39 EST
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
bits of 'enum dma_ctrl_flags'.
For this unmap'ing purpose, the usage of dma_data_direction is already
internal to the dmac driver.
[BTW, the scheme is broken because the dmac driver can't know if
the client mapped the buffers with DMA_TO/FROM_DEVICE or with
DMA_BIDIRECTION (dmatest.c does so)]
The only use of 'enum dma_data_direction' in DMAEngine _api_ is
in 'struct dma_slave_config', device_prep_slave_sg and device_prep_dma_cyclic.
Where too the dmac drivers disregard any value other than DMA_TO_DEVICE
and DMA_FROM_DEVICE and very rightly so IMO.
So replacing dma_data_direction usage with xfer_direction in
dmaengine is the best thing to do.
I don't know how better could I explain. If you still think otherwise,
please do tell exactly when would a client need to use both the
flags - dma_data_direction and xfer_direction?
>> > How could we have two macro names: SRC_MEM, DEST_MEM for mapping. or just add:
>> > dma_map_single_src
>> > dma_map_single_dst
>> Not sure what you mean by this.
> my point is dma_data_direction is named wrong after we have your
> xfer_direction. people will think dma_data_direction just means dma is
> transferred from where to where. doesn't dma_data_direction mean m2d,
> m2m, d2d, d2m just from the name? but actually it is just the mapping
> direction now.
So basically you mean people might get confused because
of 'dma_data_direction' and 'xfer_direction' names.
The concern might or might not be serious, but it certainly doesn't
warrant any change to dma_data_direction.
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/