On 08/12/2016 11:39, Vinod Koul wrote: > On Wed, Dec 07, 2016 at 04:45:58PM +0000, Måns Rullgård wrote: > >> Vinod Koul <vinod.koul@xxxxxxxxx> writes: >> >>> On Tue, Dec 06, 2016 at 01:14:20PM +0000, Måns Rullgård wrote: >>>> >>>> That's not going to work very well. Device drivers typically request >>>> dma channels in their probe functions or when the device is opened. >>>> This means that reserving one of the few channels there will inevitably >>>> make some other device fail to operate. >>> >>> No that doesn't make sense at all, you should get a channel only when you >>> want to use it and not in probe! >> >> Tell that to just about every single driver ever written. > > Not really, few do yes which is wrong but not _all_ do that. Vinod, Could you explain something to me in layman's terms? I have a NAND Flash Controller driver that depends on the DMA driver under discussion. Suppose I move the dma_request_chan() call from the driver's probe function, to the actual DMA transfer function. I would want dma_request_chan() to put the calling thread to sleep until a channel becomes available (possibly with a timeout value). But Maxime told me dma_request_chan() will just return -EBUSY if no channels are available. Am I supposed to busy wait in my driver's DMA function until a channel becomes available? I don't understand how the multiplexing of few memory channels to many clients is supposed to happen efficiently? Regards. -- 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
