big conflict in drm-tip (amdgpu)

big conflict in drm-tip (amdgpu)

[Dave Airlie]

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.

Thanks,
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: big conflict in drm-tip (amdgpu)

[Daniel Vetter]

On Thu, Feb 28, 2019 at 5:30 AM Dave Airlie <airlied@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 :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: big conflict in drm-tip (amdgpu)

[Chris Wilson]

Quoting Daniel Vetter (2019-02-28 09:49:51)
> On Thu, Feb 28, 2019 at 5:30 AM Dave Airlie <airlied@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.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: big conflict in drm-tip (amdgpu)

[Alex Deucher]

On Thu, Feb 28, 2019 at 4:54 AM Chris Wilson <chris@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@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.

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 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@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@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

Re: big conflict in drm-tip (amdgpu)

[Alex Deucher]

On Thu, Feb 28, 2019 at 12:43 PM Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Alex Deucher (2019-02-28 17:25:41)
> > On Thu, Feb 28, 2019 at 4:54 AM Chris Wilson <chris@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@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....

d63716658ac1 ("drm/amd/display: Use vrr friendly pageflip throttling
in DC.") should be dropped and this should be applied instead for
drm-next:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2-wip&id=5d5f43c235d02e4d8e9d50d012f3b21f380486eb

Alex

> -Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel