drm/radeon/kms: increase lockup detection interval to 10 sec for r100…

…-r500

One subtest of mesa/demos/gltestperf takes 9 seconds to complete,
so to prevent an unnecessary gpu reset followed by a hardlock, I am
increasing the interval to 10 seconds after which a GPU is considered
in a locked-up state. This is on RV530. However, with a little slower GPU,
we would surpass the interval easily, so this is not a good fix
for gltestperf.

Nevertheless, this commit also fixes hardlocks in the applications which
render at speed of less than 1 frame per second, where the whole frame
consists of only one command stream. The game Tiny & Big is an example.
This bar is now lowered to 0.1 fps.

Now the question comes down to whether we should (often unsuccessfully)
reset the GPU at all? Once we have stable enough drivers, we won't have to.
Has the time come already?

If possible, this commit should go to stable as well.

Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drivers/gpu/drm/radeon/r100.c

@@ -2020,18 +2020,7 @@ bool r100_gpu_cp_is_lockup(struct radeon_device *rdev, struct r100_gpu_lockup *l
 		return false;
 	}
 	elapsed = jiffies_to_msecs(cjiffies - lockup->last_jiffies);
-	if (elapsed >= 3000) {
-		/* very likely the improbable case where current
-		 * rptr is equal to last recorded, a while ago, rptr
-		 * this is more likely a false positive update tracking
-		 * information which should force us to be recall at
-		 * latter point
-		 */
-		lockup->last_cp_rptr = cp->rptr;
-		lockup->last_jiffies = jiffies;
-		return false;
-	}
-	if (elapsed >= 1000) {
+	if (elapsed >= 10000) {
 		dev_err(rdev->dev, "GPU lockup CP stall for more than %lumsec\n", elapsed);
 		return true;
 	}