lkml.org 
[lkml]   [2005]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [DVB patch 51/54] ttpci: av7110: RC5+ remote control support
On Sun, Sep 04, 2005 Nish Aravamudan wrote:
> On 9/4/05, Johannes Stezenbach <js@linuxtv.org> wrote:
> > On Sun, Sep 04, 2005 Nish Aravamudan wrote:
> > > On 9/4/05, Johannes Stezenbach <js@linuxtv.org> wrote:
> > > >
> > > > -#define UP_TIMEOUT (HZ/4)
> > > > +#define UP_TIMEOUT (HZ*7/25)
> > >
> > > #define UP_TIMEOUT msecs_to_jiffies(280)
> > > #define UP_TIMEOUT (7*msecs_to_jiffies(40)
> >
> > I agree it's nicer to read, but AFAIK not required for correctness?
> > If so, then we'll fix those up in linuxtv.org CVS and submit
> > cleanup patches later.
>
> Yeah, it's correct with the three current values of HZ (100, 250 and
> 1000), but if you try a not-so-clean value (like Con did with 864, or
> something), you might run into rounding issues. msecs_to_jiffies()
> should take care of them (or will be a single point to do so
> eventually).

Well, if msecs_to_jiffies() is the new way of specifying timeouts
we'd have a lot more to fix up in our tree. But something like
a remote control key-up timeout doesn't need much precision.
Generally I see nothing wrong with HZ/4, but something like
HZ*20/1000 could be problematic with small or odd HZ values.

Agreed? Or is it desired that people generally use msecs_to_jiffies()?

Johannes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-09-05 02:30    [W:0.111 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site