[Intel-gfx] [PATCH 0/4] Fix more fallout from reverting atomic hw readout.

[Daniel Vetter]

On Fri, Jun 12, 2015 at 03:10:53PM +0200, Maarten Lankhorst wrote:
> Hey,
> 
> Op 12-06-15 om 14:45 schreef Jani Nikula:
> > On Fri, 12 Jun 2015, Maarten Lankhorst <maarten.lankhorst at linux.intel.com> 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. :-)

Just for the recorded I decided that nothing can hamper my vacation mood
and pulled branch in with a merge. More seriously I don't expect that this
will be easier as a branch, and we've far enough away from 4.3 that I'm
confident we can fix up anything horrible that rears its ugly head in
time.

I'll definitely get less adventurous as get move towards 4.2-rc5 ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch