On Thu, Apr 12, 2018 at 07:28:48PM +0000, Runyan, Arthur J wrote: > This seems like a typical atomic modeset requirement. > > IPC should not impact register programming. > Vblank evasion only works if you have a guarantee on worst case > interrupts/delays. I think locks is part of the guarantee. > Double buffer control should guarantee safe alignment of programming across > planes on the same pipe.
This is the part that troubles me. This was supposedly tested, but apparently it didn't help. Are there some relevant registers that don't respect the double buffer control? > Multiple pipes will still require a wait for vblank. I don't think the problems should be related to multiple pipes. We shouldn't be overlapping any allocations between planes on different pipes while they're running, and the pipe enable/disable code should be sequencing things correctly (with appropriate vblank waits) to avoid overlaps. > > From: Vyas, Tarun > Sent: Thursday, 12 April, 2018 9:57 AM > To: intel-gfx@lists.freedesktop.org > Cc: Runyan, Arthur J <arthur.j.run...@intel.com>; Shaikh, Azhar > <azhar.sha...@intel.com>; Herbert, Marc <marc.herb...@intel.com>; Ciobanu, > Nathan D <nathan.d.ciob...@intel.com>; Lankhorst, Maarten > <maarten.lankho...@intel.com> > Subject: Incorrect plane programming sequence results into a corrupted > display/hard hung system > > On KBL platforms, with HW overlay and/or PSR2, a hard hang with corrupted > display is observed while running tests that frequently disable/re-enable > primary/overlay planes. Details recorded in this FDO bug: > https://bugs.freedesktop.org/show_bug.cgi?id=104975. > > The issue has been root caused as a race where only partial register updates > get latched on the next vblank, specifically, the updates that give the > buffer allocation of the current plane before disabling it (again, details > captured in the FDO bug above). There have been several optimizations to work > around this bug: > > 1. Enable Isochronous priority control (IPC) > > 2. Increase the vblank evasion time to 250 usec (We have tried 500 usec > but that doesn't helps). > > 3. Disable DOUBLE_BUFFER_CTL while the updates are done, inside > intel_pipe_update_start and intel_pipe_update_end (doesn't helps) > > 4. Grab all the required locks before starting the pipe_update. > > Per Ville, none of the above optimizations guarantee a *full* update before > the vblank. As a result, to fix this issue the right way, the plane > programming sequence needs to be altered in the driver as mentioned below: > > "Buffer allocation overlap among enabled planes will cause a full frame > underrun, and that becomes a hard hange if pkgC or SAGV are enabled. > You need to make sure the plane is disabled before reallocating the buffer it > uses. For a single pipe it is sufficient to initiate the disabling of the > plane before the reallocation. For multiple pipes it can be more complex. > In this case you should be doing something like this to ensure plane 2A turns > off before plane 1A steals the buffer > > > 1. PLANE_CTL_2A -> disabled > > 2. PLANE_SURF_2A: touch to arm double buffer update > > 3. PLANE_BUF_CFG_1A -> (0-860) > > 4. PLANE_SURF_1A: touch to arm double buffer update > If the planes are on different pipes there needs to be a wait for vblank > between step 2 and 3 to ensure the plane 2A disable completed." > > > Please comment as required. > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
