On 2020-08-17 at 16:55:29 +0530, Uma Shankar wrote:
> Add an extra vblank before fbc is activated.
> WA: 1409689360
> Corruption with FBC around plane 1A enabling. In the Frame Buffer
> Compression programming sequence "Display Plane Enabling with FBC"
> add a wait for vblank between plane enabling step 1 and FBC enabling
> step 2.
>
> v2: Add wait only for active crtc
>
> Signed-off-by: Uma Shankar <[email protected]>
> Signed-off-by: Stanislav Lisovskiy <[email protected]>
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 2ab32e6532ff..2a9d4796c4a8 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1085,10 +1085,13 @@ static void __intel_fbc_post_update(struct intel_crtc
> *crtc)
> if (!intel_fbc_can_activate(crtc))
> return;
>
> - if (!fbc->busy_bits)
> + if (!fbc->busy_bits) {
> + if (IS_TIGERLAKE(dev_priv))
> + intel_wait_for_vblank_if_active(dev_priv, crtc->pipe);
IMHO with this we are also adding a VBLANK wait when fbc is getting enabled
from frontbuffer flush flow intel_fbc_flush(), i am being afraid if there
could be unnecessary VBLANK wait here.
Thanks,
Anshuman Gupta.
> intel_fbc_hw_activate(dev_priv);
> - else
> + } else {
> intel_fbc_deactivate(dev_priv, "frontbuffer write");
> + }
> }
>
> void intel_fbc_post_update(struct intel_atomic_state *state,
> --
> 2.22.0
>
> _______________________________________________
> Intel-gfx mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
