[Intel-gfx] [PATCH] drm/i915: Clear intel_crtc->atomic before updating it.

[Daniel Stone]

Hi,

On 16 November 2015 at 11:49, Maarten Lankhorst <maarten at mblankhorst.nl> wrote:
> If an atomic update fails intel_crtc->atomic may have have some values left
> from the last atomic check. One example is atomic->wait_for_vblank,
> which results in spurious errors in kms_flip.
>
> Testcase: kms_flip
> Reported-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Cc: stable at vger.kernel.org #v4.3
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> ---
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index b5f7493213b7..b9539b14fe0d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13141,6 +13141,9 @@ static int intel_atomic_check(struct drm_device *dev,
>                 struct intel_crtc_state *pipe_config =
>                         to_intel_crtc_state(crtc_state);
>
> +               memset(&to_intel_crtc(crtc)->atomic, 0,
> +                      sizeof(struct intel_crtc_atomic_commit));
> +
>                 /* Catch I915_MODE_FLAG_INHERITED */
>                 if (crtc_state->mode.private_flags != crtc->state->mode.private_flags)
>                         crtc_state->mode_changed = true;

How about doing it in intel_crtc_duplicate_state instead? Should be a
bit more bulletproof/correct against various other failure modes. But
I guess this does work, and it is all going away shortly, so:
Reviewed-by: Daniel Stone <daniels at collabora.com>

I think the reason we haven't been bitten by cdclk failures inside
intel_atomic_state.atomic, is because intel_atomic_state always starts
with a zeroed structure.

Cheers,
Daniel