Re: PREEMPT_RT vs i915

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Tue, Jul 08, 2025 at 09:35:21PM +0200, Ben Hutchings wrote:
> Hi all,
> 
> Debian currently provides non-default kernel packages with the
> PREEMPT_RT patchset applied and enabled.  However, for the Debian 14
> "forky" release the plan is to use only the upstream RT support.
> 
> One result of this is that the i915 driver will not be included in our
> RT kernel package on amd64 because the upstream version lacks the
> patches to make it compatible with PREEMPT_RT.  This was not a surprise
> to us, but may disappoint some of our users (for example see
> <https://bugs.debian.org/1108324>).
> 
> I see that Sebastian submitted the i915 fixes upstream in October 2024.
> If I understand the explanation in
> <https://lore.kernel.org/intel-gfx/Zv-n2h0gsquKOvXu@intel.com/> rightly,
> much of these changes are unsafe because i915 has its own hard timing
> requirement for reprogramming multiple display controller registers
> within a single frame.  Is that still the sticking point?
> 
> It seems like the critical uncore lock is currently held in a lot of
> places and potentially for a long time.

It shouldn't be held for that long. I think it should just be
a raw spinlock.

The only edge case I know is the weird retry hack in
__intel_get_crtc_scanline() which I suspect is just due to PSR
and could potentially be handled in a nicer way by actually
checking the PSR state.

> Would it be practical to split
> this lock into:
> 
> 1. raw spinlock protecting only state needed for the atomic (within-one-
> frame) update

Spinlocks aren't involved in that. It is achieved by racing against
the beam, with interrupts disabled to make it more likely the CPU
wins the race.

> 2. regular spinlock protecting everything in uncore
> 
> or is almost all the uncore state potentially used during an atomic
> update?
> 
> Would it help to offload the atomic updates to a kthread that runs with
> RT priority but still with hard interrupts enabled?

Not sure what another thread would specifically get us, as opposed
to eg. just boosting the priority of the existing thread? But whatever
thread does the work needs to not be interrupted for any significant
amount of time.

The interrupt disabling part I suppose is rather hardware/workload
specific, so hard to say anything general about it.

> 
> Would it make things easier if setting CONFIG_PREEMPT_RT=y limited i915
> to not run on some older hardware?

No. All hardware needs this.

Anyways, all of this is rather academic at this point. Someone
needs to try and see what works, and hammer it hard while doing so
to make sure it doesn't fall over easily.

-- 
Ville Syrjälä
Intel