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

[Ville Syrjälä]

On Fri, Oct 04, 2024 at 10:45:25AM +0200, Sebastian Andrzej Siewior wrote:
> On 2024-10-04 11:31:22 [+0300], Ville Syrjälä wrote:
> > 
> > So once vblank evasion has declared things to be safe we might have
> > as short a time as VBLANK_EVASION_TIME_US to write all the registers.
> > If the CPU gets stolen from us at that point we can no longer guarantee
> > anything. The magic value has been tuned empirically over the years,
> > until we've found something that seems to work well enough, without
> > being too long to negatively affect performance.
> 
> what happens if this gets delayed? Just flicker or worse?

In the best best case it just gets you a corrupted frame
of some sort, in the worst case the hardware falls over.
Depends on what kind of update is happening, and what
platform we're dealing with.

We've tried to mitigate some of the worst issues by
trying to order the register writes more carefully,
but some of the ordering constraints (eg. scalers vs.
DDB) are more or less in conflict with each other
so making it 100% safe seems impossible.

> 
> Is this something that affects all i915 based HW or only old ones? As
> far as I remember, there is a register lock which is only required on
> older HW.

Currently it affects everything. There is a new double buffer
latching inhibit bit on some of the very latest platforms that
we could probably use to make things more safe if vblank evasion
fails, but we've not hooked that up. But vblank evasion would still
be necessary at least for cursor updates since those are
done as mailbox style updates (ie. multiple updates per frame)
and there is no way to guarantee forward progress without vblank
evasion.

Register access locks aren't relevant here, and most
register accesses in the vblank evade critical section
are lockless anyway. The locks were too expensive and we
determined that we an safely use lockless accesses here.

-- 
Ville Syrjälä
Intel