Re: [PATCH] DMAENGINE: add a slave buffer prep call

[Rabin Vincent <rabin@rab.in>]

On Wed, Aug 11, 2010 at 09:02:04PM +0200, Linus Walleij wrote:
> 2010/8/11 Rabin Vincent <rabin@rab.in>:
> > On Tue, Aug 10, 2010 at 11:46:06PM +0200, Linus Walleij wrote:
> >> This makes it possible for engines to implement slave transfers
> >> to be done to/from a simple kmalloc():ed memory buffer and not
> >> just from scatterlists.
> >
> > Why is this needed?  Drivers can just pass in a single-entry scatterlist
> > to the existing API to achieve the same functionality, and a couple of
> > them already do so.
> 
> Because of the overhead, simply. Especially if you want to trigger
> many jobs after each other. (This is necessary in device/slave-DMA
> since every transaction may fail...) It's not just constructing the
> sg-headers and freeing them again and again,

Note that the single length SG list can just be created on the stack.
For example, sound/soc/sh/siu_pcm.c.

> it's also list traversals
> here and there since the driver must assume it can be a linked sglist and
> then two other list traversals for each
> dma_map_sg()/dma_unmap_sg() pair and ... yeah that's basically
> it.

These list traversals of course run only one iteration for a single
length SG list.

> 
> And the number of extra code lines needed.

It's about five lines, but yes, these are duplicated in drivers.

> 
> Then it's something conceptwise of creating a list that you know
> is just always one element that is just not elegant, like taking a queue
> numer and standing in queue when there is only one customer but
> hey, maybe it's just me.

While I don't know about the overhead benefits, such an API would
probably be nice to have to at least avoid duplicating the sglist
building sequence.

Since it can be easily implemented as a wrapper over the existing API
with no change to exsting DMA drivers, why does a new cap need to be
added?  Your suggestion below sounds like a better approach.

> 
> One way of achieving it for all present drivers is to wrap the passed
> buffer in a single sglist and pass to the sglist function if the single
> buffer call is not supported in the driver. Maybe it'd be better if I
> coded up the patch like that so all driver can rely on this function
> to be present?

Rabin