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

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

On Fri, Oct 04, 2024 at 08:49:51AM +0200, Sebastian Andrzej Siewior wrote:
> On 2024-10-02 19:58:08 [+0300], Ville Syrjälä wrote:
> > > These patches were not picked. Did I forget something or was this just
> > > overseen?
> > 
> > This looks quite poorly justified. Eg. you seem to be now
> > leaving interrupts enabled (and even preemption enabled I
> > guess) when we're racing against the raster beam. On first
> > blush that seems like a recipe for failure.
> 
> I can't really parse this. I may leave interrupts enabled in vblanc code
> (the first two patches).

vblank evasion 101:
We need to write a boatload of registers atomically within one 
frame. We try to guarantee that by checking if we're too close 
the point at which the hardware latches said registers, and if 
so we defer the update into the next frame.

raster scan/time ->
.....vertical active.........><...vertical blank...><...vertical active...><...vertical blank
     <VBLANK_EVASION_TIME_US> ^^                                          ^
            ^                 ||                                          |
            |   registers are /|                            registers are /
            |   latched here   |                             latched here
            |                  |
    If we're somewhere         |
    in here we delay           |
    writing the registers...   ...until we are about here and then we have most
                               of the frame to write all the registers. Though
                               since we use an interrupt to wait for this point
                               interrupt latency does eat into the budget a bit

.....vertical active.........><..vertical blank...><...
     <VBLANK_EVASION_TIME_US> ^
  <-.                         |
    |           registers are /
    |           latched here
    |
    If we're somewhere to the left of this
    point we proceed to write the registers
    immediately and now in the worst case we
    have exactly VBLANK_EVASION_TIME_US to
    write all the registers

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.

-- 
Ville Syrjälä
Intel