Re: [PATCHv4] DMAEngine: Define interleaved transfer request api

From: Vinod Koul
Date: Wed Oct 12 2011 - 02:27:28 EST


On Wed, 2011-10-12 at 13:41 +0800, Barry Song wrote:
> 2011/10/11 Jassi Brar <jaswinder.singh@xxxxxxxxxx>:
> > On 10 October 2011 21:32, Vinod Koul <vinod.koul@xxxxxxxxx> wrote:
> >> On Mon, 2011-10-10 at 16:46 +0530, Jassi Brar wrote:
> >>> On 10 October 2011 16:15, Vinod Koul <vinod.koul@xxxxxxxxx> wrote:
> >>> >
> >>> > But I am fine if we find a common ground and merge the two where dmac
> >>> > can cleanly identify direction and mode it is operating.
> >>> >
> >>> The client would set the xfer_direction and dmac would interpret as
> >>>
> >>> enum xfer_direction {
> >>> MEM_TO_MEM, -> Async/Memcpy mode
> >>> MEM_TO_DEV, -> Slave mode & From Memory to Device
> >>> DEV_TO_MEM, -> Slave mode & From Device to Memory
> >>> DEV_TO_DEV, -> Slave mode & From Device to Device
> >>> }
> >>>
> >>> How could it get any cleaner?
> >> Consider the case of a dmac driver which supports interleaved dma as
> >> well as memcpy and slave
> >> It needs to interpret dma_data_direction for later cases and
> >> xfer_direction for former ones.
> > dma_data_direction is the mapping attribute of a buffer and is not meant to
> > tell type of source and destination of a transfer.
> > xfer_direction is meant for that purpose.
> > So I'd rather convert device_prep_dma_cyclic and device_prep_slave_sg
> > to use xfer_direction.
>
> i tend to agree with Jassi. now dma_data_direction actually is only
> mapping things not real transfer direction.
> xfer_direction is now something really telling the data transfer direction.
> I think that's what device_prep_dma_cyclic and device_prep_slave_sg want.
>
> actually, there is only one case we need to use dma_data_direction in
> dmac driver, that's unmapping async dma buffer.
> But the param to dma_unmap_single can be implied by xfer_direction and
> dma description.
>
> that's why i think we should rename dma_data_direction to
> dma_map_direction or something like that to avoid confusion.
Nope, I would leave dma_data_direction as is.
We should use above enum in dmaengine and all dmac drivers.

@Jassi: I have started doing this change for dmaengine and dmacs, and I
took the liberty to name this enum as dma_transfer_direction, hope you
are okay with that


--
~Vinod

--
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/