On 2024-10-04 12:07:24 [+0300], Ville Syrjälä wrote: > > 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. So based on what you are saying, this _has_ to happen with disabled interrupts. > > > > 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. This sounds sad. Especially since the delay is at 100us. > 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. The register lock question was only an example of something that is not required on newish hardware. Also disabling interrupts within in patch 1, 2 would require to make uncore:lock a raw_spinlock_t since it is acquire there. What do suggest as in how do we move forward? In terms of testing, I have here an i7 sandy bridge with embedded GPU. Sebastian
