Re: Question: dmaengine: dma_request_chan_by_mask() and DMA controller probe order

["Péter Ujfalusi" <peter.ujfalusi@gmail.com>]

Hi,

On 4/19/23 11:27, Vaishnav Achath wrote:
> Hi,
> 
> In dma_request_chan_by_mask() , the probe defer logic returns -EPROBE_DEFER if
> there are no DMA devices registered yet. But in case of multiple DMA controllers
> in an SoC and when only one(or a subset) of the controllers have finished probe
> dma_request_chan_by_mask() can return -ENODEV incorrectly since the first DMA
> device probed might not support the particular mask requested.

That change was added by
ec8ca8e3b4809 ("dmaengine: dma_request_chan_by_mask() to handle deferred
probing")
Which apparently only works if we have a single DMA controller or
multiple with similar capabilities.

> What is the recommended solution to avoid situation like these?

I would say, that in case of dma_request_chan_by_mask() it might be
reasonable to return -EPROBE_DEFER if the mask cannot be satisfied with
the probed DMA controllers.
With the dma_request_chan() we know which DMA we are waiting for while
with the give me any channel which can do this, we don't.

On the other hand we have users where they fallback to CPU memcpy or PIO
mode if a DMA channel is not available, returning -EPROBE_DEFER would
break them for sure.

Probably a notification system of some sort or deferred channel request
with a callback?

> Consider the following scenario for example:
> 
> SoC has two DMA controllers, one instance of system DMA, one dedicated for
> Camera subsytem which does not support DMA_MEMCPY and has lesser number of channels.
> 
> * Camera subsystem DMA is probed first.
> * Another peripheral requests dma_request_chan_by_mask(DMA_MEMCPY)
> * dmaengine returns -ENODEV for above as the controller with DMA_MEMCPY support
> is not ready yet.
> * System DMA is probed later but peripheral driver failed to start with DMA.

A while ago I have sent a series to add support for 'dma-domains':
https://lkml.kernel.org/lkml/20190906141816.24095-1-peter.ujfalusi@ti.com/

That would handle this use case fine. Looks like I did not had time to
update (or rewrite?) it based on the comments...

-- 
Péter