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). Thanks for these, all now queued up. greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html