Hey, Den 2025-11-26 kl. 20:42, skrev Ville Syrjälä: > On Wed, Nov 26, 2025 at 07:19:47PM +0000, Shankar, Uma wrote: >> >> >>> -----Original Message----- >>> From: Intel-gfx <[email protected]> On Behalf Of >>> Maarten >>> Lankhorst >>> Sent: Tuesday, November 4, 2025 2:06 PM >>> To: [email protected]; [email protected] >>> Cc: [email protected]; Maarten Lankhorst <[email protected]>; >>> Mario >>> Kleiner <[email protected]>; Mike Galbraith >>> <[email protected]>; Thomas Gleixner <[email protected]>; Sebastian >>> Andrzej Siewior <[email protected]>; Clark Williams >>> <[email protected]>; Steven Rostedt <[email protected]> >>> Subject: [PATCH v2 2/7] drm/i915/display: Use intel_de_write_fw in >>> intel_pipe_fastset >>> >>> 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. >> >> This could be ok but we need to be sure that all are called with power >> domains up. >> I think would be safe to keep this under RT check so that we don't end up >> breaking any >> generic non RT usecase. > > When removing the locks from register accesses one needs to consider > what platforms the code runs on, what other register are on the same > cacheline, and whether they can be accessed in parallel. If there is > something there then we may not be able to remove the locks. > > That's assuming the "system hangs when same cacheline is accessed from > multiple cpus" issue is real for display registers, and I'm actually > not 100% it is. But we'd need to run some tests on the affected systems > (~ivb/hsw) to get any kind of confidence here. IIRC some old > intel_gpu_top thhat directly poked the registers was very good at > hitting it on hsw at least, so that would be a decent starting point. > > Anyways, I'm going to be replacing the uncore lock with a display > specific lock soonish, and I suppose I can just make that a raw > spinlock to appease RT.
You're correct about the cacheline problem! We shouldn't be having a race in those specific registers though. On the current kernel they would likely hang the system if the _fw variants are not taken, as it means the uncore lock would be taken twice. This means the fastset path is already broken on systems requiring uncore lock, and this simply fixes it instead. Kind regards, ~Maarten Lankhorst
