Re: [PATCH v4 19/27] drm/i915: Read hw state into an atomic state struct, v2.

From: Jani Nikula <jani.nikula@linux.intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Subject: Re: [PATCH v4 19/27] drm/i915: Read hw state into an atomic state struct, v2.
Date: Wed, 10 Jun 2015 10:47:12 +0300	[thread overview]
Message-ID: <87y4js6m4f.fsf@intel.com> (raw)
In-Reply-To: <55770087.9090600@linux.intel.com>

On Tue, 09 Jun 2015, Maarten Lankhorst <maarten.lankhorst@linux.intel.com> wrote:
> Hey,
>
> Op 09-06-15 om 16:24 schreef Jani Nikula:
>> On Tue, 09 Jun 2015, Maarten Lankhorst <maarten.lankhorst@linux.intel.com> wrote:
>>> Hey,
>>>
>>> Op 09-06-15 om 13:48 schreef Tvrtko Ursulin:
>>>> On 06/01/2015 11:50 AM, Maarten Lankhorst wrote:
>>>>> From: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
>>>>>
>>>>> To make this work we load the new hardware state into the
>>>>> atomic_state, then swap it with the sw state.
>>>>>
>>>>> This lets us change the force restore path in setup_hw_state()
>>>>> to use a single call to intel_mode_set() to restore all the
>>>>> previous state.
>>>>>
>>>>> As a nice bonus this kills off encoder->new_encoder,
>>>>> connector->new_enabled and crtc->new_enabled. They were used only
>>>>> to restore the state after a modeset.
>>>>>
>>>>> Changes since v1:
>>>>> - Make sure all possible planes are added with their crtc set,
>>>>>    so they will be turned off on first modeset.
>>>>>
>>>>> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
>>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>> This breaks display for me, which is eDP on SKL. At least bisect points to it. A lot of these in the logs:
>>>>
>>>> *ERROR* mismatch in dp_m_n.link_m (expected 701594 or 0, found 350797)
>>>>
>>>> And the display does not light up.
>>> Yeah, it probably relies on better hw readout. This is partially mitigated by convert to atomic, part 3.
>>> But it requires 2 additional patches.
>> Maarten, I'd like to have the fallout from this series fixed before
>> moving on to merging another big series...
> Nasty, part of the fix is in the following series.
>
> Could we revert only 490f400db5d886fc28566af69b02f6497f31be4b and 3bae26eb2991c00670df377cf6c3bc2b0577e82a ?
>
> First commit for https://bugs.freedesktop.org/show_bug.cgi?id=90868 and because it would break not-atomic resume otherwise.
> Second commit for https://bugs.freedesktop.org/show_bug.cgi?id=90861 .
>
> I'll rework convert to atomic part 3 to incorporate the commits again.

This sounds like a good plan to me.

Please send the reverts as patches, citing the bugs and failures.

BR,
Jani.

>
> ~Maarten

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx