[RFC] amdgpu MST questions, and future plans

[RFC] amdgpu MST questions, and future plans

[Lyude Paul]

Hi! I'm writing this email because I'm currently finishing up removing pretty
much all of the non-atomic MST code in drm_dp_mst_topology_mgr.c as it's
really made it difficult to maintain MST over time. As well, once that's
complete it's likely I'm going to start on the (extremely overdue) task of
moving as much of amdgpu's MST code for DSC out of amdgpu and into the DRM
code where it's supposed to live.

This brings me to two questions. The first major one being: is anyone capable
of testing the MST support in radeon.ko to figure out whether it works or not?
I've already talked with hwentlan and ag5df about this and they haven't been
able to find anyone to help with testing this. The reason I ask is because
radeon isn't an atomic driver, and is basically the only user of any of the
non-atomic parts of the MST helpers. If anyone want to prevent this from
breaking in the future, I would definitely recommend they step up to try and
help with testing it - otherwise I'm probably going to be pushing for us just
to drop the code entirely.

The second question is: is anyone willing to help me figure out how much of
the code in amdgpu related to DSC is definitely not amdgpu specific and can be
moved out? I'm honestly having a lot of trouble wrapping my head around how
some of this works, and how much of this code is even needed. As well, with
the amount of issues I've already found in it (there's numerous spots where
we're storing MST state outside of atomic state for instance, lots of
duplicates of DP helper functions that should not be here, etc.) it's quite
likely I'm going to be rewriting rather large chunks of it. If anyone would
like to volunteer please let me know, it'd be super appreciated and likely
will make reviewing the patches that will come out of this easier.
-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

Re: [RFC] amdgpu MST questions, and future plans

[Lyude Paul]

On Wed, 2022-01-19 at 17:56 -0500, Lyude Paul wrote:
> Hi! I'm writing this email because I'm currently finishing up removing
> pretty
> much all of the non-atomic MST code in drm_dp_mst_topology_mgr.c as it's
> really made it difficult to maintain MST over time. As well, once that's
> complete it's likely I'm going to start on the (extremely overdue) task of
> moving as much of amdgpu's MST code for DSC out of amdgpu and into the DRM
> code where it's supposed to live.
> 
> This brings me to two questions. The first major one being: is anyone
> capable
> of testing the MST support in radeon.ko to figure out whether it works or
> not?
> I've already talked with hwentlan and ag5df about this and they haven't been
> able to find anyone to help with testing this. The reason I ask is because
> radeon isn't an atomic driver, and is basically the only user of any of the
> non-atomic parts of the MST helpers. If anyone want to prevent this from
> breaking in the future, I would definitely recommend they step up to try and
> help with testing it - otherwise I'm probably going to be pushing for us
> just
> to drop the code entirely.
> 
> The second question is: is anyone willing to help me figure out how much of
> the code in amdgpu related to DSC is definitely not amdgpu specific and can
> be
> moved out? I'm honestly having a lot of trouble wrapping my head around how
> some of this works, and how much of this code is even needed. As well, with
> the amount of issues I've already found in it (there's numerous spots where
> we're storing MST state outside of atomic state for instance, lots of
> duplicates of DP helper functions that should not be here, etc.) it's quite
> likely I'm going to be rewriting rather large chunks of it. If anyone would

mhhh - on second thought I think I'm starting to wrap my head around this and
it's not actually too bad :), still could use some help with the radeon
testing though!

> like to volunteer please let me know, it'd be super appreciated and likely
> will make reviewing the patches that will come out of this easier.

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat