From: b-cousson@ti•com (Cousson, Benoit)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] of: Add generic device tree DMA helpers
Date: Fri, 16 Mar 2012 14:28:32 +0100 [thread overview]
Message-ID: <4F634000.8010408@ti.com> (raw)
In-Reply-To: <201203161204.19800.arnd@arndb.de>
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?
Thanks,
Benoit
next prev parent reply other threads:[~2012-03-16 13:28 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 [this message]
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
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=4F634000.8010408@ti.com \
--to=b-cousson@ti$(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