Re: [PATCH] drm/i915: Don't check modeset state in the hw state force restore path

Jani Nikula
2015-06-04T11:11:09Z

On Tue, 02 Jun 2015, Ander Conselvan De Oliveira <conselvan2@gmail.com> wrote:
> On Tue, 2015-06-02 at 09:27 +0200, Maarten Lankhorst wrote:
>> Op 02-06-15 om 09:12 schreef Jani Nikula:
>> > On Mon, 01 Jun 2015, Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> wrote:
>> >> Since the force restore logic will restore the CRTCs state one at a
>> >> time, it is possible that the state will be inconsistent until the whole
>> >> operation finishes. A call to intel_modeset_check_state() is done once
>> >> it's over, so don't check the state multiple times in between. This
>> >> regression was introduced in:
>> >>
>> >> commit 7f27126ea3db6ade886f18fd39caf0ff0cd1d37f
>> >> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
>> >> Date: Wed Nov 5 14:26:06 2014 -0800
>> >>
>> >> drm/i915: factor out compute_config from __intel_set_mode v3
>> >>
>> >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94431
>> >> Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
>> >> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
>> >> ---
>> >>
>> >> Hi,
>> >>
>> >> This patch applies on top of nightly, but it is only relevant without
>> >> Maarten's "drm/i915: Convert to atomic, part 2" series, because of the
>> >> changes to the hw state read out and force restore logic.
>> >>
>> >> The regression exists since 3.19.
>> > Sooo, I think this should be applied to fixes, with cc: stable v3.19+,
>> > and IIUC Maarten's series makes this obsolete in dinq?
>> >
>> > Now we just need review... Maarten?
>> >
>> > BR,
>> > Jani.
>> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>
>> Looks good to me, but it will conflict with my own patch series. :(
>
> I think it's fine to skip this for dinq, since we move to a single
> modeset in the force restore path with your patch series. I just got
> confused with what branch to base this on. Thanks for reviewing.

Looks like this conflicts even more between v4.1-rc and what's queued
for v4.2. I'll pass this for now, I'm think it may be easier to fix this
for v4.2 and backport from there.

BR,
Jani.

>
> Ander
>
>
>
>

--
Jani Nikula, Intel Open Source Technology Center