On Tue, 27 Dec 2022, Alexey Lukyachuk <skif@xxxxxxxxxxx> wrote: > On Tue, 27 Dec 2022 11:39:25 -0500 > Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> 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@xxxxxxxxxxxxxxx>: "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 -- Jani Nikula, Intel Open Source Graphics Center