From: nicolas.ferre@atmel•com (Nicolas Ferre)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] of: Add generic device tree DMA helpers
Date: Mon, 19 Mar 2012 17:31:32 +0100 [thread overview]
Message-ID: <4F675F64.6070306@atmel.com> (raw)
In-Reply-To: <20120319153334.GF16389@n2100.arm.linux.org.uk>
On 03/19/2012 04:33 PM, Russell King - ARM Linux :
> On Mon, Mar 19, 2012 at 02:06:34PM +0000, Arnd Bergmann wrote:
>> ==== mmci ====
>> /* in drivers/dma/ste_dma40.c, others in pl330.c, coh901318.c, ... */
>> bool stedma40_filter(struct dma_chan *chan, void *data)
>> {
>> struct stedma40_chan_cfg *info = data;
>> struct d40_chan *d40c = container_of(chan, struct d40_chan, chan);
>> int err;
>>
>> err = d40_validate_conf(d40c, info);
>> if (!err)
>> d40c->dma_cfg = *info;
>> d40c->configured = true;
>>
>> return err == 0;
>> }
>> EXPORT_SYMBOL(stedma40_filter);
>>
>> /* in mmci.h */
>> struct mmci_platform_data {
>> ...
>> bool (*dma_filter)(struct dma_chan *chan, void *filter_param);
>> void *dma_rx_param;
>> void *dma_tx_param;
>> };
>>
>> /* in mmci.c */
>> static void __devinit mmci_dma_setup(struct mmci_host *host)
>> {
>> ...
>> host->dma_rx_channel = dma_request_channel(mask, plat->dma_filter, plat->dma_rx_param);
>> ...
>> }
>>
>> ====
>>
>> Whatever we come up with obviously needs to work with both drivers.
>> I think we will end up with something closer to the second one, except
>> that the dma parameters do not come from platform_data but from the
>> #dma-request property, which also identifies the controller and channel.
>
> Firstly, define what you mean by "the DMA parameters". Things like burst
> size, register width, register address? That should all be known by the
> peripheral driver and _not_ be encoded into DT in any way - and this
> information should be passed to the DMA engine driver for the well defined
> API for that purpose.
>
> Secondly, there are platforms (Samsung) where peripherals are connected
> to more than one DMA controller, and either DMA controller can be used -
> I'm told by Jassi that there's reasons why you'd want to select one or
> other as the target at runtime.
>
> Whether it's appropriate for DT to know that or not, I'm not certain at
> the moment - I suspect the _right_ solution would be a radical DMA engine
> redesign which moves _all_ slave DMA to a virtual channel representation,
> and for the virtual channels to be scheduled onto a set of physical DMA
> channels over a range of DMA devices. Obviously, there's restrictions on
> which virtual channels could be scheduled onto which physical channels of
> which DMA devices.
OMG! the dmaengine drivers are already not so obvious to understand. I
fear that trying to mimic some special behaviors within relatively
simple dmaengine drivers will bring confusion and prevent people to
read/contribute and fix those simple ones...
> It seems to me, therefore, that any attempt to come up with some kind of
> DT based representation of the current scheme is doomed to fail, and will
> at some point become obsolete.
>
> I think instead, rather than trying to fix this now, we persist with what
> we have, but organize an effort to clean up and restructure the DMA engine
> code so that:
>
> (a) things like the Samsung, and ARM board oddities can be easily dealt
> with in a driver independent manner.
> (b) get rid of all the duplicated functionality between each different
> DMA engine implementation, separating this out into core code, and
> simplifying the drivers.
>
> The _big_ problem I see is that if we try to represent the existing
> solution in DT, we're going to get locked into that way of doing things
> and then any major restructuring of the DMA engine stuff will become an
> impossibility - especially if we start specifying things by DMA request
> signal numbers on DMA engines.
Even if I understand your point, I wonder what is the solution for us
that have a pretty simple representation of *hardware* to code into DT:
should we wait for a big rework? Should we go for a private DMA binding
for each of us that have just the need for a quite simple representation?
I must say that I am puzzled by recent discussion on the topic (mix of
"channel" and "request" notions, plan for a complete rework of dmaengine
that can delay DT representation of DMA slave-controller relationship,
even my own doubts on the "void *" output parameter, etc.). It seems
that I am not familiar with all those cases and that I cannot go further
with a generic DT representation...
Best regards,
--
Nicolas Ferre
next prev parent reply other threads:[~2012-03-19 16:31 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-27 17:29 [RFC PATCH 1/2] of: Add generic device tree DMA helpers Cousson, Benoit
2012-01-27 18:13 ` Stephen Warren
2012-01-27 20:36 ` Cousson, Benoit
2012-01-28 18:12 ` Grant Likely
2012-01-28 18:06 ` Grant Likely
2012-01-31 21:26 ` Cousson, Benoit
2012-02-02 4:52 ` Grant Likely
2012-01-31 23:09 ` Russell King - ARM Linux
2012-02-01 10:50 ` Cousson, Benoit
2012-02-02 8:45 ` Russell King - ARM Linux
2012-02-02 8:54 ` Cousson, Benoit
2012-02-22 10:59 ` Nicolas Ferre
2012-02-23 10:03 ` Cousson, Benoit
2012-02-23 15:51 ` Nicolas Ferre
2012-02-23 15:57 ` Cousson, Benoit
2012-02-27 13:09 ` Nicolas Ferre
2012-02-27 14:22 ` Cousson, Benoit
2012-02-27 17:28 ` Nicolas Ferre
2012-02-29 14:54 ` [RFC PATCH] of: DMA helpers: manage generic requests specification Nicolas Ferre
2012-02-29 20:54 ` Stephen Warren
2012-03-05 13:14 ` Cousson, Benoit
2012-03-05 18:30 ` Stephen Warren
2012-03-05 19:57 ` Russell King - ARM Linux
2012-03-05 10:55 ` Cousson, Benoit
2012-03-05 15:36 ` Grant Likely
2012-03-14 17:47 ` Nicolas Ferre
2012-03-14 18:16 ` Stephen Warren
2012-03-15 8:38 ` [PATCH] of: Add generic device tree DMA helpers Nicolas Ferre
2012-03-15 9:22 ` Arnd Bergmann
2012-03-15 9:26 ` Russell King - ARM Linux
2012-03-15 10:09 ` Arnd Bergmann
2012-03-17 9:42 ` Grant Likely
2012-03-17 16:03 ` Arnd Bergmann
2012-03-18 9:08 ` Grant Likely
2012-03-15 10:27 ` Thierry Reding
2012-03-17 10:47 ` Grant Likely
2012-03-18 9:22 ` Thierry Reding
2012-03-18 15:10 ` Arnd Bergmann
2012-03-18 18:22 ` Grant Likely
2012-03-19 13:02 ` Mark Brown
2012-03-19 15:01 ` Arnd Bergmann
2012-03-19 15:07 ` Stephen Warren
2012-03-19 15:45 ` Arnd Bergmann
2012-03-19 16:54 ` Stephen Warren
2012-03-15 16:30 ` Cousson, Benoit
2012-03-15 19:57 ` Russell King - ARM Linux
2012-03-15 20:41 ` Arnd Bergmann
2012-03-15 21:39 ` Cousson, Benoit
2012-03-15 21:55 ` Russell King - ARM Linux
2012-03-16 9:56 ` Arnd Bergmann
2012-03-20 14:02 ` Matt Porter
2012-03-15 23:45 ` Nicolas Pitre
2012-03-16 10:03 ` Arnd Bergmann
2012-03-16 11:19 ` Cousson, Benoit
2012-03-16 12:04 ` Arnd Bergmann
2012-03-16 13:28 ` Cousson, Benoit
2012-03-16 13:36 ` Nicolas Ferre
2012-03-17 9:40 ` Grant Likely
2012-03-18 20:13 ` Arnd Bergmann
2012-03-18 20:44 ` Grant Likely
2012-03-18 21:58 ` Arnd Bergmann
2012-03-18 22:12 ` Arnd Bergmann
2012-03-19 13:37 ` Nicolas Ferre
2012-03-19 15:20 ` Russell King - ARM Linux
2012-03-19 15:58 ` Cousson, Benoit
2012-03-19 13:30 ` Nicolas Ferre
2012-03-19 14:06 ` Arnd Bergmann
2012-03-19 15:33 ` Russell King - ARM Linux
2012-03-19 16:11 ` Arnd Bergmann
2012-03-19 18:06 ` Jassi Brar
2012-03-19 16:31 ` Nicolas Ferre [this message]
2012-03-19 17:49 ` Cousson, Benoit
2012-03-19 14:45 ` Grant Likely
2012-03-20 14:54 ` Nicolas Ferre
2012-03-20 10:13 ` [PATCH v2 1/2] " Nicolas Ferre
2012-03-20 10:13 ` [PATCH 2/2] of: selftest/dma: Add selftest for new DT DMA request helpers Nicolas Ferre
2012-03-20 14:16 ` Grant Likely
2012-03-20 10:17 ` [PATCH] of: dma/fixup Nicolas Ferre
2012-03-20 13:03 ` [PATCH v2 1/2] of: Add generic device tree DMA helpers Arnd Bergmann
2012-03-20 15:38 ` Stephen Warren
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=4F675F64.6070306@atmel.com \
--to=nicolas.ferre@atmel$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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