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 ? Best regards --- Kuninori Morimoto