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>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Maxime Ripard <maxime@cerno.tech>
Cc: Dave Stevenson <dave.stevenson@raspberrypi.com>,
	Phil Elwell <phil@raspberrypi.com>,
	Tim Gover <tim.gover@raspberrypi.com>,
	Dom Cobley <dom@raspberrypi.com>,
	dri-devel@lists.freedesktop.org,
	Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Subject: [PATCH 0/9] drm/vc4: Introduce locking and remove !KMS state access
Date: Mon, 25 Oct 2021 16:11:04 +0200	[thread overview]
Message-ID: <20211025141113.702757-1-maxime@cerno.tech> (raw)

Hi,

This is a follow-up of the series here:
https://lore.kernel.org/all/20210924135530.1036564-1-maxime@cerno.tech/

and the discussion that occured here:
https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/

The original series aimed at getting rid of the encoder->crtc pointer usage in
the vc4 HDMI driver, some regression was noticed and the following discussion
pointed out that we were doing a fair number of KMS state access outside of the
mode set path, which is disallowed and unsafe.

We already have a bug that was a result of that access which is fixed in the
second patch, but other instabilities might have occured without being
reported.

That series thus removes all those accesses, and add some locking in the
process.

Sudip, since that series changed very significantly since you last tested it,
could you give it a test run on the Codethink farm?

Let me know what you think,
Maxime

Maxime Ripard (9):
  drm/vc4: crtc: Drop feed_txp from state
  drm/vc4: Fix non-blocking commit getting stuck forever
  drm/vc4: crtc: Copy assigned channel to the CRTC
  drm/vc4: hdmi: Add a spinlock to protect register access
  drm/vc4: hdmi: Use a mutex to prevent concurrent framework access
  drm/vc4: hdmi: Prevent access to crtc->state outside of KMS
  drm/vc4: hdmi: Check the device state in prepare()
  drm/vc4: hdmi: Introduce an output_enabled flag
  drm/vc4: hdmi: Introduce a scdc_enabled flag

 drivers/gpu/drm/vc4/vc4_crtc.c      |  12 +-
 drivers/gpu/drm/vc4/vc4_drv.h       |  29 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c      | 415 +++++++++++++++++++++++++---
 drivers/gpu/drm/vc4/vc4_hdmi.h      |  37 +++
 drivers/gpu/drm/vc4/vc4_hdmi_phy.c  |  37 +++
 drivers/gpu/drm/vc4/vc4_hdmi_regs.h |   2 +
 drivers/gpu/drm/vc4/vc4_hvs.c       |  26 +-
 drivers/gpu/drm/vc4/vc4_kms.c       |   3 +-
 drivers/gpu/drm/vc4/vc4_txp.c       |   4 +-
 9 files changed, 509 insertions(+), 56 deletions(-)

-- 
2.31.1


             reply	other threads:[~2021-10-25 14:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-25 14:11 Maxime Ripard [this message]
2021-10-25 14:11 ` [PATCH 1/9] drm/vc4: crtc: Drop feed_txp from state Maxime Ripard
2021-10-25 14:11 ` [PATCH 2/9] drm/vc4: Fix non-blocking commit getting stuck forever Maxime Ripard
2021-10-25 14:11 ` [PATCH 3/9] drm/vc4: crtc: Copy assigned channel to the CRTC Maxime Ripard
2021-10-25 14:11 ` [PATCH 4/9] drm/vc4: hdmi: Add a spinlock to protect register access Maxime Ripard
2021-10-25 14:11 ` [PATCH 5/9] drm/vc4: hdmi: Use a mutex to prevent concurrent framework access Maxime Ripard
2021-10-25 14:11 ` [PATCH 6/9] drm/vc4: hdmi: Prevent access to crtc->state outside of KMS Maxime Ripard
2021-10-25 14:11 ` [PATCH 7/9] drm/vc4: hdmi: Check the device state in prepare() Maxime Ripard
2021-10-25 14:11 ` [PATCH 8/9] drm/vc4: hdmi: Introduce an output_enabled flag Maxime Ripard
2021-10-25 14:11 ` [PATCH 9/9] drm/vc4: hdmi: Introduce a scdc_enabled flag Maxime Ripard
2021-11-05 11:55 ` [PATCH 0/9] drm/vc4: Introduce locking and remove !KMS state access 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=20211025141113.702757-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=maarten.lankhorst@linux.intel.com \
    --cc=phil@raspberrypi.com \
    --cc=sudipm.mukherjee@gmail.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.