On Wed, 2014-12-03 at 10:22 +0100, Daniel Vetter 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.
> >
> > 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.
There was at least this attempt:
https://lkml.org/lkml/2013/5/10/187
--Imre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
