[Public]
> -----Original Message----- > From: Guenter Roeck <groe...@gmail.com> On Behalf Of Guenter Roeck > Sent: Friday, January 20, 2023 12:18 > To: Limonciello, Mario <mario.limoncie...@amd.com> > Cc: Lin, Wayne <wayne....@amd.com>; dri-de...@lists.freedesktop.org; > amd-gfx@lists.freedesktop.org; sta...@vger.kernel.org; > stanislav.lisovs...@intel.com; Zuo, Jerry <jerry....@amd.com>; > bske...@redhat.com > 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.
