On Tue, 27 Dec 2022, Alexey Lukyachuk skif@skif-web.ru wrote:
On Tue, 27 Dec 2022 11:39:25 -0500 Rodrigo Vivi rodrigo.vivi@intel.com wrote:
On Sun, Dec 25, 2022 at 09:55:08PM +0300, Alexey Lukyanchuk wrote:
dell wyse 3040 doesn't peform poweroff properly, but instead remains in turned power on state.
okay, the motivation is explained in the commit msg..
Additional mutex_lock and intel_crtc_wait_for_next_vblank feature 6.2 kernel resolve this trouble.
but this why is not very clear... seems that by magic it was found, without explaining what race we are really protecting here.
but even worse is: what about those many random vblank waits in the code? what's the reasoning?
I would like to say, that this solution was found in drm-tip repository: link: git://anongit.freedesktop.org/drm-tip I will quotate original commit message from Ville Syrjälä ville.syrjala@linux.intel.com: "The spec tells us to do a bunch of vblank waits in the audio enable/disable sequences. Make it so." So it's just a backport of accepted patch. Which i wanna to propagate to stable versions
This is not how stable kernel backports work. Please read [1].
Does v6.2-rc1 work for you? It has all the relevant commits. Which stable kernel are you trying to backport them to?
Though I must say I find it surprising that these changes would fix a poweroff issue, and it certainly was not the goal. I'm wondering if it's just a coincidence due to timing and/or locking changes.
Have you reported an issue at fdo gitlab [2]?
BR, Jani.
[1] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html [2] https://gitlab.freedesktop.org/drm/intel/wikis/How-to-file-i915-bugs