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

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

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?

Thanks,
Jassi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html