Messages in this thread | | | Date | Fri, 13 Aug 2010 00:21:51 +0530 | From | Rabin Vincent <> | Subject | Re: [PATCH] DMAENGINE: add a slave buffer prep call |
| |
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 -- 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/
| |