On Mon, Oct 17, 2011 at 1:01 PM, Vinod Koul <vinod.k...@intel.com> wrote: > > On Mon, 2011-10-17 at 21:22 +0530, Jassi Brar wrote: > > On 15 October 2011 23:05, Vinod Koul <vinod.k...@intel.com> wrote: > > > > > Another alternate approach could be to add one more argument to > > > prep_slave_sg API which allows us to pass additional runtime > specific > > > parameters. This can be NULL and unused for existing drivers and > used in > > > RIO and any future subsystems which want to use dmaengine. > > > Thoughts...? > > > > > That doesn't sound much different than passing the data via > > dma_chan.private during prep_slave_sg. Only now we add to > > the number of arguments. > Yes agreed, but we already decided and marked it as depreciated. > > > And then either this argument would be RapidIO specific (unfair > > to other users) or generic. In latter case what would it look like ? > My initial thoughts were to add an argument which only the specific > dmac > knows howto decode and is filled by its client. As i said for existing > users and people who don't require dynamic information wouldn't bother. > The pros > - allows us to support RIO kind of subsystems where one needs to pass > subsystem specific information for programing the dmac > - doesn't require us to add subsystem specific stuff in dmaengine, > today its RIO tomorrow some other folks may want to add. We want to > maintain dmaengine as a generic framework, while also trying to support > multiple audiences. > Cons: > - there is no guarantee; dmac expects foo and clients pass bar > This was my concern that I mentioned in the beginning of this thread: how to differentiate between different types of slave channels. At that time we decided that channel filtering routines should be sufficient to properly identify a suitable channel. And this is true - if RIO filter detects registered RapidIO capable DMA channel it should be safe to pass a parameter specific to RIO client implementation.
If we want to protect pure slave channels from mixing with some specific implementations we may consider adding new values for dma_transaction_type as it done for RapidIO (DMA_RAPIDIO, DMA_FOO, DMA_BAR etc.). This way we may keep single API with extra argument and differentiate between "flavors" of DMA_SLAVE to make decisions about use of that extra parameter. E.g. channels registered as DMA_SLAVE will ignore the new parameter (pure slave mode), DMA_RAPIDIO and DMA_FOO use it according to the "flavor". Yes, I am planning to drop that flag from the current RIO implementation but It may have a new meaning if prep_slave_sg() gets the extra argument. > I am okay if we have alternate way to support this with above goal :) > > -- > ~Vinod _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
