Hi Morimoto-san, CC asoc, dma, iommu
On Tue, Sep 4, 2018 at 8:06 AM Kuninori Morimoto <kuninori.morimoto...@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 <r...@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 -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu