Thread (78 messages) 78 messages, 7 authors, 2012-06-22

[PATCH V3 1/2] of: Add generic device tree DMA helpers

From: Stephen Warren <hidden>
Date: 2012-05-21 17:33:52
Also in: linux-devicetree, linux-omap

On 05/19/2012 02:44 AM, Arnd Bergmann wrote:
On Friday 18 May 2012, Stephen Warren wrote:
quoted
On 05/18/2012 03:43 PM, Arnd Bergmann wrote:
quoted
quoted
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.
quoted
quoted
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.
How are you thinking of representing the direction in DT - as part of
the DMA request specifier, so in a DMAC-specific way?

If so, that seems a little odd; you have to request a DMA channel for
"TX", but then end up having the common code check all the entries in
the dmas property since it can't know which are TX, and then have the
wrong ones almost accidentally fail, since the DMAC will then determine
that it can't support TX on the RX DMA request IDs.

If not, then presumably there's going to be a cell for "direction", so
it may as well just be a cell for "outgoing DMA request ID" - the two
are equivalent in the simple case.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help