Quoting Daniel Vetter (2017-07-19 14:15:44) > On Wed, Jul 19, 2017 at 02:06:43PM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-07-19 13:55:00) > > > A bit an oversight - the current code did nothing, since only > > > legacy flips used the unpin_work_count and assorted logic. > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > > > Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > > There's a fence deadlock testcase for this, kms_flip/fence? > > Crunching through them, but since I tend to test my stuff all mixed into > one pile I've hit a bug in a different patch series of mine. Given that > we've run without this for a while, not sure it's that critical really. It's only going to affect gen2 (realistically using 14 fences in a gen3 batch is unlikely) if we can have 3 fb in the pipeline as userspace assumes 2 are reserved for the flip. Or at least if we may race while fb holds 3 fences due to the wq. EDEADLK is not something I've seen outside of buggy code, but it is certainly possible and this patch should fix it. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
