On Friday 20 July 2012, Vinod Koul wrote:
> > Required property:
> > dmas: list of one or more dma specifiers, each consisting of
> > - phandle pointing to dma controller node
> > - flags word, a bit map that can hold these flags
> > * 0x00000001 channel can be used for transfer from device
> > * 0x00000002 channel can be user for transfer to device
>
> Is this for identifying which channel is for TX and RX? If not I am not
> sure I understood it well
Yes, but we can potentially add more flags here.
The argument we had when coming up with this was roughly:
* we need to identify which specifiers are referring to the same
conceptual channel and can be used as alternatives
* this could be done just using the dma-names property, but making
dma-names mandatory adds complexity for everyone.
* Most devices have just one or two channels, and if they have two,
there is usually one input and one output.
=> if the common dmaengine code can find out whether a channel is
input or output without looking at the dmac driver specific configuration,
we don't need to add dma-names in most cases, but just let the client
driver ask for "give me a channel with these flags".
> > 4. A dma controller requiring complex configuration:
> >
> > dma: dmaengine@48000000 {
> > compatible = "foo,foo-sdma"
> > reg = <0x48000000 0x1000>;
> > interrupts = <4>;
> > #dma-cells = <6>; /* phandle, flag, request, channel,
> > input-width, output-width */
>
> Why would we want the widths to be here?
> Assuming a DMA from System memory to a peripheral, source width should
> be system memory width and destination the peripheral width. IMO these
> should not be in dma property even if we need these
I was just trying to come up with an example of something we might put
into the additional configuration fields. This may or may not be a
realistic one, I have no idea. If you know something else that one
of the dma controllers might want to put in there, we should change the
example.
I took the example of data width from 'struct stedma40_chan_cfg', which
is used in some places to configure this from platform data. My
impression was that if we want to move that data from board files into
the device tree, it has to be here, but it can well be that there is
a better place for it, e.g. in the global (channel independent)
configuration of the dmac.
Arnd
--
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
