Re: Tearing down DMA transfer setup after DMA client has finished

["Måns Rullgård" <mans@mansr.com>]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> Hi Måns,
>
> On Thu, Dec 8, 2016 at 12:47 PM, Måns Rullgård <mans@mansr.com> wrote:
>> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>>> On Thu, Dec 8, 2016 at 11:54 AM, Mason <slash.tmp@free.fr> 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@intel.com> 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