From: Graeme Russ <graeme.russ@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] Review of U-Boot timer API
Date: Sun, 22 May 2011 10:06:13 +1000 [thread overview]
Message-ID: <4DD85375.6080502@gmail.com> (raw)
In-Reply-To: <4DD7DB64.70605@comcast.net>
On 22/05/11 01:33, J. William Campbell wrote:
> On 5/21/2011 5:38 AM, Graeme Russ wrote:
>> Hi All,
>> 4. Implement microsecond API - get_usec_timer()
>> -----------------------------------------------
>> - Useful for profiling
>> - A 32-bit microsecond counter wraps in 71 minutes - Probably OK for most
>> U-Boot usage scenarios
>> - By default could return get_timer() * 1000 if hardware does not support
>> microsecond accuracy - Beware of results> 32 bits!
> Hi All,
> I think the multiply overflowing an unsigned long is ok here as long
> as the timeout value you desire is less than 71 seconds. This assumes that
> the CPU returns the correct lower 32 bits when overflow occurs, but I think
> this is the "normal" behavior(?)
I think you mean 71 minutes - 2^32 = 4294967296 (usec) = 4294967.296 (msec)
= 4294.967296 s = 71.582788267 minutes
So provided any millisecond timer using a 32-bit microsecond timer as a
time base is called every 71 minutes, a 32-bit microsecond timer should
suffice to keep the msb's accurately maintained by software
>> - If hardware supports microsecond resolution counters, get_timer() could
>> simply use get_usec_timer() / 1000
> I think this actually is NOT equivalent to the "current" API in
> that the full 32 bits of the timer is not available and as a result the
> "wrapping" properties of a 32 bit subtract for delta times will not work
> properly. If a "larger" counter is available in hardware, then it is
> certainly possible to do a 64 by 32 bit divide in get_timer, but probably
> you don't want to do that either. As previously discussed, it is possible
> to extract a 32 bit monotonic counter of given resolution (microsecond or
> millisecond resolution) from a higher resolution counter using a shift to
> "approximately" the desired resolution followed by a couple of multiply/add
> functions of 32 bit resolution. To do this with a microsecond resolution,
> a 42 bit or larger timer is required. The "extra" bits can be provided in
Of course, how silly of me - To downscale the microsecond timer down to
milliseconds you need to have at least 1000 times more resolution
(9.965784285 bits) - It was late ;)
> software as long as the get_timer/get_usec_timer routines are called more
> often than every 71/2 sec, so that a correct delta in microseconds can be
> obtained. Note that when the timer is not actively in use (not called
> often enough), the millisecond timer msb would stop updating, but that
> wouldn't matter.
Minutes - see above
> If the hardware supports sub-microsecond accuracy in a "longer"
> register, say 64 bits, you can just convert the 64 bit hardware timer to 32
> bit microseconds or milliseconds by a shift and 32 bit multiplies
Yes
>
> Good luck with this effort. I think getting the timer API and also
> the method of implementation of the interface to the hardware to be the
> same across all u-boot architectures is a very good idea, and it is
> possible. However, it is a quite a bit of work and I am glad you are brave
> enough to try!
It's all there already - it just needs a little bit of housekeeping :)
Regards,
Graeme
next prev parent reply other threads:[~2011-05-22 0:06 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-21 12:38 [U-Boot] [RFC] Review of U-Boot timer API Graeme Russ
[not found] ` <4DD7DB64.70605@comcast.net>
2011-05-22 0:06 ` Graeme Russ [this message]
2011-05-22 0:43 ` J. William Campbell
2011-05-22 4:26 ` Reinhard Meyer
2011-05-22 6:23 ` Graeme Russ
2011-05-22 7:21 ` J. William Campbell
2011-05-22 7:44 ` Graeme Russ
2011-05-22 8:15 ` Reinhard Meyer
2011-05-23 0:02 ` Graeme Russ
2011-05-23 0:20 ` J. William Campbell
2011-05-23 0:14 ` J. William Campbell
2011-05-23 1:00 ` Graeme Russ
[not found] ` <4DD9B608.7080307@comcast.net>
2011-05-23 1:42 ` Graeme Russ
2011-05-23 5:02 ` J. William Campbell
2011-05-23 5:25 ` Graeme Russ
2011-05-23 6:29 ` Albert ARIBAUD
2011-05-23 10:53 ` Graeme Russ
2011-05-23 16:22 ` J. William Campbell
2011-05-23 12:09 ` Wolfgang Denk
2011-05-23 12:29 ` Graeme Russ
2011-05-23 13:19 ` Wolfgang Denk
2011-05-23 17:30 ` J. William Campbell
2011-05-23 18:24 ` Albert ARIBAUD
2011-05-23 19:18 ` Wolfgang Denk
2011-05-23 18:27 ` J. William Campbell
2011-05-23 19:33 ` Wolfgang Denk
2011-05-23 20:26 ` J. William Campbell
2011-05-23 21:51 ` Wolfgang Denk
2011-05-23 20:48 ` Graeme Russ
2011-05-23 3:26 ` Reinhard Meyer
2011-05-23 5:20 ` J. William Campbell
2011-05-22 6:57 ` J. William Campbell
2011-05-23 12:13 ` Wolfgang Denk
2011-05-24 3:42 ` Mike Frysinger
2011-05-24 4:07 ` Graeme Russ
2011-05-24 4:24 ` Mike Frysinger
2011-05-24 4:35 ` Graeme Russ
2011-05-24 5:31 ` Reinhard Meyer
2011-05-24 5:43 ` Graeme Russ
2011-05-24 6:11 ` Albert ARIBAUD
2011-05-24 7:10 ` Graeme Russ
2011-05-24 14:15 ` Wolfgang Denk
2011-05-24 14:12 ` Wolfgang Denk
2011-05-24 15:23 ` J. William Campbell
2011-05-24 19:09 ` Wolfgang Denk
2011-05-24 13:29 ` Scott McNutt
2011-05-24 14:19 ` Wolfgang Denk
2011-05-24 16:51 ` Graeme Russ
2011-05-24 18:59 ` J. William Campbell
2011-05-24 19:31 ` Wolfgang Denk
2011-05-24 19:19 ` Wolfgang Denk
2011-05-24 22:32 ` J. William Campbell
2011-05-25 5:17 ` Wolfgang Denk
2011-05-25 16:50 ` J. William Campbell
2011-05-25 19:56 ` Wolfgang Denk
2011-05-25 0:17 ` Graeme Russ
2011-05-25 2:53 ` J. William Campbell
2011-05-25 3:21 ` Graeme Russ
2011-05-25 5:28 ` Wolfgang Denk
2011-05-25 6:06 ` Graeme Russ
2011-05-25 8:08 ` Wolfgang Denk
2011-05-25 8:38 ` Graeme Russ
2011-05-25 11:37 ` Wolfgang Denk
2011-05-25 11:52 ` Graeme Russ
2011-05-25 12:26 ` Wolfgang Denk
2011-05-25 12:42 ` Graeme Russ
2011-05-25 12:59 ` Wolfgang Denk
2011-05-25 13:14 ` Graeme Russ
2011-05-25 13:38 ` Wolfgang Denk
2011-05-25 21:11 ` Graeme Russ
2011-05-25 21:16 ` Wolfgang Denk
2011-05-25 23:13 ` Graeme Russ
2011-05-26 0:15 ` J. William Campbell
2011-05-26 0:33 ` Graeme Russ
2011-05-26 4:19 ` Reinhard Meyer
2011-05-26 4:40 ` Graeme Russ
2011-05-26 5:03 ` J. William Campbell
2011-05-26 5:16 ` Wolfgang Denk
2011-05-26 5:25 ` Graeme Russ
2011-05-26 5:55 ` Albert ARIBAUD
2011-05-26 6:18 ` Graeme Russ
2011-05-26 6:36 ` Reinhard Meyer
2011-05-26 8:48 ` Wolfgang Denk
2011-05-26 9:02 ` Graeme Russ
2011-05-26 4:54 ` J. William Campbell
2011-05-25 5:25 ` Wolfgang Denk
2011-05-25 6:02 ` Graeme Russ
2011-05-25 8:06 ` Wolfgang Denk
2011-05-25 8:26 ` Graeme Russ
2011-05-25 11:32 ` Wolfgang Denk
2011-05-25 11:53 ` Graeme Russ
2011-05-25 12:27 ` Wolfgang Denk
2011-05-25 12:36 ` Scott McNutt
2011-05-25 12:43 ` Graeme Russ
2011-05-25 13:08 ` Scott McNutt
2011-05-25 13:16 ` Graeme Russ
2011-05-25 13:46 ` Scott McNutt
2011-05-25 14:21 ` Graeme Russ
2011-05-25 19:46 ` Wolfgang Denk
2011-05-25 20:40 ` J. William Campbell
2011-05-25 20:48 ` Wolfgang Denk
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=4DD85375.6080502@gmail.com \
--to=graeme.russ@gmail.com \
--cc=u-boot@lists.denx.de \
/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