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

[Maarten Lankhorst]

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. :-)
>
> BR,
> Jani.
>
>
> [1] http://mid.gmane.org/1433155811-9671-1-git-send-email-maarten.lankhorst@linux.intel.com
> [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@linux.intel.com
> [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 at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx