Hello, On 7/2/26 10:44, Jani Nikula wrote: > On Thu, 02 Jul 2026, Maarten Lankhorst <[email protected]> wrote: >> intel_set_pipe_src_size(), hsw_set_linetime_wm(), >> intel_cpu_transcoder_set_m1_n1() and intel_set_transcoder_timings_lrr() >> are called from an atomic context on PREEMPT_RT, and should be using the >> _fw functions. > > Why is intel_pipe_fastset() called in atomic context on PREEMPT_RT in > the first place? > > I have no idea how to maintain this. > > It is *hard* for people to figure out when to use regular or _fw > variants. > > The _fw variant usage spreads all over the place with this, and you'll > end up with folks cargo culting one or the other at random. Someone > looking at, say, intel_vrr.c won't know why one or the other is being > used. > > I have given similar feedback before, and the response was like, "it's > not that hard". I disagree. > > I think we'll need either 1) a mechanism in non-PREEMPT_RT to flag the > issues in CI, or 2) PREEMPT_RT runs in CI. I don't think either is going > to be trivial to achieve. > > > BR, > Jani.
Ideally we'd stop using the implicit DMC lock, and replace those with explicit DMC calls like the xe_forcewake_get/put pairs, together with the approximate region those calls cover. I'd love to either take the DMC wakelock for the entirety of a modeset so we can stop using the per-register notations, and use those register accesses only for warning. A lot of the register writes during vblank evasion use the intel_de_write_dsb variant, which mostly does the right thing already. This is purely about registers updated in the fastset case, which don't use the dsb argument. The option to flag for !PREEMPT_RT can be achieved in lockdep by adding a fake vblank evasion lockdep lock, together with a might_lock() in the non-fw calls. Kind regards, ~Maarten Lankhorst
