big conflict in drm-tip (amdgpu)

[Chris Wilson]

Quoting Alex Deucher (2019-02-28 17:25:41)
> On Thu, Feb 28, 2019 at 4:54 AM Chris Wilson <chris at chris-wilson.co.uk> wrote:
> >
> > Quoting Daniel Vetter (2019-02-28 09:49:51)
> > > On Thu, Feb 28, 2019 at 5:30 AM Dave Airlie <airlied at gmail.com> wrote:
> > > >
> > > > I merged some fixes into drm-fixes, pushed it out, then saw tip
> > > > breaking, but I'm needed elsewhere, so if anyone can fix tip up or
> > > > tell me why I got a super messy commit, I'll owe you.
> > >
> > > Chris already patched it up it seems, I guess someone should
> > > double-check it's reasonable. For the future might be good if amd
> > > trees push into drm-tip and/or linux-next beforehand, for early
> > > warning and testing of the merge resolution. Ideally both I'd say.
> > > It's the biggest driver we have after all :-)
> >
> > I took a conservative approach, and just verified that the code still
> > compiled. I expect the vrr fakery was reverted in the process, but also
> > expect that new code will be flowing from amdgpu in their next update
> > anyway.
> 
> Can you point me to the conflict?  I'll take a look.  Sorry for the
> noise.  The VRR fix for 5.0 was a backport since the code changed
> slightly between 5.0 and 5.1.  We have the same fix against 5.1 as
> well if that is what the problem was.

https://cgit.freedesktop.org/drm/drm-tip/commit/?h=rerere-cache&id=660b640f5938ce08c95d75bd7a20182a92e1467f
see amdgpu_dm_commit_planes()

Presentation in rerere-cache is very weird, there's probably a better
way to review the merge choice&resolution....
-Chris