On 19/04/16 15:18, Arnd Bergmann wrote: > On Tuesday 19 April 2016 14:59:49 Jon Hunter wrote: >> On 19/04/16 14:25, Vinod Koul wrote: >>> On Mon, Apr 18, 2016 at 04:06:23PM +0100, Jon Hunter wrote: >>>> On 14/04/16 12:04, Jon Hunter wrote: >>>>> I had a look at this, but actually, I don't think this is going to work. >>>>> >>>>> Looking at dma_request_channel(), it is going to get a DMA channel that >>>>> matches the mask for any DMA controller. In the xlate I already know >>>>> which DMA controller I am and I just want one of the channels. The flow >>>>> here is ... >>>>> >>>>> dma_request_chan() >>>>> --> of_dma_request_slave_channel() >>>>> --> xlate() >>>>> --> dma_get_any_slave_channel() >>>>> >>>>> There are several other DMA drivers that are calling >>>>> dma_get_any_slave_channel() from their xlate function which makes sense >>>>> because they are requesting one of their own channels. >>>>> >>>>> I can understand that you wish to consolidate the APIs for requesting a >>>>> channel, but it seems to me that you still need to have an API that DMA >>>>> controller drivers can call where they can pass their dma_device >>>>> structure to ensure you get a channel for the appropriate DMA controller. >>> >>> Yes but the idea was that xlate will help you to get the right channel. The >>> whole dmaengine property was supposed to help you with that >> >> Well it depends on the DMA controller. In the case of tegra the xlate >> helps you extract the slave request ID for a given device. However, >> because any channel can be used with any slave request ID, we don't care >> about the exact channel. So we request any available channel for the DMA >> controller in question and program it with the slave request we got from >> the xlate. > > Right. the cleanup was supposed to reduce the number of interfaces > that a slave driver can call and consolidate them as much as possible > into dma_request_chan(), but we still need dma_get_any_slave_channel() > as an interface for the dmaengine masters as you said. OK, great. Vinod, are you ok with this then? Any other items to fix-up? >> I have seen some DMA drivers (such as imx-dma) use the filter function >> to match the DMA controller, but it seems daft to use the filter >> function to match the DMA controller when we already know in the xlate >> which DMA controller we are. > > The filter functions should ideally all go away after the cleanup > is complete. Wonderful! Thanks for the info. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
