[Intel-gfx] [PATCH] drm/i915: Drop the msleep parameter to wait_for()

Chris Wilson chris at chris-wilson.co.uk
Tue Aug 24 01:33:18 CEST 2010


On Tue, 24 Aug 2010 00:16:37 +0100, Peter Clifton <pcjc2 at cam.ac.uk> wrote:
> I noticed that the patch changes the semantics of some of the wait_for
> calls. Previously, many were called with a zero msleep parameter -
> meaning the call would not msleep. With this patch, the cases below will
> now msleep(1), rather than not msleep'ing at all.

Intentionally. The choices I made when adding the wait_for() were fairly
arbitrary. I'd err on the side of sleeping the extra milliseconds rather
than spend 500 microseconds busy-spinning. (I've have a different opinion
if these ever become the rate-limiting step in modesetting... ;-)

> >  	/* Wait for compressing bit to clear */
> > -	if (wait_for((I915_READ(FBC_STATUS) & FBC_STAT_COMPRESSING) == 0, 10, 0)) {
> > +	if (wait_for((I915_READ(FBC_STATUS) & FBC_STAT_COMPRESSING) == 0, 10)) {
>                 ^___ wait_for_atomic?

This is perhaps the most debatable as I have no feel for what the
compression delay is and the spin may only be on the order of a few
hundred microseconds. However, I think the wait_for() here is entirely
superfluous and have removed it in my drm-testing.

A couple of the later patches increase those short timeouts you
highlighted to fix reported issues, so those are poor candidates for
busy-spinning. So outside of kdb, I don't see a reason where we need to be
continuously polling the register.

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list