On Fri, 2018-06-29 at 16:26 -0700, Dhinakaran Pandiyan wrote: > On Wed, 2018-06-27 at 13:02 -0700, Tarun Vyas wrote: > > > > The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, > > then > > the pipe_update_start call schedules itself out to check back > > later. > > > > On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 > > but > > lags w.r.t core kernel code, hot plugging an external display > > triggers > > tons of "potential atomic update errors" in the dmesg, on *pipe A*. > > A > > closer analysis reveals that we try to read the scanline 3 times > > and > > eventually timeout, b/c PSR hasn't exited fully leading to a > > PIPEDSL > > stuck @ 1599. This issue is not seen on upstream kernels, b/c for > > *some* > > reason we loop inside intel_pipe_update start for ~2+ msec which in > > this > > case is more than enough to exit PSR fully, hence an *unstuck* > > PIPEDSL > > counter, hence no error. On the other hand, the ChromeOS kernel > > spends > > ~1.1 msec looping inside intel_pipe_update_start and hence errors > > out > > b/c the source is still in PSR. > > > > Regardless, we should wait for PSR exit (if PSR is disabled, we > > incur > > a ~1-2 usec penalty) before reading the PIPEDSL, b/c if we haven't > > fully exited PSR, then checking for vblank evasion isn't actually > > applicable. > > > > v4: Comment explaining psr_wait after enabling VBL interrupts (DK) > > > > v5: CAN_PSR() to handle platforms that don't support PSR. > > > > v6: Handle local_irq_disable on early return (Chris) > > Series Reviewed-by: Dhinakaran Pandiyan > <dhinakaran.pandiyan@xxxxxxxxx> > > Daniel's questions were addressed over IRC, I'll push this version if > they aren't any other concerns. and pushed to -dinq with Daniel's irc ack. "<dhnkrn> ickle: danvet ack on the PSR wait_for_idle series? <danvet> sure" _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
