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-n2h0gsquko...@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. Would it be practical to split this lock into: 1. raw spinlock protecting only state needed for the atomic (within-one- frame) update 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? Would it make things easier if setting CONFIG_PREEMPT_RT=y limited i915 to not run on some older hardware? Ben. -- Ben Hutchings All the simple programs have been written, and all the good names taken
signature.asc
Description: This is a digitally signed message part
