[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1jmu2g6wq0.fsf@starbuckisacylon.baylibre.com>
Date: Thu, 27 Aug 2020 15:32:07 +0200
From: Jerome Brunet <jbrunet@...libre.com>
To: Marek Szyprowski <m.szyprowski@...sung.com>,
Mark Brown <broonie@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
Pierre-Louis Bossart <pierre-louis.bossart@...el.com>,
Stephan Gerhold <stephan@...hold.net>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
Cc: alsa-devel@...a-project.org, Kevin Hilman <khilman@...libre.com>,
linux-kernel@...r.kernel.org, zhangn1985@...look.com,
linux-amlogic@...ts.infradead.org
Subject: Re: [PATCH] ASoC: meson: cards: deal dpcm flag change
On Thu 27 Aug 2020 at 14:43, Marek Szyprowski <m.szyprowski@...sung.com> wrote:
> Hi Jerome,
>
> On 31.07.2020 14:06, Jerome Brunet wrote:
>> Commit b73287f0b074 ("ASoC: soc-pcm: dpcm: fix playback/capture checks")
>> changed the meaning of dpcm_playback/dpcm_capture and now requires the
>> CPU DAI BE to aligned with those flags.
>>
>> This broke all Amlogic cards with uni-directional backends (All gx and
>> most axg cards).
>>
>> While I'm still confused as to how this change is an improvement, those
>> cards can't remain broken forever. Hopefully, next time an API change is
>> done like that, all the users will be updated as part of the change, and
>> not left to fend for themselves.
>>
>> Fixes: b73287f0b074 ("ASoC: soc-pcm: dpcm: fix playback/capture checks")
>> Signed-off-by: Jerome Brunet <jbrunet@...libre.com>
>
> This patch landed finally in v5.9-rc1. I've noticed it causes a
> following warning on Hardkernel's Odroid N2 board
> (arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtb):
Looks like the after match of the flag change again ...
>
> meson-drm ff900000.vpu: [drm] fb0: mesondrmfb frame buffer device
> ------------[ cut here ]------------
> WARNING: CPU: 3 PID: 66 at sound/soc/soc-core.c:817
Marek, is it possible that you have CONFIG_LOCKDEP enabled in your
configuration ?
snd_soc_find_dai() is called by snd_soc_dai_link_set_capabilities().
Indeed, the client_mutex will not be help by any of the user of
snd_soc_dai_link_set_capabilities() when called.
So I believe simple card and qcom will be impacted as well.
> snd_soc_find_dai+0xe4/0xf0
> Modules linked in: dw_hdmi_i2s_audio dw_hdmi_cec meson_gxl realtek
> dwmac_generic crct10dif_ce snd_soc_meson_axg_sound_card
> snd_soc_meson_card_utils rc_odroid pwm_meson meson_ir
> snd_soc_meson_g12a_toacodec snd_soc_meson_axg_tdmout rtc_meson_vrtc
> snd_soc_meson_g12a_tohdmitx snd_soc_meson_codec_glue mdio_mux_meson_g12a
> snd_soc_meson_axg_tdmin dwmac_meson8b stmmac_platform
> reset_meson_audio_arb snd_soc_meson_axg_frddr axg_audio
> snd_soc_meson_axg_toddr sclk_div clk_phase meson_rng stmmac rng_core
> meson_dw_hdmi snd_soc_meson_axg_fifo meson_drm meson_canvas mdio_xpcs
> dw_hdmi snd_soc_meson_t9015 display_connector nvmem_meson_efuse
> snd_soc_meson_axg_tdm_interface snd_soc_meson_axg_tdm_formatter
> snd_soc_simple_amplifier
> CPU: 3 PID: 66 Comm: kworker/3:1 Not tainted 5.9.0-rc1 #1527
> Hardware name: Hardkernel ODROID-N2 (DT)
> Workqueue: events deferred_probe_work_func
> pstate: 60000005 (nZCv daif -PAN -UAO BTYPE=--)
> pc : snd_soc_find_dai+0xe4/0xf0
> lr : snd_soc_find_dai+0xe0/0xf0
> ...
> Call trace:
> snd_soc_find_dai+0xe4/0xf0
> snd_soc_dai_link_set_capabilities+0x68/0x160
> axg_card_add_link+0x188/0x5c4 [snd_soc_meson_axg_sound_card]
> meson_card_probe+0x1e0/0x960 [snd_soc_meson_card_utils]
> platform_drv_probe+0x50/0xa8
> really_probe+0x110/0x400
> driver_probe_device+0x54/0xb8
> __device_attach_driver+0x90/0xc0
> bus_for_each_drv+0x70/0xc8
> __device_attach+0xec/0x150
> device_initial_probe+0x10/0x18
> bus_probe_device+0x94/0xa0
> deferred_probe_work_func+0x70/0xa8
> process_one_work+0x2a8/0x718
> worker_thread+0x48/0x460
> kthread+0x134/0x160
> ret_from_fork+0x10/0x1c
> irq event stamp: 269690
> hardirqs last enabled at (269689): [<ffff800010f6048c>]
> _raw_spin_unlock_irqrestore+0x7c/0x98
> hardirqs last disabled at (269690): [<ffff800010025a68>]
> do_debug_exception+0x140/0x26c
> softirqs last enabled at (269318): [<ffff800010001654>]
> efi_header_end+0x654/0x6d4
> softirqs last disabled at (269313): [<ffff80001008929c>]
> irq_exit+0x16c/0x178
> ---[ end trace 56a3ea4fa00c37c8 ]---
> ...
> axg-sound-card sound: ASoC: no DMI vendor name!
>
> The warning is repeated 10 times.
That's the probe defferal mechanism causing the repeat
>
> The bisect between v5.8-rc1 and v5.9-rc1 points to the commit
> c8f7dbdbaa15 ("Merge remote-tracking branch 'asoc/for-5.8' into
> asoc-linus"), which introduced a branch with this patch.
>
> The commit with this patch is applied on the earlier kernel release
> (da3f23fde9d7 "ASoC: meson: cards: deal dpcm flag change" on top of
> v5.7-rc1) worked fine, so it looks that there is an interference with
> something merged later.
>
> If I revert this patch on top of v5.9-rc1 or current linux-next, the
> warning is gone.
... but any aml platform with uni-directional backend (not the N2, lucky
you) would be broken.
> Let me know how I can help debugging this issue.
If you have CONFIG_LOCKDEP enabled, try disabling see how it goes and
report. It is not a fix but at least you'll be unblocked.
>
> Best regards
Powered by blists - more mailing lists