Date:	Sun, 2 Oct 2011 08:33:18 +0800
From:	Barry Song <21cnbao@...il.com>
To:	Jassi Brar <jaswinder.singh@...aro.org>
Cc:	Vinod Koul <vinod.koul@...el.com>, linux-kernel@...r.kernel.org,
	dan.j.williams@...el.com, rmk@....linux.org.uk,
	DL-SHA-WorkGroupLinux <workgroup.linux@....com>
Subject: Re: [PATCHv4] DMAEngine: Define interleaved transfer request api

2011/10/2 Jassi Brar <jaswinder.singh@...aro.org>
>
> On 1 October 2011 08:35, Barry Song <21cnbao@...il.com> wrote:
> > 2011/10/1 Jassi Brar <jaswinder.singh@...aro.org>:
> >> On 30 September 2011 12:13, Barry Song <21cnbao@...il.com> wrote:
> >>>
> >>> i support we can update dma_data_direction to:   MEM_TO_MEM,
> >>> MEM_TO_DEV,  DEV_TO_MEM, DEV_TO_DEV.
> >>>
> >> So basically you are suggesting to replace 'enum dma_data_direction'
> >> with 'enum xfer_direction'
> >> I am not sure about that. I think they represent different things and
> >> hence should be separate.
> >> dma_data_direction tells the mapping of a buffer while the other
> >> tells if the src and dst are memory or a device's FIFO.
> >>
> > you are kind of right now. now people use dma_data_direction to do
> > mapping for dma buffer. even with all 4 direction, people still use
> > the old two direction to do mapping.
> > 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.

>
> > i just don't like to the two old macro names. it seems i get a ticket
> > flying from New York to Beijing, but actually, we fly to Mexico...
> > so by the moment, dma_data_direction seems just to mean how to do map,
> > but xfer_direction is the real transfer direction.
> Not every dmac driver would need to know the src and dst type _only_ for buffer
> mapping. Some might have to reprogram the channel accordingly, say.
> The point is to give exact info about src and dst to dmac client driver and let
> it do what it must.
>
> > 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 we might make mapping things be the mapping things but not the data
direction things. we might rename macros DMA_FROM_DEV, DMA_TO_DEV in
it to MEM_DST and MEM_SRC. or we split dma_map_single class functions
into dma_map_single_src and dma_map_single_dst. then for the memory
buffer as dma src, we map it by dma_map_single_src. for the memory
buffer as dma dst, we map it by dma_map_single_dst.

-barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists