Messages in this thread | | | Subject | Re: [PATCHv4] DMAEngine: Define interleaved transfer request api | From | Vinod Koul <> | Date | Mon, 10 Oct 2011 16:15:01 +0530 |
| |
On Mon, 2011-10-10 at 15:23 +0530, Jassi Brar wrote: > On 10 October 2011 14:48, Vinod Koul <vinod.koul@intel.com> wrote: > > On Mon, 2011-10-10 at 14:46 +0530, Jassi Brar wrote: > >> On 10 October 2011 12:23, Vinod Koul <vinod.koul@intel.com> wrote: > >> > > >> > +struct dmaxfer_memcpy_template { > >> > + dma_addr_t src_start; > >> > + dma_addr_t dst_start; > >> > + bool src_inc; > >> > + bool dst_inc; > >> > + bool src_sgl; > >> > + bool dst_sgl; > >> > + size_t numf; > >> > + size_t frame_size; > >> > + struct data_chunk sgl[0]; > >> > +}; > >> > + > >> > +struct dmaxfer_slave_template { > >> > + dma_addr_t mem; > >> > + bool mem_inc; > >> > + size_t numf; > >> > + size_t frame_size; > >> > + struct data_chunk sgl[0]; > >> > +}; > >> > > >> (1) Please tell how is dmaxfer_slave_template supposed to work on > >> bi-directional channels? > >> Keeping in mind, dma_slave_config.direction is marked to go away > >> in future. > > I didn't use dma_slave_config.direction. There is direction field in > > corresponding prepare function. > > > ok but why not reduce 1 argument from api and embed that as > the transfer's property in dmaxfer_slave_template, as I did ? I am not religious about it, doesn't matter either way :) > > >> > >> (2) > >> * slave_template.mem <=> memcpy_template.src_start > >> * slave_template.mem_inc <=> memcpy_template.src_inc > >> > >> So essentially > >> memcpy_template := slave_template + src/dst_sgl + dst_start + dst_inc > >> > >> Even after this separation, there is nothing slave specific in > >> dmaxfer_slave_template. The slave client still needs DMA_SLAVE_CONFIG > >> to specify slave parameters of the transfer. > >> You only save a few bytes in a _copy_ of memcpy_template. > > Yes DMA_SLAVE_CONFIG is always required, this attempt was not aimed to > > remove that, but I would be interested in it :) > > > Sorry then I don't see this "ambiguity"(if there really is any) removal worth > adding an extra prepare when we already have 10 of them. For slave we have only two, and we can easily merge cyclic by adding a flag or something, I planning to do that for next merge cycle.
IMO having one more for interleaved-slave should be okay.
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.
-- ~Vinod
| |