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@suse.de
[ 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@suse.de Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Sasha Levin sashal@kernel.org
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?