All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Maarten Lankhorst <dev@lankhorst.se>
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 00/10] drm/intel/display: Changes required to make vblank evasion PREEMPT_RT safe.
Date: Fri, 10 Jul 2026 17:43:53 +0300	[thread overview]
Message-ID: <alEFKfqD-69wOVxJ@intel.com> (raw)
In-Reply-To: <20260702072154.171324-1-dev@lankhorst.se>

On Thu, Jul 02, 2026 at 09:21:43AM +0200, Maarten Lankhorst wrote:
> CONFIG_PREEMPT_RT requires code to be as deterministic as possible,
> and codes with interrupts disabled cannot use spinlocks.
> 
> In order to handle this correctly, we ensure any locking requirements
> are handled before disabling interrupts, and only start locking again
> after interrupts are re-enabled and timing sensitive path completed.
> 
> This also has the benefit of making the vblank evasion code more
> deterministic; without locking there's much less jitter.
> 
> Previously, we scheduled vblank work on completion.
> This is now handled by scheduling the vblank in advance, only arming
> it upon completion without locks.

Sashiko found a bunch of stuff that I was also thinking would be
a problem. Don't think I'll need to repeat it here.

I'm still thinking the easy way out would be to just convert
everything to raw spinlocks. The uncore lock I think should become
easier to deal with once I manage to move all of it into the
display code. I admit that the vblank locking is kinda annoying
and potentially inefficient. I've been pondering about making the
vblank locks to per-crtc to at least avoid some unnecessary contention,
but the fact that a lot of the drivers poke at the vblank internals
directly makes it a lot more work than it should be :/

> 
> Maarten Lankhorst (9):
>   drm/vblank_work: Add methods to schedule vblank_work in 2 stages
>   drm/vblank: Add a 2-stage version of drm_crtc_arm_vblank_event
>   drm/intel/display: Make intel_crtc_arm_vblank_event static
>   drm/intel/display: Convert vblank event handling to 2-stage arming
>   drm/i915/display: Move vblank put until after critical section
>   drm/i915/display: Remove locking from intel_vblank_evade critical
>     section
>   drm/i915/display: Handle vlv dsi workaround in scanline_in_safe_range
>     too
>   drm/i915/display: Make get_vblank_counter use intel_de_read_fw()
>   drm/i915/display: Do not take uncore lock in i915_get_vblank_counter
> 
> Mike Galbraith (1):
>   drm/i915: Use preempt_disable/enable_rt() where recommended
> 
>  drivers/gpu/drm/drm_vblank.c                  |  64 +++++++++-
>  drivers/gpu/drm/drm_vblank_work.c             | 110 +++++++++++++----
>  drivers/gpu/drm/i915/display/intel_crtc.c     |  86 ++++++-------
>  drivers/gpu/drm/i915/display/intel_crtc.h     |   1 -
>  drivers/gpu/drm/i915/display/intel_cursor.c   |   8 +-
>  drivers/gpu/drm/i915/display/intel_de.h       |   8 ++
>  drivers/gpu/drm/i915/display/intel_vblank.c   | 115 ++++++++++--------
>  drivers/gpu/drm/i915/display/intel_vblank.h   |   1 +
>  drivers/gpu/drm/i915/intel_uncore.h           |  26 ++--
>  .../drm/xe/compat-i915-headers/intel_uncore.h |   7 ++
>  include/drm/drm_vblank.h                      |  14 ++-
>  include/drm/drm_vblank_work.h                 |  12 ++
>  12 files changed, 324 insertions(+), 128 deletions(-)
> 
> -- 
> 2.53.0

-- 
Ville Syrjälä
Intel

  parent reply	other threads:[~2026-07-10 14:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02  7:21 [PATCH 00/10] drm/intel/display: Changes required to make vblank evasion PREEMPT_RT safe Maarten Lankhorst
2026-07-02  7:21 ` [PATCH 01/10] drm/vblank_work: Add methods to schedule vblank_work in 2 stages Maarten Lankhorst
2026-07-02  7:32   ` sashiko-bot
2026-07-02  7:21 ` [PATCH 02/10] drm/vblank: Add a 2-stage version of drm_crtc_arm_vblank_event Maarten Lankhorst
2026-07-02  7:35   ` sashiko-bot
2026-07-02  7:21 ` [PATCH 03/10] drm/intel/display: Make intel_crtc_arm_vblank_event static Maarten Lankhorst
2026-07-10 14:20   ` Ville Syrjälä
2026-07-02  7:21 ` [PATCH 04/10] drm/intel/display: Convert vblank event handling to 2-stage arming Maarten Lankhorst
2026-07-02  7:37   ` sashiko-bot
2026-07-02  7:21 ` [PATCH 05/10] drm/i915/display: Move vblank put until after critical section Maarten Lankhorst
2026-07-02  7:34   ` sashiko-bot
2026-07-02  7:21 ` [PATCH 06/10] drm/i915/display: Remove locking from intel_vblank_evade " Maarten Lankhorst
2026-07-02  7:36   ` sashiko-bot
2026-07-02  7:21 ` [PATCH 07/10] drm/i915/display: Handle vlv dsi workaround in scanline_in_safe_range too Maarten Lankhorst
2026-07-02  7:30   ` sashiko-bot
2026-07-02  7:21 ` [PATCH 08/10] drm/i915: Use preempt_disable/enable_rt() where recommended Maarten Lankhorst
2026-07-02  7:36   ` sashiko-bot
2026-07-02  7:21 ` [PATCH 09/10] drm/i915/display: Make get_vblank_counter use intel_de_read_fw() Maarten Lankhorst
2026-07-02  7:43   ` sashiko-bot
2026-07-10 14:34   ` Ville Syrjälä
2026-07-02  7:21 ` [PATCH 10/10] drm/i915/display: Do not take uncore lock in i915_get_vblank_counter Maarten Lankhorst
2026-07-10 14:19   ` Ville Syrjälä
2026-07-02  7:56 ` ✗ CI.checkpatch: warning for drm/intel/display: Changes required to make vblank evasion PREEMPT_RT safe Patchwork
2026-07-02  7:58 ` ✓ CI.KUnit: success " Patchwork
2026-07-02  8:33 ` ✓ Xe.CI.BAT: " Patchwork
2026-07-02 10:04 ` ✓ i915.CI.BAT: " Patchwork
2026-07-03  2:09 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-07-03  2:17 ` ✗ i915.CI.Full: " Patchwork
2026-07-10 14:43 ` Ville Syrjälä [this message]
2026-07-13 10:59   ` [PATCH 00/10] " Maarten Lankhorst

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=alEFKfqD-69wOVxJ@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dev@lankhorst.se \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    /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.