[lkml]   [2011]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [RFC PATCH 1/2] RapidIO: Add DMA Engine support for RIO data transfers
    On Mon, Oct 17, 2011 at 1:01 PM, Vinod Koul <> wrote:
    > On Mon, 2011-10-17 at 21:22 +0530, Jassi Brar wrote:
    > > On 15 October 2011 23:05, Vinod Koul <> 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

     \ /
      Last update: 2011-10-17 21:43    [W:0.025 / U:3.032 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site