Message ID | 1427982700-24901-1-git-send-email-deepak.s@linux.intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Thu, Apr 02, 2015 at 07:21:40PM +0530, deepak.s@linux.intel.com wrote: > From: Deepak S <deepak.s@linux.intel.com> > > 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. 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
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 6036e3b..2c6ebce 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -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; \