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

[Vinod Koul]

On Tue, 2012-07-24 at 14:07 -0500, Jon Hunter wrote:
> Hi Vinod,
> >>>> 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".
> > No we don't export the direction of the channel and usually channel can
> > be configured either way.
> 
> So yes I can see that a channel itself could be configured to support a
> given direction, but when we ask for a channel via dma_request_channel()
> we are going to get a channel that matches the criteria we pass using
> the filter parameter. So here the thinking was that "flags" is a filter
> parameter that the user could specify and one example being direction
> but it could be something else too.
Yes that can be done, but I am leaning towards clients not have to do
anything :) DMAEngine needs to know mapping and when
dma_request_channel() is called it _always_ gives you the right channel.

Maybe for slave case we need to create dma_request_slave_channel() which
has additional arguments for dmaengine to do the filtering.


> > But from a client POV it makes sense as with the given direction you
> > would need a specific request line for a channel. So this is right.
> > But direction is something I don't expect to be used for "give me a
> > channel" 
> 
> Ok. The thought was that the user would have the following means of
> requesting a channel ...
> 
> 1. By name
Bare name maynot be enough. In a dmac we have many channels which one to
choose?
> 2. By a filter parameter (flags)
Even with direction same problem can arise
> 3. By name and a filter parameter
Additionally we need to say which channel, or making dmaengine already
aware will help here

> 
> So we would have the following APIs ...
> 
> struct dma_chan
> *of_dma_request_channel(struct device_node *node, unsigned int flags);
> struct dma_chan
> *of_dma_request_named channel(struct device_node *node, char *name,
> unsigned int flags);
> 
> In both of these the filter parameter flags is optional.
> 
> Let me know your thoughts on this.
I would call them dma_request_slave_channel and try to add to it for
additional filtering



-- 
~Vinod