Re: [Intel-gfx] [PATCH] drm/i915: compute wait_ioctl timeout correctly

From: Daniel Vetter
Date: Wed Dec 03 2014 - 04:21:55 EST


On Tue, Dec 02, 2014 at 08:54:13AM -0800, John Stultz wrote:
> On Tue, Dec 2, 2014 at 8:35 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> > On Tue, Dec 02, 2014 at 04:36:22PM +0100, Daniel Vetter wrote:
> >> +static inline unsigned long nsecs_to_jiffies_timeout(const u64 m)
> >> +{
> >> + u64 usecs = div_u64(m + 999, 1000);
> >> + unsigned long j = usecs_to_jiffies(usecs);
> >> +
> >> + return min_t(unsigned long, MAX_JIFFY_OFFSET, j + 1);
> >
> > Or more concisely and review friendly:
> >
> > static inline unsigned long nsecs_to_jiffies_timeout(const u64 n)
> > {
> > return min_t(u64, MAX_JIFFY_OFFSET, nsecs_to_jiffies64(n) + 1);
> > }
>
> Yea. This looks much nicer. Seems generic enough it might be better
> added next to nsec_to_jiffies64() in kernel/time/time.c or jiffies.h
> rather then in a driver header.
>
> And clearly the header comment in nsec_to_jiffies() warning its only
> for the scheduler and not for use for drivers (for exactly the reason
> of this patch) are not obvious/memorable enough for me and Thomas
> makes me wonder if we should change its name to be more clear that its
> a sched only function.

This bug here isn't about nsect_to_jiffies vs the 64 bit variant, but
about the +1 that we need to not have a short sleep. In i915 we have a
bunch of jiffies_timeout functions which do just the +1 compared to the
versions in time.c because we screwed this up too often.

Iirc I did float an rfc to move these to time.c once but it resulted in
some bikeshed fest (no, I'm not going to audit every single user of
existing _to_jiffies functions). If there's interest I could try again,
the i915 versions are in drivers/gpu/drm/i915/i915_drv.h.

Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/