[PATCH] Revert "drm/amd/display: more liberal vmin/vmax update for freesync"

[PATCH] Revert "drm/amd/display: more liberal vmin/vmax update for freesync"

[Aurabindo Pillai]

This reverts commit 219898d29c438d8ec34a5560fac4ea8f6b8d4f20 since it
causes regressions on certain configs. Revert until the issue can be
isolated and debugged.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4238
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c    | 16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 90889f6867aad..9f2e26336cccf 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -676,21 +676,15 @@ static void dm_crtc_high_irq(void *interrupt_params)
 	spin_lock_irqsave(&adev_to_drm(adev)->event_lock, flags);
 
 	if (acrtc->dm_irq_params.stream &&
-		acrtc->dm_irq_params.vrr_params.supported) {
-		bool replay_en = acrtc->dm_irq_params.stream->link->replay_settings.replay_feature_enabled;
-		bool psr_en = acrtc->dm_irq_params.stream->link->psr_settings.psr_feature_enabled;
-		bool fs_active_var_en = acrtc->dm_irq_params.freesync_config.state == VRR_STATE_ACTIVE_VARIABLE;
-
+	    acrtc->dm_irq_params.vrr_params.supported &&
+	    acrtc->dm_irq_params.freesync_config.state ==
+		    VRR_STATE_ACTIVE_VARIABLE) {
 		mod_freesync_handle_v_update(adev->dm.freesync_module,
 					     acrtc->dm_irq_params.stream,
 					     &acrtc->dm_irq_params.vrr_params);
 
-		/* update vmin_vmax only if freesync is enabled, or only if PSR and REPLAY are disabled */
-		if (fs_active_var_en || (!fs_active_var_en && !replay_en && !psr_en)) {
-			dc_stream_adjust_vmin_vmax(adev->dm.dc,
-					acrtc->dm_irq_params.stream,
-					&acrtc->dm_irq_params.vrr_params.adjust);
-		}
+		dc_stream_adjust_vmin_vmax(adev->dm.dc, acrtc->dm_irq_params.stream,
+					   &acrtc->dm_irq_params.vrr_params.adjust);
 	}
 
 	/*
-- 
2.49.0

Re: [PATCH] Revert "drm/amd/display: more liberal vmin/vmax update for freesync"

[Alex Deucher]

On Fri, May 30, 2025 at 4:09 PM Aurabindo Pillai
<aurabindo.pillai@amd.com> wrote:
>
> This reverts commit 219898d29c438d8ec34a5560fac4ea8f6b8d4f20 since it
> causes regressions on certain configs. Revert until the issue can be
> isolated and debugged.
>
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4238
> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
> Acked-by: Alex Deucher <alexander.deucher@amd.com>

Already included in my -fixes PR for this week:
https://lists.freedesktop.org/archives/amd-gfx/2025-May/125350.html

Alex

> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c    | 16 +++++-----------
>  1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 90889f6867aad..9f2e26336cccf 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -676,21 +676,15 @@ static void dm_crtc_high_irq(void *interrupt_params)
>         spin_lock_irqsave(&adev_to_drm(adev)->event_lock, flags);
>
>         if (acrtc->dm_irq_params.stream &&
> -               acrtc->dm_irq_params.vrr_params.supported) {
> -               bool replay_en = acrtc->dm_irq_params.stream->link->replay_settings.replay_feature_enabled;
> -               bool psr_en = acrtc->dm_irq_params.stream->link->psr_settings.psr_feature_enabled;
> -               bool fs_active_var_en = acrtc->dm_irq_params.freesync_config.state == VRR_STATE_ACTIVE_VARIABLE;
> -
> +           acrtc->dm_irq_params.vrr_params.supported &&
> +           acrtc->dm_irq_params.freesync_config.state ==
> +                   VRR_STATE_ACTIVE_VARIABLE) {
>                 mod_freesync_handle_v_update(adev->dm.freesync_module,
>                                              acrtc->dm_irq_params.stream,
>                                              &acrtc->dm_irq_params.vrr_params);
>
> -               /* update vmin_vmax only if freesync is enabled, or only if PSR and REPLAY are disabled */
> -               if (fs_active_var_en || (!fs_active_var_en && !replay_en && !psr_en)) {
> -                       dc_stream_adjust_vmin_vmax(adev->dm.dc,
> -                                       acrtc->dm_irq_params.stream,
> -                                       &acrtc->dm_irq_params.vrr_params.adjust);
> -               }
> +               dc_stream_adjust_vmin_vmax(adev->dm.dc, acrtc->dm_irq_params.stream,
> +                                          &acrtc->dm_irq_params.vrr_params.adjust);
>         }
>
>         /*
> --
> 2.49.0
>

Re: [PATCH] Revert "drm/amd/display: more liberal vmin/vmax update for freesync"

[Greg KH]

On Fri, May 30, 2025 at 04:09:18PM -0400, Aurabindo Pillai wrote:
> This reverts commit 219898d29c438d8ec34a5560fac4ea8f6b8d4f20 since it
> causes regressions on certain configs. Revert until the issue can be
> isolated and debugged.
> 
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4238
> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
> Acked-by: Alex Deucher <alexander.deucher@amd.com>
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c    | 16 +++++-----------
>  1 file changed, 5 insertions(+), 11 deletions(-)
> 

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

Re: [PATCH] Revert "drm/amd/display: more liberal vmin/vmax update for freesync"

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

Hello Alex,

On Fri, May 30, 2025 at 04:14:09PM -0400, Alex Deucher wrote:
> On Fri, May 30, 2025 at 4:09 PM Aurabindo Pillai
> <aurabindo.pillai@amd.com> wrote:
> >
> > This reverts commit 219898d29c438d8ec34a5560fac4ea8f6b8d4f20 since it
> > causes regressions on certain configs. Revert until the issue can be
> > isolated and debugged.
> >
> > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4238
> > Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
> > Acked-by: Alex Deucher <alexander.deucher@amd.com>
> 
> Already included in my -fixes PR for this week:
> https://lists.freedesktop.org/archives/amd-gfx/2025-May/125350.html

Note the way this was done isn't maximally friendly to our stable
maintainers though.

The commit in your tree (1b824eef269db44d068bbc0de74c94a8e8f9ce02) is a
tad better than the patch that Aurabindo sent as it has:

	This reverts commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d ...

which at least is a known commit and has Cc: stable.

However this is still a bit confusing as commit cfb2d41831ee has no Cc:
stable, but a duplicate in mainline: f1c6be3999d2 that has Cc: stable.

So f1c6be3999d2 was backported to 6.14.7 (commit
4ec308a4104bc71a431c75cc9babf49303645617), 6.12.29 (commit
468034a06a6e8043c5b50f9cd0cac730a6e497b5) and 6.6.91 (commit
c8a91debb020298c74bba0b9b6ed720fa98dc4a9). But it might not be obvious
that 1b824eef269db44d068bbc0de74c94a8e8f9ce02 needs backporting to trees
that don't contain cfb2d41831ee (or a backport of it).

Please keep an eye on that change that it gets properly backported.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] Revert "drm/amd/display: more liberal vmin/vmax update for freesync"

[Alex Deucher]

On Wed, Jun 4, 2025 at 5:40 AM Uwe Kleine-König
<u.kleine-koenig@baylibre.com> wrote:
>
> Hello Alex,
>
> On Fri, May 30, 2025 at 04:14:09PM -0400, Alex Deucher wrote:
> > On Fri, May 30, 2025 at 4:09 PM Aurabindo Pillai
> > <aurabindo.pillai@amd.com> wrote:
> > >
> > > This reverts commit 219898d29c438d8ec34a5560fac4ea8f6b8d4f20 since it
> > > causes regressions on certain configs. Revert until the issue can be
> > > isolated and debugged.
> > >
> > > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4238
> > > Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
> > > Acked-by: Alex Deucher <alexander.deucher@amd.com>
> >
> > Already included in my -fixes PR for this week:
> > https://lists.freedesktop.org/archives/amd-gfx/2025-May/125350.html
>
> Note the way this was done isn't maximally friendly to our stable
> maintainers though.
>
> The commit in your tree (1b824eef269db44d068bbc0de74c94a8e8f9ce02) is a
> tad better than the patch that Aurabindo sent as it has:
>
>         This reverts commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d ...
>
> which at least is a known commit and has Cc: stable.
>
> However this is still a bit confusing as commit cfb2d41831ee has no Cc:
> stable, but a duplicate in mainline: f1c6be3999d2 that has Cc: stable.
>
> So f1c6be3999d2 was backported to 6.14.7 (commit
> 4ec308a4104bc71a431c75cc9babf49303645617), 6.12.29 (commit
> 468034a06a6e8043c5b50f9cd0cac730a6e497b5) and 6.6.91 (commit
> c8a91debb020298c74bba0b9b6ed720fa98dc4a9). But it might not be obvious
> that 1b824eef269db44d068bbc0de74c94a8e8f9ce02 needs backporting to trees
> that don't contain cfb2d41831ee (or a backport of it).
>
> Please keep an eye on that change that it gets properly backported.

DRM patches land in -next first since that is where the developers
work and then bug fixes get cherry-picked to -fixes.  When a patch is
cherry-picked to -fixes, we use cherry-pick -x to keep the reference
to the original commit and then add stable CC's as needed.  See this
thread for background:
https://lore.kernel.org/dri-devel/871px5iwbx.fsf@intel.com/T/#t

Alex

>
> Best regards
> Uwe

Re: [PATCH] Revert "drm/amd/display: more liberal vmin/vmax update for freesync"

[Greg KH]

On Wed, Jun 04, 2025 at 09:15:14AM -0400, Alex Deucher wrote:
> On Wed, Jun 4, 2025 at 5:40 AM Uwe Kleine-König
> <u.kleine-koenig@baylibre.com> wrote:
> >
> > Hello Alex,
> >
> > On Fri, May 30, 2025 at 04:14:09PM -0400, Alex Deucher wrote:
> > > On Fri, May 30, 2025 at 4:09 PM Aurabindo Pillai
> > > <aurabindo.pillai@amd.com> wrote:
> > > >
> > > > This reverts commit 219898d29c438d8ec34a5560fac4ea8f6b8d4f20 since it
> > > > causes regressions on certain configs. Revert until the issue can be
> > > > isolated and debugged.
> > > >
> > > > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4238
> > > > Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
> > > > Acked-by: Alex Deucher <alexander.deucher@amd.com>
> > >
> > > Already included in my -fixes PR for this week:
> > > https://lists.freedesktop.org/archives/amd-gfx/2025-May/125350.html
> >
> > Note the way this was done isn't maximally friendly to our stable
> > maintainers though.
> >
> > The commit in your tree (1b824eef269db44d068bbc0de74c94a8e8f9ce02) is a
> > tad better than the patch that Aurabindo sent as it has:
> >
> >         This reverts commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d ...
> >
> > which at least is a known commit and has Cc: stable.
> >
> > However this is still a bit confusing as commit cfb2d41831ee has no Cc:
> > stable, but a duplicate in mainline: f1c6be3999d2 that has Cc: stable.
> >
> > So f1c6be3999d2 was backported to 6.14.7 (commit
> > 4ec308a4104bc71a431c75cc9babf49303645617), 6.12.29 (commit
> > 468034a06a6e8043c5b50f9cd0cac730a6e497b5) and 6.6.91 (commit
> > c8a91debb020298c74bba0b9b6ed720fa98dc4a9). But it might not be obvious
> > that 1b824eef269db44d068bbc0de74c94a8e8f9ce02 needs backporting to trees
> > that don't contain cfb2d41831ee (or a backport of it).
> >
> > Please keep an eye on that change that it gets properly backported.
> 
> DRM patches land in -next first since that is where the developers
> work and then bug fixes get cherry-picked to -fixes.  When a patch is
> cherry-picked to -fixes, we use cherry-pick -x to keep the reference
> to the original commit and then add stable CC's as needed.  See this
> thread for background:
> https://lore.kernel.org/dri-devel/871px5iwbx.fsf@intel.com/T/#t

And that thread shows how the confusion between git ids that are
reverted and committed to the tree cause reverts to get missed with our
automatic tools, so you HAVE to explicitly tag them as cc: stable, which
is not always done :(

thanks,

greg k-h

Re: [PATCH] Revert "drm/amd/display: more liberal vmin/vmax update for freesync"

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]

Hello Alex,

On Wed, Jun 04, 2025 at 03:29:58PM +0200, Greg KH wrote:
> On Wed, Jun 04, 2025 at 09:15:14AM -0400, Alex Deucher wrote:
> > On Wed, Jun 4, 2025 at 5:40 AM Uwe Kleine-König
> > <u.kleine-koenig@baylibre.com> wrote:
> > > On Fri, May 30, 2025 at 04:14:09PM -0400, Alex Deucher wrote:
> > > > Already included in my -fixes PR for this week:
> > > > https://lists.freedesktop.org/archives/amd-gfx/2025-May/125350.html
> > >
> > > Note the way this was done isn't maximally friendly to our stable
> > > maintainers though.
> > >
> > > The commit in your tree (1b824eef269db44d068bbc0de74c94a8e8f9ce02) is a
> > > tad better than the patch that Aurabindo sent as it has:
> > >
> > >         This reverts commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d ...
> > >
> > > which at least is a known commit and has Cc: stable.
> > >
> > > However this is still a bit confusing as commit cfb2d41831ee has no Cc:
> > > stable, but a duplicate in mainline: f1c6be3999d2 that has Cc: stable.
> > >
> > > So f1c6be3999d2 was backported to 6.14.7 (commit
> > > 4ec308a4104bc71a431c75cc9babf49303645617), 6.12.29 (commit
> > > 468034a06a6e8043c5b50f9cd0cac730a6e497b5) and 6.6.91 (commit
> > > c8a91debb020298c74bba0b9b6ed720fa98dc4a9). But it might not be obvious
> > > that 1b824eef269db44d068bbc0de74c94a8e8f9ce02 needs backporting to trees
> > > that don't contain cfb2d41831ee (or a backport of it).
> > >
> > > Please keep an eye on that change that it gets properly backported.

I'm not sure if my mail was already enough to ensure that
1b824eef269db44d068bbc0de74c94a8e8f9ce02 will be backported to stable,
so that request still stands.

> > DRM patches land in -next first since that is where the developers
> > work and then bug fixes get cherry-picked to -fixes.  When a patch is
> > cherry-picked to -fixes, we use cherry-pick -x to keep the reference
> > to the original commit and then add stable CC's as needed.  See this
> > thread for background:
> > https://lore.kernel.org/dri-devel/871px5iwbx.fsf@intel.com/T/#t

Yeah I thought so. The problem isn't per se that there are duplicates,
but that they are not handled with the needed care. I don't know about
Greg's tooling, but my confusion would have been greatly reduced if you
reverted f1c6be3999d2 instead of cfb2d41831ee. That is the older commit
(with POV = mainline) and the one that has the relevant information (Cc:
stable and the link to cfb2d41831ee).

Getting this wrong is just a big waste of time and patience (or if the
backport is missed results in systems breaking for problems that are
already known and fixed).

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] Revert "drm/amd/display: more liberal vmin/vmax update for freesync"

[Alex Deucher]

On Wed, Jun 4, 2025 at 10:55 AM Uwe Kleine-König
<u.kleine-koenig@baylibre.com> wrote:
>
> Hello Alex,
>
> On Wed, Jun 04, 2025 at 03:29:58PM +0200, Greg KH wrote:
> > On Wed, Jun 04, 2025 at 09:15:14AM -0400, Alex Deucher wrote:
> > > On Wed, Jun 4, 2025 at 5:40 AM Uwe Kleine-König
> > > <u.kleine-koenig@baylibre.com> wrote:
> > > > On Fri, May 30, 2025 at 04:14:09PM -0400, Alex Deucher wrote:
> > > > > Already included in my -fixes PR for this week:
> > > > > https://lists.freedesktop.org/archives/amd-gfx/2025-May/125350.html
> > > >
> > > > Note the way this was done isn't maximally friendly to our stable
> > > > maintainers though.
> > > >
> > > > The commit in your tree (1b824eef269db44d068bbc0de74c94a8e8f9ce02) is a
> > > > tad better than the patch that Aurabindo sent as it has:
> > > >
> > > >         This reverts commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d ...
> > > >
> > > > which at least is a known commit and has Cc: stable.
> > > >
> > > > However this is still a bit confusing as commit cfb2d41831ee has no Cc:
> > > > stable, but a duplicate in mainline: f1c6be3999d2 that has Cc: stable.
> > > >
> > > > So f1c6be3999d2 was backported to 6.14.7 (commit
> > > > 4ec308a4104bc71a431c75cc9babf49303645617), 6.12.29 (commit
> > > > 468034a06a6e8043c5b50f9cd0cac730a6e497b5) and 6.6.91 (commit
> > > > c8a91debb020298c74bba0b9b6ed720fa98dc4a9). But it might not be obvious
> > > > that 1b824eef269db44d068bbc0de74c94a8e8f9ce02 needs backporting to trees
> > > > that don't contain cfb2d41831ee (or a backport of it).
> > > >
> > > > Please keep an eye on that change that it gets properly backported.
>
> I'm not sure if my mail was already enough to ensure that
> 1b824eef269db44d068bbc0de74c94a8e8f9ce02 will be backported to stable,
> so that request still stands.
>
> > > DRM patches land in -next first since that is where the developers
> > > work and then bug fixes get cherry-picked to -fixes.  When a patch is
> > > cherry-picked to -fixes, we use cherry-pick -x to keep the reference
> > > to the original commit and then add stable CC's as needed.  See this
> > > thread for background:
> > > https://lore.kernel.org/dri-devel/871px5iwbx.fsf@intel.com/T/#t
>
> Yeah I thought so. The problem isn't per se that there are duplicates,
> but that they are not handled with the needed care. I don't know about
> Greg's tooling, but my confusion would have been greatly reduced if you
> reverted f1c6be3999d2 instead of cfb2d41831ee. That is the older commit
> (with POV = mainline) and the one that has the relevant information (Cc:
> stable and the link to cfb2d41831ee).

The revert cc'd stable so it should go to stable.  You can check the
cherry-picked commits to see what patches they were cherry-picked from
to see if you need to apply them to stable kernels.

>
> Getting this wrong is just a big waste of time and patience (or if the
> backport is missed results in systems breaking for problems that are
> already known and fixed).

Tons of patches end up getting cherry-picked to stable without anyone
even asking for them via Sasha's scripts.  Won't this cause the same
problem?

Alex

Re: [PATCH] Revert "drm/amd/display: more liberal vmin/vmax update for freesync"

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 5029 bytes --]

On Wed, Jun 04, 2025 at 11:09:15AM -0400, Alex Deucher wrote:
> On Wed, Jun 4, 2025 at 10:55 AM Uwe Kleine-König
> <u.kleine-koenig@baylibre.com> wrote:
> >
> > Hello Alex,
> >
> > On Wed, Jun 04, 2025 at 03:29:58PM +0200, Greg KH wrote:
> > > On Wed, Jun 04, 2025 at 09:15:14AM -0400, Alex Deucher wrote:
> > > > On Wed, Jun 4, 2025 at 5:40 AM Uwe Kleine-König
> > > > <u.kleine-koenig@baylibre.com> wrote:
> > > > > On Fri, May 30, 2025 at 04:14:09PM -0400, Alex Deucher wrote:
> > > > > > Already included in my -fixes PR for this week:
> > > > > > https://lists.freedesktop.org/archives/amd-gfx/2025-May/125350.html
> > > > >
> > > > > Note the way this was done isn't maximally friendly to our stable
> > > > > maintainers though.
> > > > >
> > > > > The commit in your tree (1b824eef269db44d068bbc0de74c94a8e8f9ce02) is a
> > > > > tad better than the patch that Aurabindo sent as it has:
> > > > >
> > > > >         This reverts commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d ...
> > > > >
> > > > > which at least is a known commit and has Cc: stable.
> > > > >
> > > > > However this is still a bit confusing as commit cfb2d41831ee has no Cc:
> > > > > stable, but a duplicate in mainline: f1c6be3999d2 that has Cc: stable.
> > > > >
> > > > > So f1c6be3999d2 was backported to 6.14.7 (commit
> > > > > 4ec308a4104bc71a431c75cc9babf49303645617), 6.12.29 (commit
> > > > > 468034a06a6e8043c5b50f9cd0cac730a6e497b5) and 6.6.91 (commit
> > > > > c8a91debb020298c74bba0b9b6ed720fa98dc4a9). But it might not be obvious
> > > > > that 1b824eef269db44d068bbc0de74c94a8e8f9ce02 needs backporting to trees
> > > > > that don't contain cfb2d41831ee (or a backport of it).
> > > > >
> > > > > Please keep an eye on that change that it gets properly backported.
> >
> > I'm not sure if my mail was already enough to ensure that
> > 1b824eef269db44d068bbc0de74c94a8e8f9ce02 will be backported to stable,
> > so that request still stands.
> >
> > > > DRM patches land in -next first since that is where the developers
> > > > work and then bug fixes get cherry-picked to -fixes.  When a patch is
> > > > cherry-picked to -fixes, we use cherry-pick -x to keep the reference
> > > > to the original commit and then add stable CC's as needed.  See this
> > > > thread for background:
> > > > https://lore.kernel.org/dri-devel/871px5iwbx.fsf@intel.com/T/#t
> >
> > Yeah I thought so. The problem isn't per se that there are duplicates,
> > but that they are not handled with the needed care. I don't know about
> > Greg's tooling, but my confusion would have been greatly reduced if you
> > reverted f1c6be3999d2 instead of cfb2d41831ee. That is the older commit
> > (with POV = mainline) and the one that has the relevant information (Cc:
> > stable and the link to cfb2d41831ee).
> 
> The revert cc'd stable so it should go to stable.  You can check the
> cherry-picked commits to see what patches they were cherry-picked from
> to see if you need to apply them to stable kernels.

Yes, and I'd expect that the scripts used by stable maintainers looking
at 1b824eef269d will apply that to all stable branches that contain
cfb2d41831ee or a backport of it.
Given that that cfb2d41831ee wasn't backported to any stable kernel and
the commit itself will only be in 6.16-rc1 the set of kernels to
backport the revert to, will be the empty set.

(In git commands:

	$ git log --oneline --source stable/linux-{5.{4,10,15},6.{6,12,14,15}}.y ^1b824eef269db44d068bbc0de74c94a8e8f9ce02 --grep="commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d upstream"
	<void>
	
If however you look for cfb2d41831ee's twin, there is:

	$ git log --oneline --source stable/linux-{5.{4,10,15},6.{6,12,14,15}}.y ^1b824eef269db44d068bbc0de74c94a8e8f9ce02 --grep="commit f1c6be3999d2be2673a51a9be0caf9348e254e52 upstream"
	4ec308a4104b    stable/linux-6.14.y drm/amd/display: more liberal vmin/vmax update for freesync
	468034a06a6e    stable/linux-6.12.y drm/amd/display: more liberal vmin/vmax update for freesync
	c8a91debb020    stable/linux-6.6.y drm/amd/display: more liberal vmin/vmax update for freesync

Having said that, I don't know how the stable scripts work, *maybe*
having mentioned cfb2d41831ee in f1c6be3999d2 is indeed good enough.)

So if you had reverted f1c6be3999d2 instead of cfb2d41831ee I
wouldn't have wailed and I guess Greg would be moderately happy, too.

> > Getting this wrong is just a big waste of time and patience (or if the
> > backport is missed results in systems breaking for problems that are
> > already known and fixed).
> 
> Tons of patches end up getting cherry-picked to stable without anyone
> even asking for them via Sasha's scripts.  Won't this cause the same
> problem?

No, the problem only arises if a patch is in mainline twice and one
variant is backported to stable and later the other one is reverted (or
otherwise fixed). Patches that get backported without Cc: stable are not
a problem.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] Revert "drm/amd/display: more liberal vmin/vmax update for freesync"

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 6360 bytes --]

Hello,

On Thu, Jun 05, 2025 at 07:44:19AM +0200, Uwe Kleine-König wrote:
> On Wed, Jun 04, 2025 at 11:09:15AM -0400, Alex Deucher wrote:
> > On Wed, Jun 4, 2025 at 10:55 AM Uwe Kleine-König
> > <u.kleine-koenig@baylibre.com> wrote:
> > >
> > > Hello Alex,
> > >
> > > On Wed, Jun 04, 2025 at 03:29:58PM +0200, Greg KH wrote:
> > > > On Wed, Jun 04, 2025 at 09:15:14AM -0400, Alex Deucher wrote:
> > > > > On Wed, Jun 4, 2025 at 5:40 AM Uwe Kleine-König
> > > > > <u.kleine-koenig@baylibre.com> wrote:
> > > > > > On Fri, May 30, 2025 at 04:14:09PM -0400, Alex Deucher wrote:
> > > > > > > Already included in my -fixes PR for this week:
> > > > > > > https://lists.freedesktop.org/archives/amd-gfx/2025-May/125350.html
> > > > > >
> > > > > > Note the way this was done isn't maximally friendly to our stable
> > > > > > maintainers though.
> > > > > >
> > > > > > The commit in your tree (1b824eef269db44d068bbc0de74c94a8e8f9ce02) is a
> > > > > > tad better than the patch that Aurabindo sent as it has:
> > > > > >
> > > > > >         This reverts commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d ...
> > > > > >
> > > > > > which at least is a known commit and has Cc: stable.
> > > > > >
> > > > > > However this is still a bit confusing as commit cfb2d41831ee has no Cc:
> > > > > > stable, but a duplicate in mainline: f1c6be3999d2 that has Cc: stable.
> > > > > >
> > > > > > So f1c6be3999d2 was backported to 6.14.7 (commit
> > > > > > 4ec308a4104bc71a431c75cc9babf49303645617), 6.12.29 (commit
> > > > > > 468034a06a6e8043c5b50f9cd0cac730a6e497b5) and 6.6.91 (commit
> > > > > > c8a91debb020298c74bba0b9b6ed720fa98dc4a9). But it might not be obvious
> > > > > > that 1b824eef269db44d068bbc0de74c94a8e8f9ce02 needs backporting to trees
> > > > > > that don't contain cfb2d41831ee (or a backport of it).
> > > > > >
> > > > > > Please keep an eye on that change that it gets properly backported.
> > >
> > > I'm not sure if my mail was already enough to ensure that
> > > 1b824eef269db44d068bbc0de74c94a8e8f9ce02 will be backported to stable,
> > > so that request still stands.
> > >
> > > > > DRM patches land in -next first since that is where the developers
> > > > > work and then bug fixes get cherry-picked to -fixes.  When a patch is
> > > > > cherry-picked to -fixes, we use cherry-pick -x to keep the reference
> > > > > to the original commit and then add stable CC's as needed.  See this
> > > > > thread for background:
> > > > > https://lore.kernel.org/dri-devel/871px5iwbx.fsf@intel.com/T/#t
> > >
> > > Yeah I thought so. The problem isn't per se that there are duplicates,
> > > but that they are not handled with the needed care. I don't know about
> > > Greg's tooling, but my confusion would have been greatly reduced if you
> > > reverted f1c6be3999d2 instead of cfb2d41831ee. That is the older commit
> > > (with POV = mainline) and the one that has the relevant information (Cc:
> > > stable and the link to cfb2d41831ee).
> > 
> > The revert cc'd stable so it should go to stable.  You can check the
> > cherry-picked commits to see what patches they were cherry-picked from
> > to see if you need to apply them to stable kernels.
> 
> Yes, and I'd expect that the scripts used by stable maintainers looking
> at 1b824eef269d will apply that to all stable branches that contain
> cfb2d41831ee or a backport of it.
> Given that that cfb2d41831ee wasn't backported to any stable kernel and
> the commit itself will only be in 6.16-rc1 the set of kernels to
> backport the revert to, will be the empty set.
> 
> (In git commands:
> 
> 	$ git log --oneline --source stable/linux-{5.{4,10,15},6.{6,12,14,15}}.y ^1b824eef269db44d068bbc0de74c94a8e8f9ce02 --grep="commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d upstream"
> 	<void>
> 	
> If however you look for cfb2d41831ee's twin, there is:
> 
> 	$ git log --oneline --source stable/linux-{5.{4,10,15},6.{6,12,14,15}}.y ^1b824eef269db44d068bbc0de74c94a8e8f9ce02 --grep="commit f1c6be3999d2be2673a51a9be0caf9348e254e52 upstream"
> 	4ec308a4104b    stable/linux-6.14.y drm/amd/display: more liberal vmin/vmax update for freesync
> 	468034a06a6e    stable/linux-6.12.y drm/amd/display: more liberal vmin/vmax update for freesync
> 	c8a91debb020    stable/linux-6.6.y drm/amd/display: more liberal vmin/vmax update for freesync

TL;DR; These backports are cared for, this thread can be considered
done.

Update to the situation:

The patch to be reverted wasn't added to further stable branches since
last time we looked:
	
	$ git log --oneline --source stable/linux-{5.{4,10,15},6.{6,12,14,15}}.y ^1b824eef269db44d068bbc0de74c94a8e8f9ce02 --grep="commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d upstream"
	$ git log --oneline --source stable/linux-{5.{4,10,15},6.{6,12,14,15}}.y ^1b824eef269db44d068bbc0de74c94a8e8f9ce02 --grep="commit f1c6be3999d2be2673a51a9be0caf9348e254e52 upstream"
	4ec308a4104b    stable/linux-6.14.y drm/amd/display: more liberal vmin/vmax update for freesync
	468034a06a6e    stable/linux-6.12.y drm/amd/display: more liberal vmin/vmax update for freesync
	c8a91debb020    stable/linux-6.6.y drm/amd/display: more liberal vmin/vmax update for freesync

So 6.6.y, 6.12.y and 6.14.y need a fix, as do all releases that contain
f1c6be3999d2be2673a51a9be0caf9348e254e52 or
cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d but not the revert
1b824eef269db44d068bbc0de74c94a8e8f9ce02. That would be v6.15.

The revert was backported to the following branches:

	$ git log --oneline --source stable/linux-6.{6,12,14,15}.y ^1b824eef269db44d068bbc0de74c94a8e8f9ce02 --grep="commit 1b824eef269db44d068bbc0de74c94a8e8f9ce02 upstream"
	e9019e2214fa    stable/linux-6.6.y Revert "drm/amd/display: more liberal vmin/vmax update for freesync"
	c1c52720bb0f    stable/linux-6.15.y Revert "drm/amd/display: more liberal vmin/vmax update for freesync"
	dc86041f8d31    stable/linux-6.14.y Revert "drm/amd/display: more liberal vmin/vmax update for freesync"
	80fe1ebc1fbc    stable/linux-6.12.y Revert "drm/amd/display: more liberal vmin/vmax update for freesync"

So all four affected branches are fixed now.

So there is nothing further to be done (unless
cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d or it's twin gets backported to
older versions).

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]