Messages in this thread | | | Subject | RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sgand prep_dma_cyclic | Date | Mon, 6 Feb 2012 09:02:15 -0800 | From | "Bounine, Alexandre" <> |
| |
On Mon, Feb 06, 2012 at 10:53 AM, Russell King wrote: > > On Mon, Feb 06, 2012 at 08:58:54PM +0530, Vinod Koul wrote: > > On Mon, 2012-02-06 at 07:04 -0800, Bounine, Alexandre wrote: > > > I was thinking about keeping the original scatterlist for dmac > unchanged, > > > but allocating another scatterlist in rio_dma_prep_slave_sg() and > chaining > > > two lists together. After it passed to device specific function, it > parses > > > first section of the chain for additional transfer parameters and > use > > > following scatterlist as intended for dmac. > > hmmm, but that wouldn't make it generic for other systems like > proposed > > MSM box mode..., right? > > > > > > But Russell's idea (See https://lkml.org/lkml/2012/2/3/269 ) seems > to be > > > a better way without added complexity and I am ready to take that > path and > > > make new patches if you and Dan agree with it. > > but it still doesn't fix his concerns for the using void pointer. > > It helps because it makes it easier to find those drivers who are not > using the generic interface (and so would be tied to their particular > DMA engine.) >
What if we introduce another dma_transaction_type like DMA_SLAVE_EXT (extended?). In this case all devices that adhere to the generic SLAVE interface still be registered as DMA_SLAVE and those that do not follow generic route use DMA_SLAVE_EXT.
| |