Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel()

[Guennadi Liakhovetski]

Thanks for a detailed explanation!

On Wed, 7 Mar 2012, Russell King - ARM Linux wrote:

> On Wed, Mar 07, 2012 at 04:44:12PM +0100, Guennadi Liakhovetski wrote:
> > So, the question remains: which way should we go? If we don't come up with 
> > a generic solution, I'd be inclined to just do something as silly as
> > 
> > arch/arm/mach-shmobile/board-*.c
> > 
> > static const struct device *group1_dma_dev[] = {
> > 	&dma0.device,
> > 	&dma1.device,
> > };
> > 
> > static const struct device *group2_dma_dev[] = {
> > 	&dma2.device,
> > 	&dma3.device,
> > };
> > 
> > static struct my_platform_data = {
> > 	.dma_dev_list = group1_dma_dev,
> > 	.dma_dev_list_num = ARRAY_SIZE(group1_dma_dev),
> > };
> > 
> > drivers/.../sh_*.c
> > 
> > static bool filter(struct dma_chan *chan, void *arg)
> > {
> > 	struct device *dev = chan->dev->device.parent;
> > 	struct my_platform_data *pdata = arg;
> > 
> > 	for (i = 0; i < pdata->dma_dev_list_num; i++)
> > 		if (pdata->dma_dev_list[i] == dev)
> > 			return true;
> > 
> > 	return false;
> > }
> > 
> > even though I find it silly to have to do this on every platform and in 
> > every driver.
> 
> Why are you thinking that the filter function implementation has to be
> provided by the peripheral driver?  That's just wrong and broken.

Again: because I don't like adding private APIs to a generic one.

> Think about it - how does the peripheral driver know what kind of dma
> channel its filter function has been passed - to give an example, if
> you built into your kernel support for the PL08x DMA engine, and lets
> say you had PL08x DMA engine hardware, how would your filter function
> decide whether it was one of your per-device channels or whether it
> was a PL08x DMA engine channel?

Sorry, there must be a confusion here: I was not proposing the above 
implementation for all hardware types, I don't have a good overview of all 
possible DMA engine scenarious and, fortunately, I don't have to implement 
anything that generic:-)

Even though I did write above "arch/arm/mach-shmobile/board-*.c" it 
probably wasn't clear enough: I was only talking about the shdma DMA 
engine driver and its clients. And so far on all sh-mobile hardware, that 
I'm aware of, we haven't been mixing DMA engine types on the same 
hardware. This is going to change soon, as soon as we get USBHS?-DMAC 
support in the kernel, but even then, those controllers will not be 
interchangeable: only USBHS devices will be served by USBHS-DMAC 
controllers, the rest can be served by any other controller. So, matching 
on a DMA controller device would perfectly suffice.

Of course, client drivers have no access to those device objects, that's 
why those lists have to be provided to them by the platform code.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/