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); }
/*
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
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
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
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
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
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
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
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
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>
linux-stable-mirror@lists.linaro.org
-
Alex Deucher -
Aurabindo Pillai -
Greg KH -
Uwe Kleine-König