On Wed, Oct 26, 2016 at 03:36:32PM -0400, Lyude wrote: > Now that these have finally made it into 4.9, it's time to finally backport > these fixes. Skylake has been a mess in multi-monitor setups for a while now > because up until recently we've been updating the watermarks on Skylake just > like we would for previous generations of Intel GPUs. This means updating > attributes for each plane, and then only after they've been updated writing > their new watermark values. > > The problem with this approach is Skylake has double buffered watermark > registers that are flipped at the same time as the rest of the plane registers. > This means that the original approach will leave planes active with new > attributes but without the required watermark programming that would ensure the > display pipe reads enough data from each plane. As a result, pipes start to > underrun and the user's displays starts to flicker heavily. Usually in response > to plugging in new monitors, or moving cursors from one screen to another > (which triggers a plane and watermark update). > > Additionally, issues were found with the original code for configuring ddb, > display data buffer, allocations between display planes on Skylake. On Skylake > all planes have space allocated to them in the ddb, and the hardware requires > that these allocations never overlap at any point in time. Because ddb > allocations were not updated alongside plane attributes despite also being > double buffered registers armed by plane updates, planes were likely to get > stuck momentarily with ddb allocations that overlapped one another. This would > also lead to pipe underruns and display flickering. > > The new approach fixes this problem by making sure that on Skylake, attributes > for display planes are always updated at the same time as the watermarks, and > pipes are updated in an order that ensures their ddb allocations don't > overlap at any point between plane updates. This ensures the display pipes are > always programmed correctly, and dramatically reduces the chance of display > flickering. > > (note: my e-mail has changed since these patches were upstreamed, and I updated > the e-mails in these patches to reflect this. if this is wrong I will be happy > to update and resend the patches). > > Lyude (4): > drm/i915/skl: Update plane watermarks atomically during plane updates > drm/i915: Move CRTC updating in atomic_commit into it's own hook > drm/i915/skl: Update DDB values atomically with wms/plane attrs > drm/i915/skl: Don't try to update plane watermarks if they haven't > changed > > Paulo Zanoni (1): > drm/i915/gen9: only add the planes actually affected by ddb changes fwiw ack from my side. -Daniel > > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 189 +++++++++++++++++++----- > drivers/gpu/drm/i915/intel_drv.h | 12 ++ > drivers/gpu/drm/i915/intel_pm.c | 271 ++++++++++++++--------------------- > drivers/gpu/drm/i915/intel_sprite.c | 14 ++ > 5 files changed, 289 insertions(+), 199 deletions(-) > > -- > 2.7.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
