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 -- 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
