On Thu, Jul 17, 2025 at 12:18 PM Melissa Wen <m...@igalia.com> wrote: > > On 17-07-2025 17:57, Matthew Schwartz wrote: > >> On Jul 17, 2025, at 9:58 AM, Limonciello, Mario > >> <mario.limoncie...@amd.com> wrote: > >> > >> On 7/17/25 11:55 AM, Melissa Wen wrote: > >>> On 17-07-2025 13:39, Limonciello, Mario wrote: > >>>> On 7/17/25 9:36 AM, Melissa Wen wrote: > >>>>> This reverts commit e1bd5e0bb4ca0d633ad698abd3658f8265009b81. > >>>>> > >>>>> The commit causes a regression in Steam Deck (DCN 3.01), reintroducing a > >>>>> functional issue reported in [1] that was fixed by calling the > >>>>> clear_update_flags() from commit 7671f62c10f2a. > >>>>> > >>>>> On Steam Deck, we use multiple hw plane color caps and up to two overlay > >>>>> planes with dynamic pipe split policy. I.e. with 1 primary + 1 overlay, > >>>>> the driver split planes into two (with 4 pipes), but with 1 primary + 2 > >>>>> overlays, we don't have enough pipe for splitting. Glitches appear in > >>>>> this pipe-split transition of 1-2 overlay planes, if the driver doesn't > >>>>> clear update flags. > >>>>> > >>>>> Besides that, the issue the commit e1bd5e0bb4ca tries to address [2] > >>>>> isn't functional. > >>>>> > >>>>> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3441 [1] > >>>>> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4129 [2] > >>>>> Signed-off-by: Melissa Wen <m...@igalia.com> > >>>> > >>>> Can you please double check the use case that prompted > >>>> e1bd5e0bb4ca0d633ad698abd3658f8265009b81 in the first place? IE With > >>>> this revert you proposed do you see a traceback on unplug of external > >>>> display? > >>> > >>> Hi Mario, > >>> > >>> I don't see either traceback or REG_WAIT timeout when unplugging an > >>> external HDMI-connected display. > >>> I tried with the Deck Dock and USB-C to HDMI adapter. Not sure if there > >>> is a very specific scenario that triggers this that I didn't cover. > >> > >> No; it's quite a general problem and easy to reproduce. This makes me > >> wonder if there should be an exception carved out for Steam Deck instead. > > > > I just tested DCN 3.1.2 (Z2 Go) and DCN 3.1.4 (Legion Go/ROG Ally) and > > I was not able to reproduce the issue so a Steam Deck carveout might make > > sense here. > > What issue are you trying to reproduce? > Glitches on Hades II + MangoHud, or traceback/REG_WAIT timeout?
Sorry, should've specified! I was testing for glitches with Hades II + MangoHud. > > And with what kernel version? amd-staging-drm-next built from b78bd800, tested on top of SteamOS Main > > Melissa > > > > > Matt > > > >> > >>> > >>> The only message on dmesg from this action is: > >>> amdgpu 0000:04:00.0: amdgpu: pp_od_clk_voltage is not accessible if > >>> power_dpm_force_performance_level is not in manual mode! > >>> > >>> Moreover, if I move to the Desktop mode (KDE), there is no message. > >>> > >>> Melissa > >>> > >>>> > >>>>> --- > >>>>> drivers/gpu/drm/amd/display/dc/core/dc.c | 5 +++-- > >>>>> 1 file changed, 3 insertions(+), 2 deletions(-) > >>>>> > >>>>> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c > >>>>> b/drivers/gpu/drm/amd/display/dc/core/dc.c > >>>>> index c31f7f8e409f..7c48f72e5917 100644 > >>>>> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c > >>>>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c > >>>>> @@ -5443,7 +5443,8 @@ bool dc_update_planes_and_stream(struct dc *dc, > >>>>> else > >>>>> ret = update_planes_and_stream_v2(dc, srf_updates, > >>>>> surface_count, stream, stream_update); > >>>>> - if (ret && dc->ctx->dce_version >= DCN_VERSION_3_2) > >>>>> + > >>>>> + if (ret) > >>>>> clear_update_flags(srf_updates, surface_count, stream); > >>>>> > >>>>> return ret; > >>>>> @@ -5474,7 +5475,7 @@ void dc_commit_updates_for_stream(struct dc *dc, > >>>>> ret = update_planes_and_stream_v1(dc, srf_updates, surface_count, > >>>>> stream, > >>>>> stream_update, state); > >>>>> > >>>>> - if (ret && dc->ctx->dce_version >= DCN_VERSION_3_2) > >>>>> + if (ret) > >>>>> clear_update_flags(srf_updates, surface_count, stream); > >>>>> }
