From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly.
Date: Fri, 27 Jan 2017 15:21:29 +0100 [thread overview]
Message-ID: <20170127142129.cgdoelv6oeqeu6r3@phenom.ffwll.local> (raw)
In-Reply-To: <20170127093050.GK19521@nuc-i3427.alporthouse.com>
On Fri, Jan 27, 2017 at 09:30:50AM +0000, Chris Wilson wrote:
> On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote:
> > When writing some testcases for nonblocking modesets. I found out that the
> > infinite wait on the old fb was causing issues.
>
> The crux of the issue here is the locked wait for old dependencies and
> the inability to inject the intel_prepare_reset disabling of all planes.
> There are a couple of locked waits on struct_mutex within the modeset
> locks for intel_overlay and if we happen to be using the display plane
> for the first time.
>
> The first I suggested solving using fences to track dependencies and
> keep the order between atomic states. Cancelling the outstanding
> modesets, replacing with a disable and then on restore jumping to the
> final state look doable. It also requires avoiding the struct_mutex for
> disabling, which is quite easy. To avoid the wait under struct_mutex,
> we've talked about switching to mmio, but for starters we could move the
> wait from inside intel_overlay into the fence for the atomic operation.
> (But's that a little more surgery than we would like for intel_overlay I
> guess - dig out Ville's patches for overlay planes?) And to prevent the
> wait under struct_mutex for pin_to_display_plane, my plane is to move
> that to an async fenced operation that is then naturally waited upon by
> the atomic modeset.
A bit more a hack, but a different idea, and I think hack for gen234.0 is
ok:
We complete all the requests before we start the hw reset with fence.error
= -EIO. But we do this only when we need to get at the display locks. A
slightly more elegant solution would be to trylock modeset locks, and if
one of them fails (and only then) complete all requests with -EIO to get
the concurrent modeset to proceed before we reset the hardware. That's
essentially the logic we had before all the reworks, and it worked. But I
didn't look at how scary that all would be to make it work again ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-01-27 14:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-26 15:59 [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly Maarten Lankhorst
2017-01-26 15:59 ` [PATCH 1/3] drm/atomic: Bump timeout for waiting for hw_done to 90s in swap_state Maarten Lankhorst
2017-01-26 15:59 ` [PATCH 2/3] drm/i915: Set a timeout when waiting for fence on the old fb Maarten Lankhorst
2017-01-26 15:59 ` [PATCH 3/3] drm/i915: Skip modeset locking when atomic pageflips are used Maarten Lankhorst
2017-01-26 16:39 ` [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly Ville Syrjälä
2017-01-27 9:30 ` [Intel-gfx] " Chris Wilson
2017-01-27 14:21 ` Daniel Vetter [this message]
2017-01-27 14:31 ` Chris Wilson
2017-01-27 14:58 ` [Intel-gfx] " Daniel Vetter
2017-01-27 15:08 ` Chris Wilson
2017-01-30 8:17 ` Daniel Vetter
2017-01-30 14:42 ` Maarten Lankhorst
2017-01-31 7:46 ` [Intel-gfx] " Daniel Vetter
2017-01-31 9:11 ` Maarten Lankhorst
2017-01-30 15:25 ` [PATCH] drm/i915: Skip modeset locking when atomic pageflips are used Maarten Lankhorst
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170127142129.cgdoelv6oeqeu6r3@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.