On 2022-06-15 6:25 PM, Pierre-Louis Bossart wrote:
Jacks are often initialized during dai_link initialization which is completely out of platform_device area. This report made me think further - if we assign jack in dai_link->init(), we should be able to drop it in dai_link->exit().
Not exactly! ->init() is done once card components are already accounted for (available for use) but snd_soc_link_exit() is called during snd_soc_remove_pcm_runtime() when card components are available no longer - soc_remove_link_components().
TLDR: teardown path is not symmetric with its counterpart, perhaps a problem yet to be addressed. I'll see if moving the jack-NULLing to codec's DAI ->remove() won't be a better temporary (?) solution than reverting to platform_device->remove() usage.
It's a problem that impacted other platforms, see e.g.
static void kabylake_rt5660_codec_exit(struct snd_soc_pcm_runtime *rtd) { struct kbl_codec_private *ctx = snd_soc_card_get_drvdata(rtd->card);
/* * The .exit() can be reached without going through the .init() * so explicitly test if the gpiod is valid */ if (!IS_ERR_OR_NULL(ctx->gpio_lo_mute)) gpiod_put(ctx->gpio_lo_mute); }
I vaguely recall hitting this myself when working with codec properties. It's worthy of a comment in the ASoC header to make sure this is better known/shared.
I see in other drivers that the use of component_set_jack() is symmetrical between .init and .exit, so far we haven't seen any issues with sof_rt5682.c and others.
I'll send a separate mail where we can discuss the teardown path. Don't believe the problem can be ignored. Even for the bdw_rt286.c usage of link->exit() generates:
rt286 i2c-INT343A:00: ASoC: DAPM unknown pin LDO1
the following is the cause:
soc_remove_component() calls both component->remove() and snd_soc_dapm_free() for the component (in that order) so when link->exit() finally gets executes DAPM widgets are no longer there.
Regards, Czarek