Messages in this thread | | | Subject | RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sgand prep_dma_cyclic | From | Vinod Koul <> | Date | Tue, 07 Feb 2012 09:09:53 +0530 |
| |
On Mon, 2012-02-06 at 10:45 -0800, Bounine, Alexandre wrote: > On Mon, Feb 06, 2012 at 1:07 PM, Vinod Koul wrote: > > > > On Mon, 2012-02-06 at 09:02 -0800, Bounine, Alexandre wrote: > > > > > > 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. > > that way it would be channel specific not transaction specific as you > > had asked for...? > > > > Again, how does this solve problem of passing parameters while > > preventing abuse... > > This gives a channel-specific treatment to the parameter. Channels registered > as DMA_SLAVE never expect an extra parameter (BUG_ON if the pointer is not NULL). > In the generic use scenario described by Russell clients are safe to request > any such channel without an additional HW knowledge (as it is now). > > Channels registered as DMA_SLAVE_EXT will accept a pointer to parameter structure. > This, combined with configuration specific wrappers as you described > in earlier e-mail with #ifdef CONFIG_RAPIDIO, should ensure that there is no > unexpected treatment of (void *) parameter. Also for channels registered > as DMA_SLAVE_EXT a corresponding filter routine must be provided. Okay this sounds better :) Sorry I didnt quite get the last line about filter routine?
-- ~Vinod
| |