drm/i915: _wait_for might be called when irq is off

From: Deepak S <[email protected]>

Sometimes, i915 might call _wait_for when irq is disabled. If the cpu is the main cpu to process jiffies, jiffies wouldn't be increased as this cpu disables irq. Then, time_after(jiffies, timeout__) becomes meaningless. If gunit doesn't work now, kernel wouldn't exit as the timeout doesn't work.

The patch fixes it by using sched_clock instead of jiffies.

---
 drivers/gpu/drm/i915/intel_drv.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

index 6036e3b..2c6ebce 100644
@@ -49,10 +49,12 @@
  * we've never had a chance to check the condition before the timeout.
  */
 #define _wait_for(COND, MS, W) ({ \
-	unsigned long timeout__ = jiffies + msecs_to_jiffies(MS) + 1;	\
+	u64 timeout_ = sched_clock() + MS * ((u64) NSEC_PER_MSEC);	\
+	u64 clock;							\
 	int ret__ = 0;							\
 	while (!(COND)) {						\
-		if (time_after(jiffies, timeout__)) {			\
+		clock = sched_clock();					\
+		if (clock >= timeout_) {				\
 			if (!(COND))					\
 				ret__ = -ETIMEDOUT;			\
 			break;						\

1.9.1

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

sched_clock() requires irq disabled, or at least so the header claims, at the very least it would require preemption disabled - definitely not for our general waits of many ms. Also local_clock() would seem to be the right choice in these tight loops.

I think you want a specialised macro (if any) that is very aware of the constraints it is running under. I would hope we never have to busy spin with interrupts disabled. And so I want such code that does to blatantly obvious and scrutinised carefully.
-Chris

Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx