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
