public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: nicolas.ferre@atmel•com (Nicolas Ferre)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
Date: Mon, 27 Feb 2012 18:28:02 +0100	[thread overview]
Message-ID: <4F4BBD22.6090104@atmel.com> (raw)
In-Reply-To: <4F4B91B8.8000805@ti.com>

On 02/27/2012 03:22 PM, Cousson, Benoit :
> On 2/27/2012 2:09 PM, Nicolas Ferre wrote:
>> On 02/23/2012 04:57 PM, Cousson, Benoit :
>>> On 2/23/2012 4:51 PM, Nicolas Ferre wrote:
>>>> On 02/23/2012 11:03 AM, Cousson, Benoit :
>>>>> Salut Nico,
>>>>
>>>> Coucou Benoit ;-)
>>>>
>>>>> On 2/22/2012 11:59 AM, Nicolas Ferre wrote:
>>>>>> On 01/27/2012 06:29 PM, Cousson, Benoit :
>>>>>>> Add some basic helpers to retrieve a DMA controller device_node
>>>>>>> and the DMA request line number.
>>>>>>>
>>>>>>> For legacy reason another API will export the DMA request number
>>>>>>> into a Linux resource of type IORESOURCE_DMA.
>>>>>>> This API is usable only on system with an unique DMA controller.
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I followed that discussion and I like very much the biding that
>>>>>> Benoit
>>>>>> is proposing. It will help me a lot with my current work on Atmel DMA
>>>>>> controller.
>>>>>>
>>>>>> If I understand correctly, some rework is needed before it can be
>>>>>> integrated in a stable git tree (I mean before we can base our
>>>>>> work on
>>>>>> top of it). So, in the meantime, what should I do to help and make
>>>>>> things go forward? to be quite frank, I would be interested to have a
>>>>>> working DMA enabled device soon ;-)
>>>>>
>>>>> Me too, but unfortunately, I was busy trying to add irq_domain and
>>>>> fixing issues with SPARSE_IRQ on OMAP :-(
>>>>
>>>> Been there, loved that ;-)
>>>>
>>>>>> Do you think that 3.4 is out of reach?
>>>>>
>>>>> Maybe not, from the comments, it looks like we should add a .xlate
>>>>> callback to allow any custom parsing of the DMA nodes attributes.
>>>>>
>>>>> I'll be more than happy, if you can finalize that patch :-)
>>>>
>>>> I will try to figure out what I can understand from the irq
>>>> mechanism of
>>>> .xlate and try to see if I can implement it on top of your patch.
>>>
>>> In fact that dma code is a big copy/paste of the of/gpio one and gpio
>>> was already managing .xlate function.
>>> I removed it because I thought it was useless for the DMA :-)
>>>
>>> You might just have to copy the original code...
>>
>> The thing is that with gpio, we can rely on the gpio_chip structure for
>> having a common storage location of such .xlate callbacks.
>> In our DMA case, I guess that we should not cling to dmaengine
>> infrastructure because not all of us are using it right now.
> 
> Yep, that's the main issue compared to GPIO or IRQ.
> 
>> So, maybe we should provide some simple "xlate" helpers like the
>> irqdomain ones. But I fear that a "callback" directly called from the
>> of_get_dma_request() function is not possible (the gpio code model).
> 
> I think a well that we cannot much but a simple very abstract callback
> since we do not have any formal DMA representation?
> 
> I'm not sure to understand you concern?

Well, in fact I cannot find a place where to store a "xlate" callback:
- it have to be provided by the DMA controller (the one pointed out by
the phandle) and not the caller of the of_get_dma_request() funtion
- it has to be generic enough to match the dmaengine/non-dmaengine cases
(so it cannot be stored in the dmaengine "struct dma_device").

So I guess that the very basic idea of returning the full DMA specifier
(struct of_phandle_args) is the best... My only concern is that the
"helper" becomes very short and empty in this case...

Bye,
-- 
Nicolas Ferre

  reply	other threads:[~2012-02-27 17: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 [this message]
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
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=4F4BBD22.6090104@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