Thread (1 message) 1 message, 1 author, 2012-07-06

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

From: Arnd Bergmann <hidden>
Date: 2012-07-06 15:28:58
Also in: linux-arm-kernel, linux-omap

On Friday 06 July 2012, Guennadi Liakhovetski wrote:
On Mon, 25 Jun 2012, Arnd Bergmann wrote:

[snip]
quoted
The channel data in the device tree is still in a format
that is specific to that dmaengine driver and interpreted
by it. Using the regular dma_filter_fn prototype is not
necessary, but it would be convenient because the dmaengine
code already knows how to deal with it. If we don't use this
method, how about adding another callback to struct dma_device
like

bool (*device_match)(struct dma_chan *chan, struct property *req);
I like this idea, but why don't we extend it to also cover the non-DT 
case? I.e., why don't we add the above callback (call it "match" or 
"filter" or anything else) to dmaengine operations and inside (the 
extended) dma_request_channel(), instead of calling the filter function, 
passed as a parameter, we loop over all registered DMAC devices and call 
their filter callbacks, until one of them returns true? In fact, it goes 
back to my earlier proposal from 
http://thread.gmane.org/gmane.linux.kernel/1246957
which I, possibly, failed to explain properly. So, the transformation 
chain from today's API would be (all code is approximate):

...
<dmaengine_core>
	for_each_channel() {
		ret = chan->device->device_alloc_chan_resources(chan, filter_arg);
		if (!ret)
			return chan;
		else if (ret != -ENODEV)
			return ret;
		/* -ENODEV - try the next channel */
	}

Which is quite similar to my above mentioned proposal. Wouldn't this both 
improve the present API and prepare it for DT?
How would the individual driver know the size of the filter_arg? In the
device tree code, we would know if from #dma-cells of the engine node,
and that gets checked when reading the property, but when you have
a free-form data structure, it's much less clear.

Also, you could easily have an argument that looks valid for more than one
dmaengine, but really isn't.

I think for your proposal to work, we would need something like the
phandle for the dmaengine device that is at the start of the property
in the DT case.

	Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help