Message-ID: <20120307103112.GP17370@n2100.arm.linux.org.uk>
Date:	Wed, 7 Mar 2012 10:31:12 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Guennadi Liakhovetski <g.liakhovetski@....de>
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, Mar 07, 2012 at 11:02:46AM +0100, Guennadi Liakhovetski wrote:
> Right, I thought about virtual DMA channels, but I really hoped we 
> wouldn't have to do that;-)

We have to do it because on many systems, we have N request signals and
M channels, where M << N.  If we don't do that, then we run into problems
with tying up DMA channels when they're not being used.

For example, the SA11x0 IrDA driver uses two virtual channels, one for
receive and one for transmit.  The SA11x0 has a total of five DMA
channels.  To waste two of them on IrDA when it's half-duplex is just
silly.  Doing the whole 'request+free' thing is also silly because
switching between tx and rx mode is timing-critical.

Plus, it's a lot easier for driver writers to request their DMA channels
at the start, and hold them until they've completed - less complicated
error checking, less latency, more throughput etc.

> Would we then also have to use virtual DMAC 
> instances? Given that the core operates in terms of DMA-controller devices 
> and channels and the hardware is also built around those concepts, it 
> seems a natural choice to use a 1-to-1 correspondence.

That depends what you want from virtual DMA channels.  At the moment, most
setups are about virtual DMA channels within a DMA device itself.  So we
expose just the virtual DMA channels and hide the physical channels within
the depths of the driver.

> In the sh-mobile case, AFAIK, until now we can have N DMA controllers of M 
> types. Within each type the controllers are identical, meaning also, that 
> all channels on them can be configured to work with all the same devices. 
> Currently that's also what we present to the dmaengine core and to 
> clients: N controllers. Whereas it has been suggested a couple of times, 
> that neither the core nore clients should be bothered with specific DMA 
> controller instances, so, we might as well just present M virtual 
> controllers to the system - 1 of each type, each with a unique capability 
> set?

I am aware of these kinds of setup, but at the moment I think there's
enough of a big problem to solve with dmaengine without having it made
even bigger.  It's already a big enough headache trying to work out
sane ways to provide library based functionality which can be shared
between the DMA engine drivers...

I've been chipping away at this problem since Jan 2011 and so far all
I've managed to produce sanely is the consolidation of cookie handling.
I have two versions of virtual channels, one based on the PL08x code
and one based on my new SA11x0 code which will probably be shared with
an OMAP DMA engine driver I'm working on, but I haven't looked at making
all these drivers work with one set of virtual channel code yet (mainly
due to crippled PL08x hardware.)
--
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