Messages in this thread | | | Date | Mon, 10 Oct 2011 21:58:43 +0530 | Subject | Re: [PATCHv4] DMAEngine: Define interleaved transfer request api | From | Jassi Brar <> |
| |
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. -- 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/
| |