Hi Jassi,
On 05/12/2012 08:40 AM, Jassi Brar wrote:
> On 12 May 2012 05:21, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
>> On 05/11/2012 03:06 PM, Jassi Brar wrote:
>>> On 12 May 2012 00:58, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
>>>> On 05/10/2012 01:59 PM, Jassi Brar wrote:
>> ...
>>>>>> client0: i2s {
>>>>>> /* has 2 DMA request output signals: 0, 1 */
>>>>>> };
>>>>>>
>>>>>> client1: spdif {
>>>>>> /* has 2 DMA request signals: 0, 1 */
>>>>>> };
>>>>>>
>>>>> Do we also need to somehow tag these signals for the client to
>>>>> differentiate between TX and RX channel ?
>>>>
>>>> Yes, the client's DT binding would certainly need to describe how many
>>>> DMA request signals its HW generates, and give a unique ID to each. The
>>>> driver would need to request a DMA channel for a specific one of its DMA
>>>> requests.
>>>>
>>> Did I read "give a unique ID to each" correctly ?
>>
>> It'd be unique relative to that individual device or DT node, not at any
>> larger scope.
>>
> OK.
>
>>> Could you please take some time out to jot down an example of how a
>>> typical client's dma specifier should look.
>>
>> With this proposal, I'm not sure that the client DT node would need any
>> DMA information at all, at least nothing that identifies which DMA
>> controllers, channels, or requests are required to service this
>> node/device's DMA requests - that routing information is all represented
>> in the DMA controller itself.
>>
>> (I think Arnd made the following point earlier in this thread):
>>
>> If you did need to put any other information in DT, then that probably
>> would go in the DMA client node, since it'd presumably be the same
>> irrespective of which DMA controller got used. However, that information
>> presumably wouldn't be needed in DT at all, since the driver would know
>> it, since it'd be a facet of the HW.
>>
>> Note: I'm thinking things like DMA physical address (presumably an
>> offset from the reg property), DMA access size (presumably a fixed
>> property of the HW), DMA burst size (presumably a property of the HW,
>> although at least some HW can be programmed to raise the DMA request
>> signal with a varying number of FIFO entries free, so not fixed), etc.
>>
> Yeah, neither did I think a client node should tell more than IDs of
> its channels
> - which we now decide to simply mention in its binding.
>
> How do I know if you or someone is interested in reworking the patchset
> or want me to give it a try?
Sorry for not participating more in the discussion here, but I got tied
up. I was planning on a V4 on the patch-set last week, but it did not
happen. So I was planning for it this week. The V4 I had in mind was a
more generic version of what I previously submitted, using xlate
function to permit different DT tree formats. However, there would be a
couple default xlate functions for people to use.
I am concerned that this implementation may not address all your
concerns. So if you have something to propose then please feel free to
do so.
By the way, what it unclear to me, if you have a client that could use
more than one channel of multiple controllers, how is the handled? Who
makes the decision on which to use?
The TI DMAs are somewhat inflexible and simple in this manner that you
don't have a choice :-)
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
