Hi Jerome,
On 17.02.2020 14:18, Jerome Brunet wrote:
On Mon 17 Feb 2020 at 13:13, Marek Szyprowski m.szyprowski@samsung.com wrote:
On 14.02.2020 21:56, Mark Brown wrote:
The patch
ASoC: core: ensure component names are uniquehas been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.gitAll being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
From b2354e4009a773c00054b964d937e1b81cb92078 Mon Sep 17 00:00:00 2001 From: Jerome Brunet jbrunet@baylibre.com Date: Fri, 14 Feb 2020 14:47:04 +0100 Subject: [PATCH] ASoC: core: ensure component names are unique
Make sure each ASoC component is registered with a unique name. The component is derived from the device name. If a device registers more than one component, the component names will be the same.
This usually brings up a warning about the debugfs directory creation of the component since directory already exists.
In such case, start numbering the component of the device so the names don't collide anymore.
Signed-off-by: Jerome Brunet jbrunet@baylibre.com Link: https://lore.kernel.org/r/20200214134704.342501-1-jbrunet@baylibre.com Signed-off-by: Mark Brown broonie@kernel.org
This patch landed in today's linux-next and I've noticed that it breaks registration of VC4 DRM driver on Raspberry Pi3 boards (I've compiled kernel from bcm2835_defconfig):
I think I have an idea about what is going on. (good catch in the defer BTW)
- Funny to see that the vc4-hdmi already registers several (3) ASoC
components. It must have had warning about the debugfs entry before this patch.
Okay, right, before this patch there is a warning from debugfs I've missed (debugfs was not enabled in bcm2835_defconfig):
raspberrypi-firmware soc:firmware: Attached to firmware from 2019-07-09 14:40 raspberrypi-clk raspberrypi-clk: CPU frequency range: min 600000000, max 1200000000 debugfs: Directory '3f902000.hdmi' with parent 'vc4-hdmi' already present! vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops) vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops) vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops) vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops) vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops) vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops) vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops) vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops)
- Let say that vc4 hdmi driver defers after the registration of the 2nd
component (/drivers/gpu/drm/vc4/vc4-hdmi.c:1082). The devm callback of the 2nd component will run first and call snd_soc_unregister_component(). The catch is that this function unregisters all the components registered by the linux device so far.
- Then the devm callback of the dma_engine will run
snd_dmaengine_pcm_unregister() (sound/soc/soc-generic-dmaengine-pcm.c:466) and the lookup will not find the component dmaengine component since it is already unregistered. The function bails out and dmaengine_pcm_release_chan() is not run.
- Next time the hdmi driver tries to probe, the it will fail to
allocate the DMA channel because the sysfs entry already exists.
I would suspect that any driver doing:
- devm_snd_dmaengine_pcm_register()
- devm_snd_soc_register_component()
could be exposed to this issue, even before this patch. I don't really get is triggering the issue in this change.
Maybe it would be better if the devm callback of devm_snd_soc_register_component() unregistered only the related component.
...
Best regards