Re: [RFC v2 0/5] dmaengine: Slave DMA interface and example users

[Dan Williams]

On Feb 4, 2008 8:32 AM, Haavard Skinnemoen <hskinnemoen@xxxxxxxxx> wrote:
> On Wed, 30 Jan 2008 10:39:47 -0700
> "Dan Williams" <dan.j.williams@xxxxxxxxx> wrote:
>
> > Agreed, the issue is how to do this without requiring an
> > interrupt+callback sequence for each transaction or requiring the
> > client to carry per transaction unmap-data.  For example NET_DMA never
> > sees a dma_addr_t and assumes that all it needs to care about is the
> > last transaction in a sequence.  Since it is alive for the duration of
> > a transaction, we could put unmap data in dma_async_tx_descriptor
> > along with an unmap function pointer since dma_unmap* routines have an
> > equal number of parameters.  But I just got through making this
> > structure smaller so maybe there is a better way.
>
> I have to say I'm not crazy about the idea of adding more callbacks to
> the descriptor...
>
> The client must somehow know when the transfer is complete -- after
> all, it has to call async_tx_ack() at some point. So additional
> callbacks shouldn't be needed.
>

The 'ack' only signifies that the client is done with this descriptor,
it tells the api "this descriptor can be freed/reused, no dependent
operations will be submitted against it".  This can and does happen
before the operation actually completes.

[..]

> This requires three additional fields in the dma_async_tx_descriptor
> structure, but in many cases the driver needs these fields in its own
> private descriptor wrapper anyway.
>

I agree this should be moved up to the common descriptor.  The unmap
routines are fairly symmetric, so it may not be that bad to also have
an "unmap type" that the cleanup routines could key off of, one of the
options being "do not unmap" for clients that know what they are
doing.

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/