From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Jerome Brunet <jbrunet@baylibre.com>,
Mark Brown <broonie@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Pierre-Louis Bossart <pierre-louis.bossart@intel.com>,
Stephan Gerhold <stephan@gerhold.net>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Kevin Hilman <khilman@baylibre.com>,
alsa-devel@alsa-project.org, linux-amlogic@lists.infradead.org,
linux-kernel@vger.kernel.org, zhangn1985@outlook.com
Subject: Re: [PATCH] ASoC: meson: cards: deal dpcm flag change
Date: Thu, 27 Aug 2020 16:46:15 +0200 [thread overview]
Message-ID: <1b540f64-bf03-af59-756a-c4981fc43259@samsung.com> (raw)
In-Reply-To: <1jmu2g6wq0.fsf@starbuckisacylon.baylibre.com>
Hi
On 27.08.2020 15:32, Jerome Brunet wrote:
> On Thu 27 Aug 2020 at 14:43, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>> 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@baylibre.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 ?
Right, I have CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP enabled.
> 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.
Right, disabling LOCKDEP hides it. The issue is not a problem for me.
I've just added OdroidN2 to my test machines and wanted to report what I
found and help fixing it.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
prev parent reply other threads:[~2020-08-27 14:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-31 12:06 Jerome Brunet
2020-07-31 18:54 ` Mark Brown
2020-08-17 17:48 ` patchwork-bot+linux-amlogic
[not found] ` <CGME20200827124306eucas1p2c355345ca848e396f1fb06a7ef7a111e@eucas1p2.samsung.com>
2020-08-27 12:43 ` Marek Szyprowski
2020-08-27 13:32 ` Jerome Brunet
2020-08-27 14:46 ` Marek Szyprowski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1b540f64-bf03-af59-756a-c4981fc43259@samsung.com \
--to=m.szyprowski@samsung.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=jbrunet@baylibre.com \
--cc=khilman@baylibre.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lgirdwood@gmail.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pierre-louis.bossart@intel.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=stephan@gerhold.net \
--cc=zhangn1985@outlook.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®