public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Alexey Lukyachuk <skif@skif-web.ru>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: tvrtko.ursulin@linux.intel.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: dell wyse 3040 shutdown fix
Date: Wed, 28 Dec 2022 10:50:15 +0200	[thread overview]
Message-ID: <875ydv29q0.fsf@intel.com> (raw)
In-Reply-To: <20221227204003.6b0abe65@alexey-Swift-SF314-42>

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


-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-12-28  8:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-25 18:44 [PATCH] drm/i915/: dell wyse 3040 shutdown fix Alexey Lukyanchuk
2022-12-25 18:55 ` [PATCH v2] drm/i915: " Alexey Lukyanchuk
2022-12-27 16:39   ` [Intel-gfx] " Rodrigo Vivi
2022-12-27 17:40     ` Alexey Lukyachuk
2022-12-28  8:50       ` Jani Nikula [this message]
2023-01-02 13:56       ` Alexey Lukyachuk
2023-01-03 10:14         ` Jani Nikula
2023-01-03 10:24           ` Alexey Lukyachuk
2023-01-04 14:08             ` Jani Nikula
2023-01-03 12:46         ` Rodrigo Vivi
2023-01-03 13:43           ` Jani Nikula
2023-01-03 16:09           ` Alexey Lukyachuk
2023-01-03 16:18             ` Rodrigo Vivi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875ydv29q0.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=skif@skif-web.ru \
    --cc=stable@vger.kernel.org \
    --cc=tvrtko.ursulin@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox