From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Vinod Koul <vinod.koul@intel.com>,
linux-kernel@vger.kernel.org,
"'Jassi Brar'" <jassisinghbrar@gmail.com>,
Linus Walleij <linus.walleij@linaro.org>,
Magnus Damm <magnus.damm@gmail.com>,
Paul Mundt <lethal@linux-sh.org>
Subject: Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel()
Date: Wed, 7 Mar 2012 14:49:25 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.4.64.1203071416060.19595@axis700.grange> (raw)
In-Reply-To: <20120307124620.GT17370@n2100.arm.linux.org.uk>
On Wed, 7 Mar 2012, Russell King - ARM Linux wrote:
> On Wed, Mar 07, 2012 at 01:30:23PM +0100, Guennadi Liakhovetski wrote:
> > 1. The current scheme is:
> >
> > (a) client issues
> > dma_request_channel()
> > with an optional filter function as parameter
> > (b) the core picks up a suitable from its PoV DMA controller device and a
> > channel on it and calls the filter function with that channel as an
> > argument
> > (c) the filter function can verify, whether that channel is suitable or
> > not (*)
> > (d) the client driver then can call
> > dmaengine_slave_config()
> > to provide any additional channel configuration information to the DMA
> > controller driver (**)
> > (e) if the filter has rejected this channel, the core jumps to the next
> > DMA controller instance (***)
>
> No - if the filter function rejects the first free channel, the next free
> channel on the same controller will be tried. When all channels have
> been tried, the next DMA controller is checked.
Right, sorry, I confused it with an error, returned by DMA driver's
.device_alloc_chan_resources()
> > 2. (goal: eliminate filter function look-ups) proposed by Linus W
> >
> > (a) client issues
> > dma_request_slave_channel(dev, "MMC-RX")
> > (b) the dmaengine core scans a platform-provided list of channel mappings
> > and picks up _the_ correct channel (****)
>
> That doesn't work if you have multiple DMA controllers supporting the
> same client.
Right, that's why I was against it, but it would work with virtual
channels (and virtual devices)?
> > 3. Jassi's idea with capabilities has been rejected by Russell
> >
> > 4. (goal: simplify the allocation and configuration procedure) proposed by
> > myself
> >
> > (a) as in (1) client issues
> > dma_request_channel()
> > with an additional slave configuration parameter
> > (b) the core picks up a suitable from its PoV DMA controller device and a
> > channel on it, (optionally) calls the filter
>
> How can it work out what's a suitable DMA controller device?
It doesn't, it will have to probe all DMA devices, until
.device_alloc_chan_resources() succeeds in (c) below.
> Even knowing
> where the DMA register is, the burst size and width doesn't really narrow
> down the selection of the DMA controller.
>
> > (c) the core calls DMA controller driver's
> > .device_alloc_chan_resources()
> > method, which verifies, whether the channel can be configured for the
> > requesting slave, if not, an error is returned and the next DMA
> > controller instance is checked by the core
>
> And this effectively prevents a channel being reconfigured to target a
> different burst size or different transfer width without freeing and
> re-requesting it.
Cannot dmaengine_slave_config() be used for that?
> > Naturally, my preference goes for (4) because (a) I think, it is the DMA
> > controller driver, that has to decide, whether the channel is suitable for
> > a specific slave,
>
> We already effectively do that with many of the DMA engine drivers. The
> DMA engine drivers export their filter function which should be used when
> requesting a channel (if you care about the channel you end up with.)
This is one of the things I'd like to avoid - having to extend the
standard API with hardware-specific methods... It's already bad enough,
that client drivers often have to use DMA-controller specific types to
configure transfers. Ideally I'd prefer to have 0 DMA device knowledge in
client drivers. If needed, they should just pass DMA device data from
platform code to the DMA controller driver as opaque handles.
> > (b) changes to the core are minimal, simple and
> > trivially backwards-compatible, (c) the core is not cluttered with
> > hw-specific channel mappings, (d) the additional call to
> > dmaengine_slave_config() can be eliminated.
>
> The call to dmaengine_slave_config() actually simplifies the DMA engine
> support for some drivers though, so eliminating it doesn't help.
Right, sorry, I didn't mean, that I'd like to get rid of it completely. I
just meant, that being forced to use it for every slave channel allocation
isn't very nice.
> 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...
Ah, there's the problem actually: you cannot try to find another channel,
if dmaengine_slave_config() fails - the scan will restart from the
beginning and you end up with the same failure again. So, we cannot rely
on dmaengine_slave_config() to be the first instance, where the DMA
controller driver actually gets the channel configuration and has a chance
to verify its suitability.
> which would simplify some of the DMA engine users. There'll still be
> some though which would want to call dmaengine_slave_config() to change
> the channels configuration when the mode of the device switches.
>
> 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.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
next prev parent reply other threads:[~2012-03-07 13:50 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-01 15:26 [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel() Guennadi Liakhovetski
2012-03-02 13:21 ` Guennadi Liakhovetski
2012-03-06 8:30 ` Vinod Koul
2012-03-06 8:53 ` Guennadi Liakhovetski
2012-03-06 12:08 ` Vinod Koul
2012-03-06 13:03 ` Guennadi Liakhovetski
2012-03-07 6:28 ` Vinod Koul
2012-03-07 9:18 ` Guennadi Liakhovetski
2012-03-07 9:30 ` Russell King - ARM Linux
2012-03-07 9:55 ` Linus Walleij
2012-03-07 10:02 ` Guennadi Liakhovetski
2012-03-07 10:31 ` Russell King - ARM Linux
2012-03-07 12:30 ` Guennadi Liakhovetski
2012-03-07 12:45 ` Guennadi Liakhovetski
2012-03-07 12:46 ` Russell King - ARM Linux
2012-03-07 13:49 ` Guennadi Liakhovetski [this message]
2012-03-07 14:26 ` Russell King - ARM Linux
2012-03-07 15:44 ` Guennadi Liakhovetski
2012-03-07 16:27 ` Russell King - ARM Linux
2012-03-07 18:21 ` Guennadi Liakhovetski
2012-03-08 6:30 ` Vinod Koul
2012-03-08 10:16 ` Guennadi Liakhovetski
2012-03-08 10:55 ` Vinod Koul
2012-03-08 11:22 ` Guennadi Liakhovetski
2012-03-08 11:34 ` Vinod Koul
2012-03-08 12:58 ` Vinod Koul
2012-03-08 13:18 ` Guennadi Liakhovetski
2012-03-09 9:21 ` Vinod Koul
2012-03-09 9:24 ` Guennadi Liakhovetski
2012-03-09 9:39 ` Vinod Koul
2012-03-09 12:20 ` Guennadi Liakhovetski
2012-03-09 14:07 ` Russell King - ARM Linux
2012-03-09 14:15 ` Guennadi Liakhovetski
2012-03-12 2:47 ` Vinod Koul
2012-03-12 19:47 ` Linus Walleij
2012-03-16 9:36 ` Guennadi Liakhovetski
2012-03-16 10:16 ` Linus Walleij
2012-03-16 10:31 ` Russell King - ARM Linux
2012-03-16 11:09 ` Guennadi Liakhovetski
2012-03-16 14:11 ` Linus Walleij
2012-03-16 14:28 ` Guennadi Liakhovetski
2012-03-30 5:44 ` Linus Walleij
2012-03-30 6:40 ` Guennadi Liakhovetski
2012-03-30 10:38 ` Russell King - ARM Linux
2012-04-03 20:36 ` Linus Walleij
2012-04-03 20:44 ` Linus Walleij
2012-04-12 21:33 ` Guennadi Liakhovetski
2012-04-12 23:48 ` Russell King - ARM Linux
2012-03-30 10:29 ` Russell King - ARM Linux
2012-03-30 10:40 ` Guennadi Liakhovetski
2012-03-30 10:43 ` Russell King - ARM Linux
2012-03-19 11:58 ` Vinod Koul
2012-03-30 10:25 ` Russell King - ARM Linux
2012-03-19 11:39 ` Vinod Koul
2012-03-19 11:37 ` Vinod Koul
2012-03-19 11:47 ` Guennadi Liakhovetski
2012-03-19 13:34 ` Vinod Koul
2012-03-19 13:38 ` Guennadi Liakhovetski
2012-03-19 14:00 ` Vinod Koul
2012-03-19 14:09 ` Guennadi Liakhovetski
2012-03-19 14:22 ` Vinod Koul
2012-03-19 14:45 ` Guennadi Liakhovetski
2012-03-19 16:20 ` Vinod Koul
2012-03-19 16:32 ` Guennadi Liakhovetski
2012-03-20 7:11 ` Vinod Koul
2012-03-08 11:46 ` Linus Walleij
2012-03-08 12:36 ` Guennadi Liakhovetski
2012-03-07 16:31 ` Linus Walleij
2012-03-07 16:20 ` Linus Walleij
2012-03-07 9:46 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1203071416060.19595@axis700.grange \
--to=g.liakhovetski@gmx.de \
--cc=jassisinghbrar@gmail.com \
--cc=lethal@linux-sh.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=magnus.damm@gmail.com \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).