On Thu, Apr 30, 2020 at 11:36:05PM +0100, Roy Spliet wrote:
(Minus "Linux kernel", that list has enough volume)
Op 24-04-2020 om 13:44 schreef Takashi Iwai:
On Fri, 24 Apr 2020 14:22:10 +0200,
Sasha Levin wrote:
From: Takashi Iwai <tiwai@xxxxxxx>
[ Upstream commit c4c8dd6ef807663e42a5f04ea77cd62029eb99fa ]
The HD-audio controller does system-suspend and resume operations by
directly calling its helpers __azx_runtime_suspend() and
__azx_runtime_resume(). However, in general, we don't have to resume
always the device fully at the system resume; typically, if a device
has been runtime-suspended, we can leave it to runtime resume.
Usually for achieving this, the driver would call
pm_runtime_force_suspend() and pm_runtime_force_resume() pairs in the
system suspend and resume ops. Unfortunately, this doesn't work for
the resume path in our case. For handling the jack detection at the
system resume, a child codec device may need the (literally) forcibly
resume even if it's been runtime-suspended, and for that, the
controller device must be also resumed even if it's been suspended.
This patch is an attempt to improve the situation. It replaces the
direct __azx_runtime_suspend()/_resume() calls with with
pm_runtime_force_suspend() and pm_runtime_force_resume() with a slight
trick as we've done for the codec side. More exactly:
- azx_has_pm_runtime() check is dropped from azx_runtime_suspend() and
azx_runtime_resume(), so that it can be properly executed from the
system-suspend/resume path
- The WAKEEN handling depends on the card's power state now; it's set
and cleared only for the runtime-suspend
- azx_resume() checks whether any codec may need the forcible resume
beforehand. If the forcible resume is required, it does temporary
PM refcount up/down for actually triggering the runtime resume.
- A new helper function, hda_codec_need_resume(), is introduced for
checking whether the codec needs a forcible runtime-resume, and the
existing code is rewritten with that.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043
Link: https://lore.kernel.org/r/20200413082034.25166-6-tiwai@xxxxxxx
Signed-off-by: Takashi Iwai <tiwai@xxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
This commit is known to cause a regression, and the fix patch is
included in today's pull request. If we apply this, better to wait
for the next batch including its fix.
These six patches, plus Takashi's fix on top of them, do not seem to
have made it to 5.6.7 or 5.6.8 in the end. Is there a plan to include
AUTOSEL stuff take a while to hit the stable trees, if you want patches
in quicker they should be tagged for stable...
them in 5.6.9?
What are the commit ids?
--
Thanks,
Sasha
