Hi Russell, On 06/22/2012 06:12 PM, Russell King - ARM Linux wrote: > Before this goes much further... one fairly obvious and important point > must be made. > > You're designing an API here. You're designing it *WITHOUT* involving > the two most important people in its design that there are. The > DMA engine maintainers. Is this how we go about designing APIs - behind > maintainers backs and then presenting it to the maintainers as a fait > accompli? Absolutely not, this was not the intent and your point is well understood. I have added Dan and Vinod, and will ensure that he is added in future. > There's 86 messages in this thread, none of which have been copied to > them in any way. Why aren't they involved? Initially this binding was not dma-engine centric. However, I should have included them in this version from the beginning as I had evolved it in that direction. Dan, Vinod, in this thread we have been discussing the addition of a generic device-tree binding for DMA controllers. In the below, we were discussing the addition of a device-tree API, which would work as a wrapper to the dma-engine dma_request_channel() API. I apologise for adding you late into the discussion. If you have any questions/comments let me know. Jon > On Fri, Jun 22, 2012 at 05:52:08PM -0500, Jon Hunter wrote: >> Hi Arnd, >> >> On 06/14/2012 06:48 AM, Arnd Bergmann wrote: >> >> [snip] >> >>> This would let us handle the following cases very easily: >>> >>> 1. one read-write channel >>> >>> dmas = <&dmac 0x3 match>; >>> >>> 2. a choice of two read-write channels: >>> >>> dmas = <&dmacA 0x3 matchA>, <&dmacB 0x3 matchB>; >>> >>> 3. one read-channel, one write channel: >>> >>> dmas = <&dmac 0x1 match-read>, <&dmac 0x2 match-write>; >>> >>> 4. a choice of two read channels and one write channel: >>> >>> dmas = <&dmacA 0x1 match-readA>, <&dmacA 0x2 match-write> >>> <&dmacB match-readB>; >>> >>> And only the cases where we have more multiple channels that differ >>> in more aspects would require named properties: >>> >>> 5. two different channels >>> >>> dmas = <&dmac 0x3 match-rwdata>, <&dmac 0x1 match-status>; >>> dma-names = "rwdata", "status"; >>> >>> 6. same as 5, but with a choice of channels: >>> >>> dmas = <&dmacA 0x3 match-rwdataA>, <&dmacA 0x1 match-status>; >>> <dmacB 0x3 match-rwdataB>; >>> dma-names = "rwdata", "status", "rwdata"; >>> >>> >>> With a definition like that, we can implement a very simple device >>> driver interface for the common cases, and a slightly more complex >>> one for the more complex cases: >>> >>> 1. chan = of_dma_request_channel(dev->of_node, 0); >>> 2. chan = of_dma_request_channel(dev->of_node, 0); >>> 3. rxchan = of_dma_request_channel(dev->of_node, DMA_MEM_TO_DEV); >>> txchan = of_dma_request_channel(dev->of_node, DMA_DEV_TO_MEM); >>> 4. rxchan = of_dma_request_channel(dev->of_node, DMA_MEM_TO_DEV); >>> txchan = of_dma_request_channel(dev->of_node, DMA_DEV_TO_MEM); >>> 5. chan = of_dma_request_named_channel(dev->of_node, "rwdata", 0); >>> auxchan = of_dma_request_named_channel(dev->of_node, "status", DMA_DEV_TO_MEM); >>> 6. chan = of_dma_request_named_channel(dev->of_node, "rwdata", 0); >>> auxchan = of_dma_request_named_channel(dev->of_node, "status", DMA_DEV_TO_MEM); >> >> In the above examples, did you imply that the of_dma_request_channel() >> function would return a type of "struct dma_chan" and so be calling >> dma_request_channel() underneath? >> >> I am been prototyping something, but wanted to make sure I am completely >> aligned on this :-) >> >> Cheers >> 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
