Messages in this thread | | | From | Barry Song <> | Date | Wed, 12 Oct 2011 14:53:34 +0800 | Subject | Re: [PATCHv4] DMAEngine: Define interleaved transfer request api |
| |
2011/10/12 Vinod Koul <vinod.koul@intel.com>: > 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.
anyway, the rename issue is trivial. i can accept the current name as is even it doesn't make all senses. The important thing is the dma_transfer_direction or dma_xfer_direction as Jassi and you said.
> > @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 > -barry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |