From: nicolas.ferre@atmel•com (Nicolas Ferre)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] of: Add generic device tree DMA helpers
Date: Fri, 16 Mar 2012 14:36:05 +0100 [thread overview]
Message-ID: <4F6341C5.4060009@atmel.com> (raw)
In-Reply-To: <4F634000.8010408@ti.com>
On 03/16/2012 02:28 PM, Cousson, Benoit :
> On 3/16/2012 1:04 PM, Arnd Bergmann wrote:
>> On Friday 16 March 2012, Cousson, Benoit wrote:
>>> And it seems that other ARM SoCs are using it for the same purpose.
>>> There are at least 230+ IORESOURCE_DMA instances in the kernel today.
>>
>> These tend to be the ones that don't use dmaengine but either the
>> ISA dma api or a platform specific variant of that, right?
>>
>> Also, I think that most of those definitions are for the same few
>> devices. The number that I see is much lower:
>>
>> $ git grep -l IORESOURCE_DMA drivers/ sound/ | wc -l
>> 51
>
> Gosh, good point... I've just done a dumb grep, but most of them are in
> the device creation inside arch code:-(
>
> Assuming OMAP driver does contains omap in the name, the result is
> indeed way smaller.
>
> git grep -l IORESOURCE_DMA drivers/ sound/ | grep omap
>
> drivers/crypto/omap-aes.c
> drivers/crypto/omap-sham.c
> drivers/spi/spi-omap2-mcspi.c
> drivers/tty/serial/omap-serial.c
> sound/soc/omap/omap-dmic.c
> sound/soc/omap/omap-hdmi.c
>
> We do have 127 DMA requests and only 6 drivers are using them, that's a
> pity...
>
>> Out of those, a quite number are mips or blackfin or xtensa based, or are
>> for legacy ISA devices, which leaves 29 drivers for ARM.
>>
>>> For the moment it is still used in a lot of places, and without any
>>> other better API yet, it is still useful. As written it is there only
>>> for simple single DMA controller case.
>>>
>>> By maintaining that IORESOURCE_DMA for the moment we can adapt some
>>> driver to DT without having to change the way they are retrieving
>>> information. By using IORESOURCE_IRQ and IORESOURCE_MEM, we had the same
>>> advantage.
>>
>> The main difference to IORESOURCE_IRQ and IORESOURCE_MEM that I see
>> is that those are going to start for any forseeable time and are actually
>> helpful in a lot of ways. We are not going to remove the single number
>> space for interrupts in the next few years. For DMA, the dmaengine API
>> has already moved away from the flat number space of the ISA API.
>>
>>> Otherwise how are we supposed to get the DMA channel for non-DT boot
>>> until we have migrated everything to DT? A bunch of ARM SoC are using
>>> IORESOURCE_DMA for the same purpose.
>>>
>>> The goal here is really to maintain that during the transition phase
>>> only. As soon as the full DT support is there, we can switch to the
>>> of_ API.
>>>
>>> Ideally, we should define and use a generic API non dependent of DT.
>>> AFAIK, that does not exist so far.
>>> And since most drivers are not using dmaengine, we do not even have a
>>> common DMA fmwk to define an API on top.
>>>
>>> I fully agree that this IORESOURCE_DMA is not scalable for multiple
>>> controller, ugly, and must be avoided like the plague.
>>> But what other options do we have during the transition?
>>
>> We could use the same binding for the nonstandard controllers, but
>> keep the dma channel number lookup separate for those, and let them
>> call of_get_dma_request directly.
>>
>> Since there are not too many drivers using those controllers with
>> dma resources today, it's fairly easy to go through those as we write
>> the driver bindings and just do
>>
>> err = of_get_dma_request(pdev->dev.of_node, 0,&dma);
>> if (err) {
>> struct resource *r = platform_get_resource(pdev,
>> IORESOURCE_DMA, 0);
>> if (r)
>> dma = r->start;
>> }
>>
>> For the drivers that we convert to DT before we convert them to
>> dmaengine,
>> and not do anything if we convert them to dmaengine first.
>
> Considering the small amount of OMAP drivers really using
> IORESOURCE_DMA, I guess this is fair enough.
>
> Bottom-line, I do not have any more issue removing this of_dma_to_resource.
>
>
> Nico,
> Is that OK for you to repost the patch without this function?
Yes sure, I will repost a V2 soon.
I also try to have an integration in DT selftest.c:
- that will show some possibilities of the API
- that will give some examples of usage (1 or 2 xlate() functions)
- that made me review my code and find a weakness
- that will allow to monitor non-regression (obviously)
=> WIP...
Bye,
--
Nicolas Ferre
next prev parent reply other threads:[~2012-03-16 13:36 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 [this message]
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
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=4F6341C5.4060009@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