From: jon-hunter@ti•com (Jon Hunter)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH V3 1/2] of: Add generic device tree DMA helpers
Date: Fri, 4 May 2012 14:26:38 -0500 [thread overview]
Message-ID: <4FA42D6E.5040106@ti.com> (raw)
In-Reply-To: <201205041906.13959.arnd@arndb.de>
Hi Arnd,
On 05/04/2012 02:06 PM, Arnd Bergmann wrote:
> On Friday 04 May 2012, Jon Hunter wrote:
>
>>>
>>> I believe this is not entirely correct: sometimes the filter_fn is provided
>>> by the slave driver, sometimes by the master driver.
>>
>> Ok, but in the master case I assume they still use the same API?
>
> The all use dma_request_channel, but the format of the data that gets
> passed depends only on whoever provides the filter function, which
> is not necessarily the slave or the master, but could be either one.
>
> FWIW, I believe that for each dma engine implementation we only do
> one or the other, i.e. if the dmaengine driver provides a filter function,
> it is always used with these devices.
Ok, I think I am with you now. That should be fine.
>>>>
>>>> Next we need to think about how the DMA controller and channels are described
>>>> in the device tree itself. The following device tree node example describes
>>>> the properties of the DMA controller that includes, the register address
>>>> range, number of interrupt supported, number of channels and number of request
>>>> signals. This has been enhanced from the previous versions by adding number of
>>>> channels and number of request signals.
>>>
>>> I think you can actually use strings, too, as long as you use a fixed number
>>> of cells.
>>>
>>> Wouldn't something like this work:?
>>>
>>> dma-controller1: dma1 {
>>> compatible = "something-using-strings";
>>> #dma-cells = <1>;
>>> };
>>>
>>> dma-controller2: dma2 {
>>> compatible = "something-using-integers";
>>> #dma-cells = <3>
>>> };
>>>
>>> some-device {
>>> compatible = "something";
>>> dmas = <&dma-controller1>, "some-dma",
>>> <&dma-controller2 1 2 3>;
>>> }
>>>
>>> The only hard requirement is that the format of the attributes is
>>> what the binding specific to that controller understands.
>>
>> Yes it could. My point was why do this, if at the end of the day you
>> need to resolve the string into a number at some point in the driver?
>> However, this may make the migration easier for those using strings.
>
> Well, actually Stephen just clarified that we should not use strings
> here :(
> We will always have to use numbers then.
Ok. I think it makes life easier in the long run too.
>>> I think a better interface for the device driver would be something that combines
>>> your of_get_dma_channel_info() function with the dma_request_channel() function,
>>> like
>>>
>>> struct dma_chan *of_dma_request_channel(struct device_node *dn, int index);
>>>
>>> When we have the device tree, the driver using that channel doesn't actually have
>>> to care about the specific of how the channel is defined any more, it just needs
>>> to say which one it's interested in, out of the list of channels defined for that
>>> device node.
>>
>> Yes true. I was trying to avoid any changes to DMA engine itself. Plus
>> in the feedback from Stephen his preference was to isolate the binding
>> from DMA engine.
>>
>> So in your example, is index passed via dma_request_channel()? I assume
>> that of_dma_request_channel() get called in the context of
>> dma_request_channel somewhere???
>
> What I meant what that you should still provide the existing
> dma_request_channel interface without changes, and also provide
> of_dma_request_channel as a wrapper around it that does a lookup
> in the way that your of_get_dma_channel_info does, passing the
> data it gets back from the device tree into the filter function
> that was provided by the dma engine driver.
Ok, gotcha.
>> By the way, have you looked at the pl330_filter() function
>> (drivers/dma/pl330.c)? They parse the device-tree in the filter function
>> itself. The index could be passed as the filter_param. In this type of
>> implementation there would be no need for a generic dma binding.
>> However, would only work for devices supporting DMA engine.
>
> IMHO this will have to change, we should not have allowed a nonstandard
> binding for pl330 to be used for the samsung platforms and should migrate
> to the new binding as soon as possible.
Ok, that's fine with me.
Cheers
Jon
next prev parent reply other threads:[~2012-05-04 19:26 UTC|newest]
Thread overview: 129+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-30 21:17 [PATCH V3 1/2] of: Add generic device tree DMA helpers Jon Hunter
2012-05-03 22:26 ` Stephen Warren
2012-05-03 23:25 ` Russell King - ARM Linux
2012-05-04 12:39 ` Arnd Bergmann
2012-05-04 15:06 ` Jon Hunter
2012-05-04 15:14 ` Russell King - ARM Linux
2012-05-04 18:21 ` Stephen Warren
2012-05-04 19:19 ` Jon Hunter
2012-05-04 6:56 ` Jassi Brar
2012-05-04 15:17 ` Jon Hunter
2012-05-04 19:01 ` Jassi Brar
2012-05-04 19:23 ` Arnd Bergmann
2012-05-05 17:10 ` Jassi Brar
2012-05-07 15:53 ` Stephen Warren
2012-05-07 17:19 ` Jassi Brar
2012-05-08 16:35 ` Stephen Warren
2012-05-08 19:09 ` Jassi Brar
2012-05-09 12:30 ` Arnd Bergmann
2012-05-09 19:10 ` Stephen Warren
2012-05-09 21:38 ` Jassi Brar
2012-05-10 17:00 ` Stephen Warren
2012-05-10 19:59 ` Jassi Brar
2012-05-11 19:28 ` Stephen Warren
2012-05-11 21:06 ` Jassi Brar
2012-05-11 23:51 ` Stephen Warren
2012-05-12 13:40 ` Jassi Brar
2012-05-16 1:05 ` Jon Hunter
2012-05-17 13:18 ` Russell King - ARM Linux
2012-05-07 17:21 ` Arnd Bergmann
2012-05-16 1:11 ` Jon Hunter
2012-05-16 12:37 ` Jassi Brar
2012-05-16 13:15 ` Jon Hunter
2012-05-16 15:44 ` Stephen Warren
2012-05-16 16:04 ` Jon Hunter
2012-05-16 16:01 ` Jon Hunter
2012-05-16 16:15 ` Stephen Warren
2012-05-16 16:22 ` Jassi Brar
2012-05-16 17:09 ` Jon Hunter
2012-05-16 19:42 ` Arnd Bergmann
2012-05-16 21:16 ` Jassi Brar
2012-05-17 19:32 ` Stephen Warren
2012-05-18 17:12 ` Jassi Brar
2012-05-18 21:04 ` Arnd Bergmann
2012-05-16 23:59 ` Stephen Warren
2012-05-17 4:05 ` Jassi Brar
2012-05-18 20:49 ` Arnd Bergmann
2012-05-18 21:07 ` Stephen Warren
2012-05-18 21:43 ` Arnd Bergmann
2012-05-18 22:20 ` Stephen Warren
2012-05-19 8:44 ` Arnd Bergmann
2012-05-21 17:33 ` Stephen Warren
2012-05-21 18:18 ` Arnd Bergmann
2012-05-21 20:32 ` Stephen Warren
2012-06-08 19:04 ` Jon Hunter
2012-06-09 0:04 ` Arnd Bergmann
2012-06-13 22:32 ` Jon Hunter
2012-06-14 4:45 ` Jassi Brar
2012-06-14 11:48 ` Arnd Bergmann
2012-06-14 15:39 ` Jon Hunter
2012-06-15 8:40 ` Arnd Bergmann
2012-06-22 22:52 ` Jon Hunter
2012-06-22 23:12 ` Russell King - ARM Linux
2012-06-25 16:51 ` Jon Hunter
2012-06-25 18:04 ` Vinod Koul
2012-06-25 20:30 ` Arnd Bergmann
2012-06-26 9:40 ` Vinod Koul
2012-06-26 14:59 ` Arnd Bergmann
2012-06-26 17:50 ` Vinod Koul
2012-06-26 20:27 ` Arnd Bergmann
2012-06-27 13:45 ` Vinod Koul
2012-06-27 15:20 ` Arnd Bergmann
2012-07-13 6:45 ` Vinod Koul
2012-07-13 21:52 ` Guennadi Liakhovetski
2012-07-17 19:24 ` Arnd Bergmann
2012-07-20 4:00 ` Vinod Koul
2012-07-20 8:39 ` Arnd Bergmann
2012-07-20 9:37 ` Vinod Koul
2012-07-24 19:07 ` Jon Hunter
2012-07-24 19:27 ` Arnd Bergmann
2012-07-26 6:42 ` Vinod Koul
2012-07-26 7:14 ` Arnd Bergmann
2012-07-26 11:28 ` Vinod Koul
2012-07-26 15:53 ` Jon Hunter
2012-07-31 11:06 ` Vinod Koul
2012-07-26 17:43 ` Jon Hunter
2012-07-31 11:12 ` Vinod Koul
2012-08-01 20:43 ` Jon Hunter
2012-08-03 9:55 ` Vinod Koul
2012-07-20 9:08 ` Robert Jarzmik
2012-07-20 9:41 ` Vinod Koul
2012-07-26 4:56 ` zhangfei gao
2012-07-23 21:29 ` Stephen Warren
2012-07-24 7:19 ` Arnd Bergmann
2012-07-24 16:04 ` Stephen Warren
2012-07-24 18:55 ` Arnd Bergmann
2012-07-24 12:54 ` Sergei Shtylyov
2012-07-06 11:36 ` Guennadi Liakhovetski
2012-07-06 15:28 ` Arnd Bergmann
2012-07-06 15:43 ` Guennadi Liakhovetski
2012-07-06 17:31 ` Arnd Bergmann
2012-07-06 21:01 ` Russell King - ARM Linux
2012-07-06 20:57 ` Russell King - ARM Linux
2012-07-06 22:49 ` Guennadi Liakhovetski
2012-07-13 6:51 ` Vinod Koul
2012-06-14 15:17 ` Guennadi Liakhovetski
2012-06-14 21:52 ` Jon Hunter
2012-06-15 8:41 ` Guennadi Liakhovetski
2012-06-15 9:00 ` Arnd Bergmann
2012-06-15 9:18 ` Guennadi Liakhovetski
2012-06-15 11:27 ` Arnd Bergmann
2012-06-15 16:11 ` Mitch Bradley
2012-06-16 6:56 ` Arnd Bergmann
2012-06-21 11:21 ` Guennadi Liakhovetski
2012-06-21 14:56 ` Arnd Bergmann
2012-05-17 13:22 ` Russell King - ARM Linux
2012-05-17 13:52 ` Mark Brown
2012-05-17 14:16 ` Russell King - ARM Linux
2012-05-16 16:16 ` Jassi Brar
2012-05-16 17:12 ` Jon Hunter
2012-05-16 17:24 ` Jassi Brar
2012-05-16 17:37 ` Jon Hunter
2012-05-16 17:46 ` Stephen Warren
2012-05-16 18:03 ` Jon Hunter
2012-05-04 15:22 ` Jon Hunter
2012-05-04 15:56 ` Arnd Bergmann
2012-05-04 17:19 ` Jon Hunter
2012-05-04 19:06 ` Arnd Bergmann
2012-05-04 19:26 ` Jon Hunter [this message]
2012-05-04 18:30 ` 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=4FA42D6E.5040106@ti.com \
--to=jon-hunter@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