On Tue, Mar 03, 2015 at 09:03:32AM -0800, Linus Torvalds wrote: > On Tue, Mar 3, 2015 at 8:31 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > > > > Fix this all by applying the same duct-tape as for the legacy setcrtc > > ioctl code and set crtc->primary->crtc properly. > > Ack. Tests fine on the machine that showed issues for me. > > I'll apply it manually directly to my tree, since I want to release > rc2 and I was holding that up in the hope this would get released (I > hate releasing even early rc's with issues that I know about and that > break machines I have access to). Fine with me. If you haven't pushed out yet can you maybe clarify the commit message? The setcrtc step must be one that disables the crtc, only then will we (again) skip the book-keeping for plane->state->fb and unref to 0 in the drm core. If you directly switch to another fb/mode then we'll unref to 0 in the state duplicate and then blow up in the drm core when doing the unref for plane->old_fb. But since X generally disable everything before enabling the new config the previuos one is how we more likely blow up, and hence also why duplicate_state blows up. > If it ends up in your tree too and I'll get a duplicate commit later, > git will sort it all out, so it's fine. The revert and another patch to make the load detect code testable in an automated fashion on modern platfroms to avoid another occurence of this mess are fully independent of this one line. So no conflicts to be expected. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
