[Intel-gfx] [PATCH 7/9] drm/i915: adjust has_pending_fb_unpin to atomic
Chris Wilson
chris at chris-wilson.co.uk
Wed Jul 19 14:08:35 UTC 2017
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 at linux.intel.com>
> > > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> >
> > 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
More information about the dri-devel
mailing list