[PATCH 00/76] DAL Patches Nov 21, 2016

[Alex Deucher]

On Tue, Nov 22, 2016 at 7:06 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
> I hate to shime in but from review point of view what i don't undersntand is why
> isn't there a single reviewable patchset for DAL ?
>
> What i mean by that is a patchset in which you collapse all fixes and cleanup so
> that there is an easy way to review thing. Yes this means loosing history and
> major work to just spawn a new patchset but quite frankly in this state this thing
> is just unreviewable. The only sane way today is to look at git tree with the whole
> thing applied and avoid looking at individual patch. That not a sane way to do
> review in my mind.

As Harry mentioned, the display team is starting the process of moving
their development to this mailing list so Harry will start sending
regular development patches from the display team until they get fully
ramped up on using the public mailing list.

As for upstreaming the new display code, we are still working on
addressing all of the previous concerns, but it takes a while as we
have a lot of customer deliverables and new asic work so the clean up
and reorg has had to happen in parallel as time permits.  I don't know
that it makes a lot of sense to re-generate new patches for upstream
again at this point if they are not likely to make it upstream.  The
idea of flagging the new display code as staging code was suggested a
while ago so that we could work on clean up and better integration
upstream, but I think that got shot down.  We don't have the resources
to rewrite the entire thing from scratch, so it needs to be an
iterative process.  Right now we share the Linux display code with the
our pre-and post silicon validation and diagnostics teams (and we have
plans to move other platforms to this code as well down the road) so
we need to make sure we don't break them while we reorg the code for
upstream.

For the most part, I agree with many of the changes we need to make to
get the code upstream, it's just frustrating for us and for our users
to have to use out of tree code to enable most advanced display
functionality while we work through those issues.  I understand the
arguments for general upstream maintainability absent our support, but
that has to be countered with being able to support features and asics
now.  Moreover, we've been working upstream for a long time now, so I
don't think it's that likely that we are just going to disappear and
leave hard to maintain code.  We end up having to spend a lot of
resources on maintaining big out of tree packages for OEMs and other
customers that we could be spent on getting the code ready for
upstream.  It's a vicious cycle.

Alex

>
> That just my opinion other might disagree but i thought i would say that outloud.
>
> Cheers,
> Jérôme
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx