All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime@cerno.tech>
To: Daniel Vetter <daniel.vetter@intel.com>, David Airlie <airlied@linux.ie>
Cc: Dom Cobley <dom@raspberrypi.com>,
	Tim Gover <tim.gover@raspberrypi.com>,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	dri-devel@lists.freedesktop.org,
	Maxime Ripard <maxime@cerno.tech>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Phil Elwell <phil@raspberrypi.com>
Subject: [PATCH 0/8] drm/vc4: Fix frame corruption when moving the cursor
Date: Mon, 21 Feb 2022 14:41:47 +0100	[thread overview]
Message-ID: <20220221134155.125447-1-maxime@cerno.tech> (raw)

Hi,

This series fixes a long standing issue with the VC4 driver when one was
moving the cursor on X11 along the edges of the monitor, if we had
overscan margins enabled.

The details are in the commit log of the last patch, but the main reason
was that moving along the edges with the overscan margins enabled
triggers a full blown commit, as opposed to an async commit. Since that
commit is on the cursor plane, it's treated as a legacy cursor update,
and won't wait for vblank, so it's possible to queue multiple commit
between vblank.

Now, the composition happens in the HVS, and the HVS has a series of
descriptors stored in an internal RAM, one for each plane. Allocations
in that RAM are tied to the CRTC state, and freed when that state is
destroyed. That internal RAM is also used by the HVS to store some
internal context while it's generating a frame.

If we get multiple commits between vblanks, chances are that the RAM
entries used by one of the first commit is going to be freed and reused
by a later commit, which will then overwrite the content of the earlier
entries, erasing the context in the process and corrupting the frame.

We've tested multiple solutions, but the one that seem to work without
any cons is to defer the deallocation of RAM entries to the next vblank
after the CRTC state has been freed.

Let me know what you think,
Maxime

Maxime Ripard (8):
  drm/vc4: kms: Take old state core clock rate into account
  drm/vc4: hvs: Fix frame count register readout
  drm/vc4: hvs: Store channel in variable
  drm/vc4: hvs: Remove dlist setup duplication
  drm/vc4: hvs: Move the dlist setup to its own function
  drm/vc4: hvs: Ignore atomic_flush if we're disabled
  drm/vc4: hvs: Use pointer to HVS in HVS_READ and HVS_WRITE macros
  drm/vc4: hvs: Defer dlist slots deallocation

 drivers/gpu/drm/vc4/vc4_crtc.c |  24 +--
 drivers/gpu/drm/vc4/vc4_drv.h  |  30 +++-
 drivers/gpu/drm/vc4/vc4_hvs.c  | 309 ++++++++++++++++++++++++++-------
 drivers/gpu/drm/vc4/vc4_kms.c  |  10 +-
 drivers/gpu/drm/vc4/vc4_regs.h |  13 +-
 5 files changed, 299 insertions(+), 87 deletions(-)

-- 
2.35.1


             reply	other threads:[~2022-02-21 13:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-21 13:41 Maxime Ripard [this message]
2022-02-21 13:41 ` [PATCH 1/8] drm/vc4: kms: Take old state core clock rate into account Maxime Ripard
2022-02-21 13:41 ` [PATCH 2/8] drm/vc4: hvs: Fix frame count register readout Maxime Ripard
2022-02-21 13:41 ` [PATCH 3/8] drm/vc4: hvs: Store channel in variable Maxime Ripard
2022-02-21 13:41 ` [PATCH 4/8] drm/vc4: hvs: Remove dlist setup duplication Maxime Ripard
2022-02-21 13:41 ` [PATCH 5/8] drm/vc4: hvs: Move the dlist setup to its own function Maxime Ripard
2022-02-21 13:41 ` [PATCH 6/8] drm/vc4: hvs: Ignore atomic_flush if we're disabled Maxime Ripard
2022-02-21 13:41 ` [PATCH 7/8] drm/vc4: hvs: Use pointer to HVS in HVS_READ and HVS_WRITE macros Maxime Ripard
2022-02-21 13:41 ` [PATCH 8/8] drm/vc4: hvs: Defer dlist slots deallocation Maxime Ripard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220221134155.125447-1-maxime@cerno.tech \
    --to=maxime@cerno.tech \
    --cc=airlied@linux.ie \
    --cc=daniel.vetter@intel.com \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=dom@raspberrypi.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=phil@raspberrypi.com \
    --cc=tim.gover@raspberrypi.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.