[Public] > -----Original Message----- > From: Guenter Roeck <groeck7@xxxxxxxxx> On Behalf Of Guenter Roeck > Sent: Friday, January 20, 2023 12:18 > To: Limonciello, Mario <Mario.Limonciello@xxxxxxx> > Cc: Lin, Wayne <Wayne.Lin@xxxxxxx>; dri-devel@xxxxxxxxxxxxxxxxxxxxx; > amd-gfx@xxxxxxxxxxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx; > stanislav.lisovskiy@xxxxxxxxx; Zuo, Jerry <Jerry.Zuo@xxxxxxx>; > bskeggs@xxxxxxxxxx > Subject: Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into > the atomic state" > > Hi Mario, > > 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. > > Thanks a lot for the update. There is talk about abandoning v6.1.y as > LTS candidate, in large part due to this problem, so it would be great > to get the problem fixed before that happens. Any idea how soon that decision is happening? It seems that we have line of sight to a solution including back to 6.1.y pending that review. So perhaps we can put off the decision until those are landed.
