Re: [PATCH] drm/i915: Put all non-blocking modesets onto an ordered wq

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Put all non-blocking modesets onto an ordered wq
Date: Tue, 21 Nov 2017 16:42:10 +0200	[thread overview]
Message-ID: <20171121144210.GC10981@intel.com> (raw)
In-Reply-To: <20171113144408.GO10981@intel.com>

On Mon, Nov 13, 2017 at 04:44:08PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 13, 2017 at 03:36:58PM +0100, Maarten Lankhorst wrote:
> > Op 13-11-17 om 14:36 schreef Ville Syrjala:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > We have plenty of global registers and whatnot programmed without
> > > any further locking by the modeset code. Currently non-bocking
> > > modesets are allowed to execute in parallel which could corrupt
> > > said registers.
> > >
> > > To avoid the problem let's run all non-blocking modesets on an
> > > ordered workqueue. We still put page flips etc. to system_unbound_wq
> > > allowing page flips on one pipe to execute in parallel with page flips
> > > or a modeset on a another pipe (assuming no known state is shared
> > > between them, at which point they would have been added to the same
> > > atomic commit and serialized that way).
> > >
> > > Blocking modesets are already serialized with each other by
> > > connection_mutex, and thus are safe. To serialize them with
> > > non-blocking modesets we just flush the workqueue before executing
> > > blocking modesets.
> > >
> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > Fixes: 94f050246b42 ("drm/i915: nonblocking commit")
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > This patch won't really fix it, you could still have a blocking modeset in parallel to a nonblocking one.
> 
> Hence the flush_workqueue().
> 
> > What would really be needed to fix those instances here?
> 
> Someone needs to review the entire modeset code and come up with a fix
> for all the cases where we are frobbing some global state.

So what do we want to do here?

1) someone volunteering to find all the broken code and fix it?
2) go with my ordered wq?
3) someone want to come up with some kind of modeset mutex?
4) revert nonblocking modesets?

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx