[PATCH v3 0/8] drm/i915: PREEMPT_RT related fixups.

[Ville Syrjälä]

On Wed, Oct 02, 2024 at 06:25:43PM +0200, Sebastian Andrzej Siewior wrote:
> On 2024-06-28 14:57:59 [+0200], To intel-gfx at lists.freedesktop.org wrote:
> Hi,
> 
> > The following patches are from the PREEMPT_RT queue.  It is mostly about
> > disabling interrupts/preemption which leads to problems. Unfortunately
> > DRM_I915_LOW_LEVEL_TRACEPOINTS had to be disabled because it acquires locks
> > from within trace points. Making the lock a raw_spinlock_t led to higher
> > latencies during video playback
> >   https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfyf7g@linutronix.de/
> > 
> > and I'm not sure if I hit the worse case here.
> > I tested it on a SandyBridge with built-in i915 by using X, OpenGL and
> > playing videos without noticing any warnings. However, some code paths
> > were not entered.
> > I carry them for some time now and most issues were reported by other
> > people and they reported that things work for them since.
> 
> These patches were not picked. Did I forget something or was this just
> overseen?

This looks quite poorly justified. Eg. you seem to be now
leaving interrupts enabled (and even preemption enabled I
guess) when we're racing against the raster beam. On first
blush that seems like a recipe for failure.

First step would be to set CONFIG_DRM_I915_DEBUG_VBLANK_EVADE=y,
run a bunch of tests that stress the display stuff (eg.
kms_atomic_transitions and other stuff from igt, and also
some real workloads) and probably throw in a bunch of
other load/perturbance at the system to make life hard.
After the system has been sufficiently hammered one can
compare sys/kernel/debug/dri/0/crtc-*/i915_update_info
against a baseline. Bonus points for doing it on a potato.

-- 
Ville Syrjälä
Intel