Messages in this thread | | | Subject | Re: [PATCHv4] DMAEngine: Define interleaved transfer request api | From | Vinod Koul <> | Date | Sat, 01 Oct 2011 23:41:14 +0530 |
| |
On Sat, 2011-10-01 at 11:05 +0800, Barry Song wrote: > 2011/10/1 Jassi Brar <jaswinder.singh@linaro.org>: > > On 30 September 2011 12:13, Barry Song <21cnbao@gmail.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. > > 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. > > How could we have two macro names: SRC_MEM, DEST_MEM for mapping. or just add: > dma_map_single_src > dma_map_single_dst Direction is valid even if you are doing memory to memory transfer. IMO what we need to specify what type of transfer (memory or peripheral), perhaps a flag and use that along with dma_data_direction.
@Jassi, this is what kind of tweak I have in mind. And i do not agree current approach is bad and is it cleanly tell us type of transfer (memcpy or prep_sg) and direction with dma_data _direction.
-- ~Vinod
| |