From: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
To: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: udelay minimum delay guarantee and maximum supported delay?
Date: Fri, 9 Mar 2012 14:37:50 +0000 [thread overview]
Message-ID: <201203091437.50996.tvrtko.ursulin@onelan.co.uk> (raw)
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
next reply other threads:[~2012-03-09 15:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-09 14:37 Tvrtko Ursulin [this message]
2012-03-09 15:21 ` Tvrtko Ursulin
2012-03-09 19:55 ` Thomas Gleixner
2012-03-09 20:11 ` Linus Torvalds
2012-03-09 20:31 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201203091437.50996.tvrtko.ursulin@onelan.co.uk \
--to=tvrtko.ursulin@onelan.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®