Quoting Alex Deucher (2019-02-28 17:25:41) > On Thu, Feb 28, 2019 at 4:54 AM Chris Wilson <ch...@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 <airl...@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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel