[AMD Official Use Only - General] > -----Original Message----- > From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > Sent: Sunday, January 29, 2023 07:32 > To: Limonciello, Mario <Mario.Limonciello@xxxxxxx> > Cc: Linux regressions mailing list <regressions@xxxxxxxxxxxxxxx>; dri- > devel@xxxxxxxxxxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx; > stanislav.lisovskiy@xxxxxxxxx; Zuo, Jerry <Jerry.Zuo@xxxxxxx>; amd- > gfx@xxxxxxxxxxxxxxxxxxxxx; Lin, Wayne <Wayne.Lin@xxxxxxx>; Guenter > Roeck <linux@xxxxxxxxxxxx>; bskeggs@xxxxxxxxxx > Subject: Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into > the atomic state" > > On Fri, Jan 27, 2023 at 03:02:41PM +0000, Limonciello, Mario wrote: > > [Public] > > > > > > > > > -----Original Message----- > > > From: Linux kernel regression tracking (Thorsten Leemhuis) > > > <regressions@xxxxxxxxxxxxx> > > > Sent: Friday, January 27, 2023 03:15 > > > To: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>; Limonciello, Mario > > > <Mario.Limonciello@xxxxxxx> > > > Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx; > > > stanislav.lisovskiy@xxxxxxxxx; Zuo, Jerry <Jerry.Zuo@xxxxxxx>; amd- > > > gfx@xxxxxxxxxxxxxxxxxxxxx; Lin, Wayne <Wayne.Lin@xxxxxxx>; Guenter > > > Roeck <linux@xxxxxxxxxxxx>; bskeggs@xxxxxxxxxx > > > Subject: Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info > into > > > the atomic state" > > > > > > On 27.01.23 08:39, Greg KH wrote: > > > > On Fri, Jan 20, 2023 at 11:51:04AM -0600, Limonciello, Mario wrote: > > > >> On 1/20/2023 11:46, Guenter Roeck wrote: > > > >>> On Thu, Jan 12, 2023 at 04:50:44PM +0800, Wayne Lin wrote: > > > >>>> This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f. > > > >>>> > > > >>>> [Why] > > > >>>> Changes cause regression on amdgpu mst. > > > >>>> E.g. > > > >>>> In fill_dc_mst_payload_table_from_drm(), amdgpu expects to > > > add/remove payload > > > >>>> one by one and call fill_dc_mst_payload_table_from_drm() to > update > > > the HW > > > >>>> maintained payload table. But previous change tries to go through > all > > > the > > > >>>> payloads in mst_state and update amdpug hw maintained table in > once > > > everytime > > > >>>> driver only tries to add/remove a specific payload stream only. The > > > newly > > > >>>> design idea conflicts with the implementation in amdgpu nowadays. > > > >>>> > > > >>>> [How] > > > >>>> Revert this patch first. After addressing all regression problems > caused > > > by > > > >>>> this previous patch, will add it back and adjust it. > > > >>> > > > >>> Has there been any progress on this revert, or on fixing the > underlying > > > >>> problem ? > > > >>> > > > >>> Thanks, > > > >>> Guenter > > > >> > > > >> Hi Guenter, > > > >> > > > >> Wayne is OOO for CNY, but let me update you. > > > >> > > > >> Harry has sent out this series which is a collection of proper fixes. > > > >> https://patchwork.freedesktop.org/series/113125/ > > > >> > > > >> Once that's reviewed and accepted, 4 of them are applicable for 6.1. > > > > > > > > Any hint on when those will be reviewed and accepted? patchwork > > > doesn't > > > > show any activity on them, or at least I can't figure it out... > > > > > > I didn't look closer (hence please correct me if I'm wrong), but the > > > core changes afaics are in the DRM pull airlied send a few hours ago to > > > Linus (note the "amdgpu […] DP MST fixes" line): > > > > > > > https://lore.kernel.org/all/CAPM%3D9tzuu4xnx6T5v7sKsK%2BA5HEaPOc1ie > > > MyzNSYQZGztJ%3D6Qw@xxxxxxxxxxxxxx/ > > > > That's right. There are 4 commits in that PR with the appropriate stable tags > > that should fix the majority of the MST issues introduced in 6.1 by > 4d07b0bc40340 > > ("drm/display/dp_mst: Move all payload info into the atomic state"): > > > > drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot count > assignments > > drm/amdgpu/display/mst: limit payload to be updated one by one > > drm/amdgpu/display/mst: update mst_mgr relevant variable when long > HPD > > drm/display/dp_mst: Correct the kref of port. > > > > There will be follow ups for any remaining corner cases. > > Great, thanks for this, all are now queued up in the 6.1.y queue. > > greg k-h Greg, My apologies if this has been covered elsewhere and I missed it but I was wondering if there was a decision made for whether 6.1.y will be an LTS kernel release or not?
