[ujfalusi]

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.

To solve the deadlock, drop the jdet_mutex, use the jack_detect_work to do
the jack removal handling, move the dapm lock up one level to protect the
most of the rt5682_jack_detect_handler(), but not the jack reporting as it
might trigger a DAPM sequence.
The rt5682_headset_detect() can be changed to static as well.

Fixes: 8deb34a ("ASoC: rt5682: fix the wrong jack type detected")
Signed-off-by: Peter Ujfalusi peter.ujfalusi@linux.intel.com

[marc-hb]

Still a suspend/resume timeout in https://sof-ci.01.org/linuxpr/PR3392/build7053/devicetest/?model=CML_RVP_SDW&testcase=check-suspend-resume-5 :-(

[ranj063]

Still a suspend/resume timeout in https://sof-ci.01.org/linuxpr/PR3392/build7053/devicetest/?model=CML_RVP_SDW&testcase=check-suspend-resume-5 :-(

thats unrelated. the fix here is for the RT5682 and the CML helios actually passed whereas it almost always failed without this

[ujfalusi]

Still a suspend/resume timeout in https://sof-ci.01.org/linuxpr/PR3392/build7053/devicetest/?model=CML_RVP_SDW&testcase=check-suspend-resume-5 :-(

I think the CML_RVP_SDW is not using rt5682 codec, this PR should not have any effect on it as the patch only touches the rt5682 codec driver and by the results it does fixes the issue.
Side note: the revert of the offender also helped to resolve the CI failure: #3390

[ujfalusi]

I will send this patch upstream tomorrow.

[plbossart]

@oder-chiou @shumingfan it seems like a similar fix is needed for rt5682s, the same 'jdet_mutex' is used, and we should check if the same doesn't happen with other codecs. I've noticed the programming flows are similar, so if we have an issue with rt5682 we should double-check if other codec drivers don't have the same problem.

[shumingfan]

@oder-chiou @shumingfan it seems like a similar fix is needed for rt5682s, the same 'jdet_mutex' is used, and we should check if the same doesn't happen with other codecs. I've noticed the programming flows are similar, so if we have an issue with rt5682 we should double-check if other codec drivers don't have the same problem.

@ujfalusi @plbossart Thanks for the fix.
I checked the rt5682s and it shouldn't have the same problem for now. Because the rt5682s_headset_detect function doesn't have the snd_soc_dapm_mutex_lock/snd_soc_dapm_mutex_unlock. However, we will check the test result on the Chromebook devices. After that, I would like to use a similar fix for rt5682s.

[RanderWang]

!