Hi Jassi,

On 05/12/2012 08:40 AM, Jassi Brar wrote:

On 12 May 2012 05:21, Stephen Warren [off-list ref] wrote:

quoted

On 05/11/2012 03:06 PM, Jassi Brar wrote:

quoted

On 12 May 2012 00:58, Stephen Warren [off-list ref] wrote:

quoted

On 05/10/2012 01:59 PM, Jassi Brar wrote:

...

quoted

quoted

quoted

quoted

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.

quoted

quoted

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