Hey, Op 12-06-15 om 14:45 schreef Jani Nikula: > On Fri, 12 Jun 2015, Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> wrote: >> Commit f662af8c5c1619 reverts >> "drm/i915: Read hw state into an atomic state struct, v2." >> but it doesn't take into account other changes that were done in that time. >> Before I continue on the atomic fixes I want to fix the fallout first, >> and some of the reasons I identified that could cause a failure for atomic >> modeset. >> >> When that's fixed I'll look at committing the atomic hw readout patch >> again, since it will be needed for converting to full atomic. >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90929 > To recap, the atomic conversion part 2 series [1] broke things > [2][3][4], and the quick fix reverts [5] broke other things [6], and now > we have these patches to fix that. > > I was resolved to either merge these fixes or purge the whole thing this > afternoon. On the one hand people have based their work on this and it > clearly now works with the test coverage we've had, on the other hand > I'm now less confident with the series overall, and Ville and Maarten > keep on debating about it. > > I've ended up chickening out of this and compromising. I've moved > ("demoted") Maarten's atomic series part 2 from drm-intel-next-queued to > a new topical branch topic/atomic-conversion, and added these four > patches on top. The topical branch merges to > drm-intel-nightly. Basically nightly now has these patches on top, but > the source of the commits is different. We were discussing the intel_plane_restore patch, but that was to fix a hard hang on my broadwell machine, that occurs when it terminally wedges. I picked the patch from my tree because I already had it and the warning made it looks like it would fix it. This was already broken before part 2 was applied. It can safely be dropped without affecting anyone affected by the hangs, the other 3 patches should still be applied to the topic branch. > Frankly what I'm doing is deferring this to Daniel who'll return next > week. He'll take over handling drm-intel-next-queue on his return > anyway, so given he'll have to deal with the rest of the fallout I think > it's only fair he can decide what to do. I would have dropped the whole > series and started over if I were in charge next week, but this will > probably cause less of a hickup right now. Sane decision, especially if he's back next monday. :-) > > BR, > Jani. > > > [1] http://mid.gmane.org/1433155811-9671-1-git-send-email-maarten.lankhorst@xxxxxxxxxxxxxxx > [2] https://bugs.freedesktop.org/show_bug.cgi?id=90868 > [3] https://bugs.freedesktop.org/show_bug.cgi?id=90861 > [4] https://bugs.freedesktop.org/show_bug.cgi?id=90874 > [5] http://mid.gmane.org/1433924660-2228-1-git-send-email-maarten.lankhorst@xxxxxxxxxxxxxxx > [6] https://bugs.freedesktop.org/show_bug.cgi?id=90929 > > >> Maarten Lankhorst (4): >> drm/i915: Do not use atomic modesets in hw readout. >> drm/i915: get rid of intel_plane_restore in intel_crtc_page_flip >> drm/i915: Set hwmode during readout. >> drm/i915: Only enable cursor if it can be enabled. >> >> drivers/gpu/drm/i915/intel_display.c | 108 ++++++++++++++++++++--------------- >> 1 file changed, 63 insertions(+), 45 deletions(-) >> >> -- >> 2.1.0 >> >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx