Repository navigation
Conversation
ujfalusi
force-pushed
the
peter/sof/pr/rt5682_locking_fix_01
branch
2 times, most recently
from
January 24, 2022 10:32
7aa43e9 to
18c0903
Compare
This reverts commit 8deb34a. On resume from suspend the following chain of events can happen: A rt5682_resume() -> mod_delayed_work() for jack_detect_work B DAPM sequence starts ( DAPM is locked now) A1. rt5682_jack_detect_handler() scheduled - Takes both jdet_mutex and calibrate_mutex - Calls in to rt5682_headset_detect() which tries to take DAPM lock, it starts to wait for it as B path took it already. B1. DAPM sequence reaches the "HP Amp", rt5682_hp_event() tries to take the jdet_mutex, but it is locked in A1, so it waits. Deadlock. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
This was referenced Jan 24, 2022
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On resume from suspend the following chain of events can happen:
A rt5682_resume() -> mod_delayed_work() for jack_detect_work
B DAPM sequence starts ( DAPM is locked now)
A1. rt5682_jack_detect_handler() scheduled
starts to wait for it as B path took it already.
B1. DAPM sequence reaches the "HP Amp", rt5682_hp_event() tries to take
the jdet_mutex, but it is locked in A1, so it waits.
Deadlock.
In order to solve the lock while keeping similar level of protection we
need to drop the jdet_mutex and the jd_check_work altogether and widen the
DAPM lock to rt5682_jack_detect_handler().
The jd_check_work was used to check for jack removal as presumably the
codec is not generating interrupt for that event.
We can do the same thing with the jack_detect_work and report the jack only
if it is changed.
Fixes: 8deb34a ("ASoC: rt5682: fix the wrong jack type detected")
Signed-off-by: Peter Ujfalusi peter.ujfalusi@linux.intel.com