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.
> 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.
> FWIW, I think I can live with what you propose. Let us go for the kill.
--
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
