[PATCH V3 1/2] of: Add generic device tree DMA helpers
Arnd Bergmann
arnd at arndb.de
Sat May 19 04:44:03 EDT 2012
On Friday 18 May 2012, Stephen Warren wrote:
> On 05/18/2012 03:43 PM, Arnd Bergmann wrote:
> > So if we do that, we might want to make the dma-names property mandatory
> > for every device, and document what the names are.
>
> We could do that, but one more proposal: Add the client's ID/index into
> the dmas property, so:
>
> simple 1 req:
>
> dmas = <0 &dmac1 xxx>;
>
> simple 2 req:
>
> dmas = <0 &dmac1 xxx 1 &dmac1 yyy>;
>
> multiple dmacs:
>
> dmas = <0 &dmac1 xxx 0 &dmac2 zzz 1 &dmac1 yyy>;
>
> (i.e. dmas = [client_dma_req_id phandle dma-specifier]*)
>
> (where 0==TX_FIFO, 1=RX_FIFO for example, but could also have
> 2=TX_FIFO_B, 3=RX_FIFO_B, ...)
>
> Then dma-names would map name to ID, but you'd still need to search all
> through the dmas property to find the ID match.
Again, this would probably work, but it adds complexity and inconsistency
for the common case, as nothing else requires these. I think it's much
better than putting the information into the dma controller node, but
not ideal.
> > Another option would be to encode the direction in the property in
> > a generic way and provide an API that lets you ask specifically
> > for a read, write or readwrite channel out of the ones that are
> > available, rather than assuming there is only one kind. Consequently,
> > any device that uses more than one read channel or more than one
> > write channel would still have to use names to identify them.
>
> I'm not sure that just direction cuts it; Tegra's SPDIF has 2 TX DMAs
> ("PCM" data and control data) and same for RX. The format above is
> roughly the same as what you proposed, but with an explicit ID rather
> than direction in the dmas property.
The point with the direction was that it covers most cases and makes
them rather simple, while for the rare case where you need more than
two channels, you just use the otherwise optional named interface
rather than the numbered one. My feeling is that this also makes a
lot of sense at the driver API level: most dirvers just ask for the
read and write channels using a very simple interface, and those drivers
that have more than two will want to name them anyway.
Arnd
More information about the linux-arm-kernel
mailing list