On Friday 06 July 2012, Guennadi Liakhovetski wrote:
> On Mon, 25 Jun 2012, Arnd Bergmann wrote:
>
> [snip]
>
> > 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
_______________________________________________
devicetree-discuss mailing list
[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
