lkml.org 
[lkml]   [2012]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: udelay minimum delay guarantee and maximum supported delay?
Date

[Adding some people to the CC list, courtesy of get_maintainer.pl -f
arch/x86/lib/delay.c, if you consider that a good file choice for this.]

On Friday 09 Mar 2012 14:37:50 Tvrtko Ursulin wrote:
> Hi all,
>
> I was debugging some weird driver behaviour under 3.3.0-rc6+ (amd64) and
> eventually I got to discovering udelay's driver is issuing are occasionally
> short. That results in random hardware behaviour, but that is beside the
> point.
>
> Driver in question wants to delay for 500us at a time, which is not a
> terribly nice thing to do, but putting that aside and talking more in
> general I would have three questions:
>
> 1. Are 500us udelays supposed to work? (I know they are not recommended and
> I'll fix that.)
> 2. Should udelay guarantee it won't delay by less than the time asked?
> 3. Is ktime_get() considered accurate enough to measure how long udelay
> actually delayed? (Empirical evidence suggests it is, because hardware
> weirdness correlates perfectly with occurences of these short udelays.)
>
> If answers to all are yes then we might have a bug here.
>
> Because I am seeing udelay(500) (_occasionally_) being short, and that by
> delaying for some duration between 0us (yep) and 491us.
>
> As far as I can see this box is using TSC delay and CPU (Intel(R) Core(TM)
> i5-2400S CPU @ 2.50GH) exposes the constant_tsc flag:
>
> [ 1.717050] Refined TSC clocksource calibration: 2494.334 MHz.
> [ 1.717054] Switching to clocksource tsc
>
> Am I missing something and what are your opinions?
>
> Thanks,
>
> Tvrtko


\
 
 \ /
  Last update: 2012-03-09 16:25    [W:0.178 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site