lkml.org 
[lkml]   [2011]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCHv4] DMAEngine: Define interleaved transfer request api
From
Date
On Wed, 2011-10-12 at 13:41 +0800, Barry Song wrote:
> 2011/10/11 Jassi Brar <jaswinder.singh@linaro.org>:
> > On 10 October 2011 21:32, Vinod Koul <vinod.koul@intel.com> wrote:
> >> On Mon, 2011-10-10 at 16:46 +0530, Jassi Brar wrote:
> >>> On 10 October 2011 16:15, Vinod Koul <vinod.koul@intel.com> 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



\
 
 \ /
  Last update: 2011-10-12 08:29    [W:0.226 / U:1.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site