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

[Daniel Vetter]

On Wed, Dec 03, 2014 at 11:07:08AM -0800, John Stultz wrote:
> On Wed, Dec 3, 2014 at 6:30 AM, Daniel Vetter <daniel@xxxxxxxx> wrote:
> > 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.
> >
> > Ok, that needs an EXPORT_SYMBOL for nsecs_to_jiffies64. Can I count your
> > "Yea" above as an ack for adding that and pulling it in through
> > drm-intel.git?
> 
> Do you need an EXPORT_SYMBOL if you add the _timeout version next to
> nsecs_to_jiffies64 in time.c?

I wouldn't but the patch from Imre to add all the _timeout was killed with
a few bikesheds so really not volunteering. And just moving this single
one doesn't make a lot of sense imo. Also the next patch I'll do is just
add the +1 that we lost to the code and call it a day, really ;-)

> Otherwise no objections to the approach, but I'd like to properly do
> an Acked-by: after I see the patch. :)

I'll send it out.
-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/