lkml.org 
[lkml]   [2011]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCHv4] DMAEngine: Define interleaved transfer request api
    From
    On 11 October 2011 22:14, Williams, Dan J <dan.j.williams@intel.com> wrote:
    > [ Adding Alexandre ]
    >
    > 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.
    >
    From what I read so far, the requirement is closer to prep_slave_sg
    than to this api.

    IMO, there should be a virtual channel for each device that the real
    physical channel, at the backend, can transfer data to/from.

    The client driver should request each virtual channel corresponding
    to each target device it wants to transfer data with.

    In the dmac driver - transfers queued for all virtual channels that are
    backed by the same physical channel, could be added to the same
    list and executed in FIFO manner.

    That way, there won't be any need to hook target device info per transfer
    and more importantly "struct dma_chan" would continue to mean
    link between fixed 'endpoints'.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-10-11 20:45    [W:3.258 / U:0.296 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site