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

Zhenyu Wang zhenyuw at linux.intel.com
Thu Nov 26 02:08:52 CET 2009


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.

And user space will try to turn on DPMS unconditionally, which might put
display engine in unknown state, well that's a different point of failure.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20091126/bfb2cb98/attachment.sig>


More information about the Intel-gfx mailing list