Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> writes: > Hi Måns, > > On Thu, Dec 8, 2016 at 12:47 PM, Måns Rullgård <mans@xxxxxxxxx> wrote: >> Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> writes: >>> On Thu, Dec 8, 2016 at 11:54 AM, Mason <slash.tmp@xxxxxxx> wrote: >>>> 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? >>> >>> Can you fall back to PIO if requesting a channel fails? >>> >>> Alternatively, dma_request_chan() could always succeed, and >>> dmaengine_prep_slave_sg() could fail if the channel is currently not >>> available due to a limitation on the number of active channels, and >>> the driver could fall back to PIO for that transfer. >> >> Why are we debating this nonsense? There is an easy fix that doesn't >> require changing the semantics of existing functions or falling back to >> slow pio. > > You still want to fall back to PIO if the DMA engine is not available at all > (e.g. DMA engine driver not compiled in, or module not loaded). That's a choice for each device driver to make. Some devices don't have a pio mode at all. -- Måns Rullgård -- 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
