From: Mark Brown <broonie@kernel.org>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: ALSA development <alsa-devel@alsa-project.org>,
Linux Samsung SOC <linux-samsung-soc@vger.kernel.org>,
Jimmy Cheng-Yi Chiang <cychiang@google.com>,
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
Takashi Iwai <tiwai@suse.de>,
Krzysztof Kozlowski <krzk@kernel.org>,
Tzung-Bi Shih <tzungbi@google.com>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
Dylan Reid <dgreid@google.com>
Subject: Re: [alsa-devel] [PATCH v2] ASoC: max98090: save and restore SHDN when changing sensitive registers
Date: Thu, 19 Dec 2019 12:37:09 +0000 [thread overview]
Message-ID: <20191219123709.GB5047@sirena.org.uk> (raw)
In-Reply-To: <ef908cb8-875e-4339-33bd-5997b594f022@samsung.com>
[-- Attachment #1.1: Type: text/plain, Size: 1887 bytes --]
On Thu, Dec 19, 2019 at 09:03:42AM +0100, Marek Szyprowski wrote:
> On 18.12.2019 17:24, Mark Brown wrote:
> I've checked again the exact probe order and here is what happens in the
> system:
> 1. first call to odroid_audio_probe() is just after:
>
> [ 2.942428] samsung-i2s 3830000.i2s-sec: DMA channels sourced from device 3830000.i2s
> 2. That time, i2s dai and max98090 devices are already registered.
> However the snd_soc_of_get_dai_link_codecs() return -EPROBE_DEFER,
> because it cannot get the HDMI codec component.
> 3. HDMI codec is being registered when Exynos DRM initializes. This
> happens later:
> [ 3.127833] [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on
> minor 0
> 4. Then odroid_audio_probe() is called again from the deferred probe
> worker and succeeds:
> [ 3.501198] ALSA device list:
> [ 3.501300] #0: Odroid-U3
> 5. Then userspace starts:
> [ 3.603825] Run /sbin/init as init process
>
> 6. when userspace init scripts (alsactl) enumerates devices in the
> system the lockdep warning is triggered:
>
> [ 10.068990] ======================================================
> [ 10.070970] WARNING: possible circular locking dependency detected
> [ 10.077136] 5.5.0-rc2-next-20191218 #7188 Not tainted
> [ 10.082168] ------------------------------------------------------
> [ 10.088332] alsactl/1106 is trying to acquire lock:
>
> 7. then alsa utils probably tries to load the saved values for the controls, what triggers the NULL ptr dereference:
>
> [....] Setting up ALSA...[ 10.502672] 8<--- cut here ---
> [ 10.502772] Unable to handle kernel NULL pointer dereference at virtual address 000000b0
OK, so this is probably related to some of Morimoto-san's bisections.
Is there any chance you coudld do a bisect to try to isolate where
things go wrong?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2019-12-19 12:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20191128152110epcas3p2b205b4b55f6d8bfac42fcb8faaade93c@epcas3p2.samsung.com>
2019-11-28 15:19 ` [alsa-devel] [PATCH v2] ASoC: max98090: save and restore SHDN when changing sensitive registers Tzung-Bi Shih
2019-12-09 18:59 ` [alsa-devel] Applied "ASoC: max98090: save and restore SHDN when changing sensitive registers" to the asoc tree Mark Brown
2019-12-12 14:09 ` [alsa-devel] [PATCH v2] ASoC: max98090: save and restore SHDN when changing sensitive registers Marek Szyprowski
2019-12-12 16:02 ` Marek Szyprowski
2019-12-12 16:48 ` Mark Brown
2019-12-12 18:05 ` Tzung-Bi Shih
2019-12-17 14:18 ` Marek Szyprowski
2019-12-18 13:26 ` Mark Brown
2019-12-18 14:48 ` Marek Szyprowski
2019-12-18 16:24 ` Mark Brown
2019-12-19 8:03 ` Marek Szyprowski
2019-12-19 12:37 ` Mark Brown [this message]
2019-12-19 12:54 ` Marek Szyprowski
2019-12-19 13:05 ` Mark Brown
2019-12-19 13:41 ` Marek Szyprowski
2019-12-19 19:16 ` Mark Brown
2019-12-20 8:28 ` Marek Szyprowski
2019-12-20 9:05 ` Marek Szyprowski
2019-12-20 12:01 ` Mark Brown
2020-01-08 11:54 ` Marek Szyprowski
2020-01-09 21:18 ` Mark Brown
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=20191219123709.GB5047@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=cychiang@google.com \
--cc=dgreid@google.com \
--cc=krzk@kernel.org \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=s.nawrocki@samsung.com \
--cc=tiwai@suse.de \
--cc=tzungbi@google.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