[lkml]   [2011]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCHv4] DMAEngine: Define interleaved transfer request api
    [ Adding Alexandre ]

    On Fri, Oct 7, 2011 at 4:27 AM, Jassi Brar <> wrote:
    > On 7 October 2011 11:15, Vinod Koul <> wrote:
    >> Thru this patch Jassi gave a very good try at merging DMA_SLAVE and
    >> memcpy, but more we debate this, I am still not convinced about merging
    >> memcpy and DMA_SLAVE yet.
    > Nobody is merging memcpy and DMA_SLAVE right away.
    > The api's primary purpose is to support interleave transfers.
    > Possibility to merge other prepares into this is a side-effect.
    >> I would still argue that if we split this on same lines as current
    >> mechanism, we have clean way to convey all details for both cases.
    > Do you mean to have separate interleaved transfer apis for Slave
    > and Mem->Mem ? Please clarify.

    This is a tangent, but it would be nice if this API extension also
    covered the needs of the incoming RapidIO case which wants to specify
    new device context information per operation (and not once at
    configuration time, like slave case). Would it be enough if the
    transfer template included a (struct device *context) member at the
    end? Most dma users could ignore it, but RapidIO could use it to do
    something like:

    struct rio_dev *rdev = container_of(context, typeof(*rdev), device);

    That might not be enough, but I'm concerned that making the context a
    (void *) is too flexible. I'd rather have something like this than
    acquiring a lock in rio_dma_prep_slave_sg() and holding it over
    ->prep(). The alternative is to extend device_prep_slave_sg to take
    an extra parameter, but that impacts all other slave implementations
    with a dead parameter.


     \ /
      Last update: 2011-10-11 18:47    [W:0.021 / U:0.156 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site