(Optional?) DMA vs. PIO

[Stephen Warren]

Andy Shevchenko wrote at Thursday, October 8, 2020 9:06 AM:
> During internal review of one patch I have been puzzled with the following code
> and Pierre suggested to ask mailing list for help.
> 
> My main concern is what was the idea behind? Does it mean we support optional
> DMA in such case? If now, why not to return an error code directly?
> 
> ---8<---8<---8<---
> 
> > Why ASoC core has the following code in the first place:
> >
> > 387              chan = dma_request_chan(dev, name);
> > 388              if (IS_ERR(chan)) {
> > 389                      if (PTR_ERR(chan) == -EPROBE_DEFER)
> > 390                              return -EPROBE_DEFER;
> > 391                      pcm->chan[i] = NULL;
> > 392              } else {
> > 393                      pcm->chan[i] = chan;
> > 394              }
> >
> > (note lines 389-391).
> > If PIO fallback is not okay, why not to return an error there?
> 
> no idea, the code has been this way since 2013
> (5eda87b890f867b098e5566b5543642851e8b9c3)

It's been there a bit longer, in fact since the file was created:

commit 28c4468b00a1e55e08cc20117de968f7c6275441
Author: Lars-Peter Clausen <lars at metafoo.de>
Date:   Mon Apr 15 19:19:50 2013 +0200

    ASoC: Add a generic dmaengine_pcm driver

+               pcm->chan[i] = of_dma_request_slave_channel(dev->of_node,
+                                       dmaengine_pcm_dma_channel_names[i]);

The commit you mentioned above simply prevents the code from taking the "no DMA
available" path if deferred probe occurs.

> It's worth asking the question on the mailing list, I don't know if this is a
> bug or a feature.

This does seem like a bug, but there are a few places in the code which explicitly check
for a NULL chan or dma_dev (derived from chan) object, so it seems deliberate.