On 07/26/2012 01:42 AM, Vinod Koul wrote: > 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. Ok, so are you proposing to remove the filter function and parameter from the dma_request_channel()? > Maybe for slave case we need to create dma_request_slave_channel() which > has additional arguments for dmaengine to do the filtering. Ok, so what is not clear to me is if you envision that dma_request_slave_channel() is using a mapping table based look-up or the DT scheme or both. As Arnd highlighted the DT convention is to store the DMA info in each of the device nodes and not store in a global mapping table which conflicts with having a mapping table approach for non-DT usage. So I am still not sure how you envision this function working for both the non-DT and DT use-cases. Jon -- 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
