Hi,
On Fri, 9 Oct 2020, Takashi Iwai wrote:
On Fri, 09 Oct 2020 16:02:27 +0200, Kai Vehmanen wrote:
- if (status && from_rt) {
list_for_each_codec(codec, &chip->bus)
- if (from_rt) {
list_for_each_codec(codec, &chip->bus) {if (codec->forced_resume && pm_runtime_suspended(hda_codec_dev(codec)))pm_request_resume(hda_codec_dev(codec));if (!codec->relaxed_resume && (status & (1 << codec->addr))) schedule_delayed_work(&codec->jackpoll_work, codec->jackpoll_interval);}Basically both pm_request_resume() and the jackpoll_work do the equivalent task, hence no need to do twice differently. Actually pm_request_resume() looks like a better choice as it's clearer about what it does, so let's replace with it.
ack. I was unsure whether the other actions in jackpoll_work would be needed in some case (when jackpoll_interval>0), but I guess if interval is non-zero, the workqueue is kicked from the codec driver, so no need to do it here. Will change.
Also, the pm_runtime_suspend() can be skipped here; the codec must have been suspended at this moment because of the pm-dependency.
Oh, true, you are right.
So, it'll be like:
if (from_rt) { list_for_each_codec(codec, &chip->bus) { if (codec->relaxed_resume) continue; if (codec->forced_resume || (status & (1 << codec->addr))) pm_request_resume(hda_codec_dev(codec)); } }
[..]
Could you check whether this still works?
Sure, not necessarily today, but I'll get back with the test results.
PS And Pierre, indeed it is sufficient to just power the codec on. Even if it then goes back to suspend, jack detection still works. And if controller never goes to suspend, then there's no problem either. I'll update the commit message for v2.
Br, Kai