Re: [alsa-devel] of_dma_request_slave_channel() failed ?

Hi Morimoto-san,

CC asoc, dma, iommu

On Tue, Sep 4, 2018 at 8:06 AM Kuninori Morimoto kuninori.morimoto.gx@renesas.com wrote:

Hi Renesas ML Cc Rob

I noticed that Sound driver is using PIO mode on latest kernel.

    ...
    rcar_sound ec500000.sound: src[0] : probe error -11
    rcar_sound ec500000.sound: ssi[0] fallback to PIO mode
    rcar_sound ec500000.sound: src[1] : probe error -11
    rcar_sound ec500000.sound: ssi[1] fallback to PIO mode
    rcar_sound ec500000.sound: ssi[2] : probe error -11
    rcar_sound ec500000.sound: ssi[2] fallback to PIO mode
    rcar_sound ec500000.sound: ssi[3] : probe error -11
    rcar_sound ec500000.sound: ssi[3] fallback to PIO mode
    rcar_sound ec500000.sound: probed
    ...

Sound can use DMA mode and PIO mode. It automatically fallbacks to PIO mode if it can't use DMA.

I bisected this issue, and found the 1st bad commit

---

commit ac6bbf0cdf4206c517ac9789814c23e372ebce4d Author: Rob Herring robh@kernel.org Date: Mon Jul 9 09:41:52 2018 -0600

iommu: Remove IOMMU_OF_DECLARE

Now that we use the driver core to stop deferred probe for missing
drivers, IOMMU_OF_DECLARE can be removed.

This is slightly less optimal than having a list of built-in drivers in
that we'll now defer probe twice before giving up. This shouldn't have a
significant impact on boot times as past discussions about deferred
probe have given no evidence of deferred probe having a substantial
impact.
    ...

---

In more detail, it seems it can't find DMA controller, and of_dma_request_slave_channel() returns -EPROBE_DEFER from this commit.

struct dma_chan *of_dma_request_slave_channel(struct device_node *np, const char *name) { ... ofdma = of_dma_find_controller(&dma_spec);

            if (ofdma) {
                    chan = ofdma->of_dma_xlate(&dma_spec, ofdma);
            } else {

=> ret_no_channel = -EPROBE_DEFER; chan = NULL; } ... => return ERR_PTR(ret_no_channel); }

Is this known issue ? Or sound shouldn't fallbacks to PIO mode ?

I assume you wrote commit 6c92d5a2744e2761 ("ASoC: rsnd: don't fallback to PIO mode when -EPROBE_DEFER") to work around this?

While this got rid of the error messages, and postpones sound initialization until the audio DMAC is available, it does mean that the driver will _never_ fall back to PIO.

I.e. if CONFIG_RCAR_DMAC=n, audio will fail to probe instead of falling back to PIO.

With CONFIG_RCAR_DMAC=y:

rcar-dmac e6700000.dma-controller: ignoring dependency for device, assuming no driver rcar-dmac e7300000.dma-controller: ignoring dependency for device, assuming no driver rcar-dmac e7310000.dma-controller: ignoring dependency for device, assuming no driver rcar-dmac ec700000.dma-controller: ignoring dependency for device, assuming no driver rcar-dmac ec720000.dma-controller: ignoring dependency for device, assuming no driver

So it seems the audio DMAC is deferred a second time, before the iommu driver probed.

subsys_initcall(ipmmu_init); calls platform_driver_register module_platform_driver(rcar_dmac_driver);

Gr{oetje,eeting}s,

Geert