Messages in this thread | | | From | Tvrtko Ursulin <> | Subject | Re: udelay minimum delay guarantee and maximum supported delay? | Date | Fri, 9 Mar 2012 15:21:50 +0000 |
| |
[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
| |