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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2015-06-17 at 15:04 +0300, Jani Nikula 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!

In the end, that means only the content of 3/3 is in -nightly. It won't
fix any of the issues, but shouldn't cause any problems.

Ander


_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux