[Intel-gfx] [PATCH 3/3] drm/i915: Don't wait interruptible for possible plane buffer flush

Jesse Barnes jbarnes at virtuousgeek.org
Mon Nov 30 21:59:30 CET 2009


On Thu, 26 Nov 2009 09:08:52 +0800
Zhenyu Wang <zhenyuw at linux.intel.com> wrote:

> On 2009.11.25 12:16:33 -0800, Eric Anholt wrote:
> > On Wed, 25 Nov 2009 13:09:39 +0800, Zhenyu Wang
> > <zhenyuw at linux.intel.com> wrote:
> > > When we setup buffer for display plane, we'll check any pending
> > > required GPU flush and possible make interruptible wait for flush
> > > complete. But that wait would be most possibly to fail in case of
> > > signals received for X process, which will then fail modeset
> > > process and put display engine in unconsistent state. The result
> > > could be blank screen or CPU hang, and DDX driver would always
> > > turn on outputs DPMS after whatever modeset fails or not.
> > > 
> > > So this one creates new helper for setup display plane buffer, and
> > > when needing flush using uninterruptible wait for that.
> > 
> > Can you explain why the modeset process is special and shouldn't be
> > interruptible?  It certainly seems to me like it should be
> > interruptible like other driver commands are.
> 
> If wait is interrupted by something else, it will abort plane setup
> and mode_set function, within that we've already done new DPLL
> setting and other stuff. Failure in mode_set also won't proceed on
> real pipe setup later in commit function, so we're stopped in the
> middle of the timing sensitive modesetting process. Normally no plane
> enabled means blank screen like for bug 24009.

It's a nasty bug, thanks for catching it.  We can either make our GTT
transition uninterruptible (what you've done), or we can make the
failure paths of the mode setting core a bit more robust against
signals.  Have you looked at what it would take to do the latter?  It
might be good to do anyway, since even with an uninterruptible flush we
might fail (or timeout, do we do that?) and so would need to unwind any
previous programming...

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center



More information about the Intel-gfx mailing list