On Wed, 2015-06-17 at 15:13 +0300, Jani Nikula wrote: > On Wed, 17 Jun 2015, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: > > On Tue, 16 Jun 2015, Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@xxxxxxxxx> 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@xxxxxxxxxxxxxxxx> > >> Date: Wed Nov 5 14:26:06 2014 -0800 > >> > >> drm/i915: factor out compute_config from __intel_set_mode v3 > >> > >> v2: Rename check parameter to force_restore. (Matt) > >> > >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94431 > >> Cc: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> > >> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@xxxxxxxxx> > >> Reviewed-by: Matt Roper <matthew.d.roper@xxxxxxxxx> > > > > All three patches applied to drm-intel-next-fixes, aiming for v4.2 merge > > window. Thanks for the patches and review. > > > > For drm-intel-nightly, I resolved the conflicts by ignoring these > > changes and favoring what's in drm-intel-next-queued. Fingers crossed I > > didn't botch it up! > > Also, do we need some of these in v4.1 or earlier as well? Should we > backport once these are upstream? The regression 1/3 solves goes back to v3.19. The other patches are only relevant for 4.2 and later. Thanks, Ander _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
