linux-kernel - Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.1203071602330.19595@axis700.grange>
Date:	Wed, 7 Mar 2012 16:44:12 +0100 (CET)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
cc:	Vinod Koul <vinod.koul@...el.com>, 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, 7 Mar 2012, Russell King - ARM Linux wrote:

> On Wed, Mar 07, 2012 at 02:49:25PM +0100, Guennadi Liakhovetski wrote:
> > On Wed, 7 Mar 2012, Russell King - ARM Linux wrote:
> > > What
> > > would be useful is to have a helper function along these lines:
> > > 
> > > 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;
> > > }
> > 
> > Hm, yeah... That seems like an over-complication to me: to "just" allocae 
> > a channel you cann dma_request_channel(), which scans your devices and 
> > channels on them, calls your filter, calls the DMA controller driver's 
> > allocation method, only to eventually call dmaengine_slave_config() and 
> > see it fail, after which you release the channel and start anew...
> 
> The point is _not_ that this uses dmaengine_slave_config() to find a
> channel at all.  As I already said, there's nothing in dma_slave_config
> which _could_ be used to decide whether a channel is suitable or not.

I completely agree, that's why I wrote in my previous mail:

> > > However, I don't see anything in struct dma_slave_config which could be
> > > used to select an appropriate channel.
> > 
> > That's also my problem with it, and the reason, why I suggested, that it 
> > has to be embedded in a hardware-specific channel configuration type.

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.

Thanks
Guennadi

> So to try to filter on the slave configuration is a pure red herring.
> None of the DMA controllers I have access to (whether they be working
> or not) could make any kind of decision about whether a particular
> channel is suitable for the peripheral by looking at the dma_slave_config
> structure - it's very much the case that the decision would be that
> 'any channel will do', which in reality it won't because there's other
> information required to make the decision about which virtual channel
> should be used.  Specifically, the request signal information.
> 
> Even more specifically, the request signal information may not be _just_
> the request signal on the DMA controller but also incorporate an
> external MUX like on the Realview boards (which pl08x handles itself.)
> 
> I do not see any milage in trying to select a channel based on "I want
> a DMA engine to access register X, width Y, burst size Z."  As far as
> I can see, the common situation is that there's nothing in that set of
> information which would be useful to chose a specific channel on a
> DMA engine.

---
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/