[PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

[Limonciello, Mario]

[Public]



> -----Original Message-----
> From: Guenter Roeck <groeck7 at gmail.com> On Behalf Of Guenter Roeck
> Sent: Friday, January 20, 2023 12:18
> To: Limonciello, Mario <Mario.Limonciello at amd.com>
> Cc: Lin, Wayne <Wayne.Lin at amd.com>; dri-devel at lists.freedesktop.org;
> amd-gfx at lists.freedesktop.org; stable at vger.kernel.org;
> stanislav.lisovskiy at intel.com; Zuo, Jerry <Jerry.Zuo at amd.com>;
> bskeggs at 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.