From: Reinhard Meyer <u-boot@emk-elektronik.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] ARM timing code refactoring
Date: Mon, 24 Jan 2011 08:50:12 +0100 [thread overview]
Message-ID: <4D3D2F34.6020903@emk-elektronik.de> (raw)
In-Reply-To: <4D3D2942.4060600@free.fr>
Dear all,
its quite funny to see how we go around in circles here, this proposal of Albert
now is quite close to my original proposal. Only that I factored the ms_to_ticks
AND the comparison into the timer calls:
u64 timer_setup(u32 timeout_in_ms)
{
return get_ticks() + ms_to_ticks(timeout_in_ms);
}
int timer_expired(u64 endtime)
{
/*
* convert the unsigned difference to signed, to easyly
* check for "carry". In assembly we could just do a BCC
* after the subtraction to see whether get_ticks()
* has passed ahead of endtime.
*/
return (signed)(endtime - get_ticks()) < 0;
}
What can be more pragmatic and trivial than those two functions??
Usage then:
/* let's wait 200 milliseconds */
u64 endtime = timer_setup(200);
do {
...
} while (!timer_expired(endtime));
> That's where I come back to one point of my proposal: if we can get a
> general framework for get_timer() to return a 64-bit free-running tick
We have that already at least on PowerPC and AT91. Its called u64 get_ticks(void)
and returns a free running 64 bit value. An associated function,
u64 get_tbclk(void) returns the frequency of that tick.
I don't think that this part of the framework needs to be discussed -
except *maybe* for function names.
> value, then we might not need a ms-based get_time() at all, because we
> could use get_timer() as well for ms timings, provided we can convert
> our timeout from ms to ticks, i.e.
>
> /* let's wait 200 milliseconds */
> /* Timing loop uses ticks: convert 200 ms to 'timeout' ticks */
> timeout = ms_to_ticks(200);
> u32 start = get_timer(); /* start time, in ticks */
> do {
> ...
> } while ( (get_timer() -start) < timeout);
Mandatory u64 for start AND timeout, please.
It is the same functionality as my proposal, just bears more places where
"users" might make mistakes.
But I am sure that Wolfgang will not like either of our proposals, because
the variables used in "userspace" are not in ms.
Reinhard
next prev parent reply other threads:[~2011-01-24 7:50 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-22 10:20 [U-Boot] [RFC] ARM timing code refactoring Albert ARIBAUD
2011-01-22 10:42 ` Reinhard Meyer
2011-01-22 11:32 ` Albert ARIBAUD
2011-01-22 11:00 ` [U-Boot] [RFC] U-boot (was: ARM) " Reinhard Meyer
2011-01-22 12:22 ` [U-Boot] [RFC] U-boot Albert ARIBAUD
2011-01-22 19:19 ` [U-Boot] [RFC] ARM timing code refactoring Wolfgang Denk
2011-01-22 20:17 ` Albert ARIBAUD
2011-01-22 21:26 ` Wolfgang Denk
2011-01-22 21:51 ` Reinhard Meyer
2011-01-23 10:12 ` Wolfgang Denk
2011-01-23 10:26 ` Reinhard Meyer
2011-01-23 16:23 ` Wolfgang Denk
2011-01-23 18:47 ` Reinhard Meyer
2011-01-23 19:35 ` Wolfgang Denk
2011-01-23 20:59 ` Albert ARIBAUD
2011-01-23 21:22 ` Reinhard Meyer
2011-01-23 22:01 ` Reinhard Meyer
2011-01-23 22:57 ` Wolfgang Denk
2011-01-24 1:42 ` J. William Campbell
2011-01-24 7:24 ` Albert ARIBAUD
2011-01-24 7:50 ` Reinhard Meyer [this message]
2011-01-24 12:59 ` Wolfgang Denk
2011-01-24 8:25 ` Andreas Bießmann
2011-01-24 11:58 ` Albert ARIBAUD
2011-01-24 12:06 ` Albert ARIBAUD
2011-01-24 12:58 ` Andreas Bießmann
2011-01-24 12:54 ` Wolfgang Denk
2011-01-24 13:02 ` Wolfgang Denk
2011-01-24 16:23 ` J. William Campbell
2011-01-22 22:13 ` Albert ARIBAUD
2011-01-23 16:15 ` 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=4D3D2F34.6020903@emk-elektronik.de \
--to=u-boot@emk-elektronik.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.