[PATCH v4 0/5] MST DSC support in drm-mst
Harry Wentland
hwentlan at amd.com
Mon Aug 26 21:12:56 UTC 2019
On 2019-08-26 3:50 p.m., Dave Airlie wrote:
> On Sat, 24 Aug 2019 at 06:24, Francis, David <David.Francis at amd.com> wrote:
>>
>> Adding DSC functionality to drm_dp_mst_atomic_check() is a good idea.
>> However, until amdgpu switches over to that system, I wouldn't be able
>> to test those changes. Making that switch is on our TODO list, and it would
>> fix a number of problems with our current MST implementation, but
>> it's going to be a major rewrite.
>>
>> MST DSC hardware is already on the market. It would be expedient to
>> merge the patches we need for Navi support sooner and update
>> drm_dp_mst_atomic_check when we're able to test it.
>
> Is there any commitment to rewriting it, a timeline or anything?
>
> The problem with this situation is there is always new hardware coming
> onto the market, and there is always pressure to support all the
> features of that new hardware, and the pressure always comes like this
> and being expedient. However I've found that a lot of the time the
> required refactor or work is never done, because the time is being
> allocated now to the next GPU that is coming on the market, and nobody
> ever cares enough to clean up their technical debt.
>
> How come the needs for MST DSC support wasn't identified earlier,
> blocked on refactoring of the code to use common code, and then that
> task made a higher priority?
>
drm_dp_mst_atomic_check was introduced by Lyude back in January with
https://patchwork.freedesktop.org/patch/276405/ as part of
https://patchwork.freedesktop.org/series/54031/
At the time Lyude updated i915 and nouveau to use these helpers. amdgpu
wasn't updated.
> I'm sorta inclined to say no we shouldn't be merging any driver
> specific code here, because this is the only point we can push
> pressure on to refactor the MST implementation, which I guess
> otherwise we'll just keep avoiding until Lyude ends up doing it for
> you.
>
That's fair. I agree that the refactor should be done and I understand
where you're coming from. Since David is heading back to school in less
than a week I was inclined to see if we can push back a little so he can
get his change in. Other than that I don't mind holding off on the merge
unless the refactor is done.
Adding Mikita who'll pick up DSC stuff from David and will iterate on
these patches if necessary and look at the MST refactor.
Thanks for keeping us honest.
Harry
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
More information about the dri-devel
mailing list