Hi Morimoto-san,
CC asoc, dma, iommu
On Tue, Sep 4, 2018 at 8:06 AM Kuninori Morimoto
<kuninori.morimoto.gx@xxxxxxxxxxx> 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@xxxxxxxxxx>
> 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 -- geert@xxxxxxxxxxxxxx
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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
