Date:	Thu, 08 Mar 2012 12:00:01 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Guennadi Liakhovetski <g.liakhovetski@....de>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org,
	'Jassi Brar' <jassisinghbrar@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Magnus Damm <magnus.damm@...il.com>,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH/RFC] dmaengine: add a slave parameter to
 __dma_request_channel()

On Wed, 2012-03-07 at 19:21 +0100, Guennadi Liakhovetski wrote:
> > 
> > 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.
We are trying to solve this problem by making it a client or dmac
problem rather than a platform problem. We *miss* the point here in
discussion that platform *knows* the channel mapping and *not* dmac or
client, so any solution not based on this would not work, so let the
platform provide this to dmaengine.

We can have the map as* 
[*with due credit to Linus Walleij, whose idea I have extended a small
bit to have multiple channel and 1 to many mapping]

struct dmaengine_map {
	char *ch_name;
	char *client_name;
	char *dmac_name;
	unsigned int ch;
};

struct dmaengine_map[] = {
	{
		.name = "MMC-RX",
		.client_name = "mmc.0",
		.dmac_name = "pl08x.0",
		.ch = 0;
	},
	/* mmc.0 device can use pl08x.0 controller ch 0 */
	{
		.name = "MMC-TX",
		.client_name = "mmc.0",
		.dmac_name = "pl08x.0",
		.ch = 1;
	},
	/* mmc.0 device can use pl08x.0 controller ch 1 */
	{
		.name = "SSP-TX",
		.client_name = "pl022.0",
		.dmac_name = "pl022.0",
		.ch = 1;
	},
	/* SSP-TX device can use pl022.0 controller ch 1 */
	{
		.name = "SSP-RX",
		.client_name = "pl022.0",
		.dmac_name = "pl022.0",
		.ch = 2;
	},
	/* SSP-TX device can use pl022.0 controller ch 2 */
	{
		.name = "MMC-TX",
		.client_name = "pl022.0",
		.dmac_name = "pl022.0",
		.ch = 2;
	},
	/* BTW I ahve ultra spl hardware where
	 * SSP-TX device can also use pl022.0 controller ch 2 */
	...
};
This also takes care care of many to 1 mapping where a channel can talk
to multiple clients and dmaengine choose first in list.

If we do virtual channels (which I would advise) then we can have 1-1
mapping, even otherwise dmaengine can pick first channel, and client has
right to refuse (filter fn ofcourse!)

So we can add 
int dmaengine_add_channel_map(struct dmaengine_map *map, unsigned int num_entries)
{
	/* store this map into dmaengine and use for channle allocation */
}
This map can be given by device tree, board files, etc based on each
what the respective arch deems the best way.

And based on yesterday discussion, I like Russell's idea of hiding
dma_slave_config, so:

struct dma_chan *dma_request_channel_config(mask, fn, data, config)
{
        struct dma_chan *c = dma_request_channel(mask, fn, data);

        if (c) {
                if (dmaengine_slave_config(c, config)) {
                        dma_release_channel(c);
                        c = NULL;
                }
        }
        return c;
}

where
struct dma_chan *dma_request_channel(mask, fn, data)
{
	for_each_match_in_map(c, map) {
		if (fn && ! fn(c, data))
			continue;
		return chan;
	}
	return NULL;
}

At this point the client has the channel it needs to use .prepare_xxx
API without the need of anything else...

Does this model fit all?

-- 
~Vinod



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists