From: Reinhard Meyer <u-boot@emk-elektronik.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 4/4] arm920t/at91/timer: replace bss variables by gd
Date: Tue, 30 Nov 2010 08:17:23 +0100 [thread overview]
Message-ID: <4CF4A503.50104@emk-elektronik.de> (raw)
In-Reply-To: <1291099039-49672-5-git-send-email-andreas.devel@googlemail.com>
Dear Andreas Bie?mann,
> Reuse the gd->tbl/tbu values for timestamp/lastinc bss values in
> arm920t/at91/timer driver.
> The usage of bss values in driver before initialisation of bss is
> forbidden. In that special case some data in .rel.dyn gets corrupted by
> the arm920t/at91/timer driver.
>
> Signed-off-by: Andreas Bie?mann <andreas.devel@googlemail.com>
> ---
> arch/arm/cpu/arm920t/at91/timer.c | 29 ++++++++++++++---------------
> {
> /* reset time */
> at91_tc_t *tc = (at91_tc_t *) AT91_TC_BASE;
> - lastinc = readl(&tc->tc[0].cv) & 0x0000ffff;
> - timestamp = 0;
> + gd->tbl = readl(&tc->tc[0].cv) & 0x0000ffff;
> + gd->tbu = 0;
> }
>
> ulong get_timer_raw(void)
> @@ -109,16 +108,16 @@ ulong get_timer_raw(void)
>
> now = readl(&tc->tc[0].cv) & 0x0000ffff;
>
> - if (now >= lastinc) {
> + if (now >= gd->tbl) {
> /* normal mode */
> - timestamp += now - lastinc;
> + gd->tbu += now - gd->tbl;
> } else {
> /* we have an overflow ... */
> - timestamp += now + TIMER_LOAD_VAL - lastinc;
> + gd->tbu += now + TIMER_LOAD_VAL - gd->tbl;
> }
> - lastinc = now;
> + gd->tbl = now;
>
> - return timestamp;
> + return gd->tbu;
> }
I see your dilemma here.
tbu/tbl were introduced by me to form a true 64 bit monotonous incrementing value
(like on most powerPC).
You use tbl as the last (16 bit) value of the 16 bit hardware timer and
tbu as the actual, only 32 bits worth time value.
If the rest of the timer functions handle this correctly (I doubt that, but I cannot look at
that right now), that "abuse" might be OK.
But I rather have a field, say "u32 last_hw_val" (or a better name) added to the GD inside the
AT91FAMILY define and have tbu/tbl really be a functional 64 bit value.
That would also ease a later unification/factoring of all AT91 timer sources:
A small SoC dependant part that just makes sure tbu/tbl increment with a high frequency,
and a common parts that derives udelay() and get_timer() from that. We should not need any
other functions like *_masked or reset_timer() in the future.
I know there is an endless but not leading anywhere discussion about timers ongoing, but no clean
solution exists right now because of the messed up ways the many different timer functions are used
throughout u-boot.
I would like to reduce it to as few functions as possible...
I am working on a proposal for that, but since that untimately requires to fix *ALL* existing timer
uses I see little change that we will ever get to clean up the mess.
Best Regards,
Reinhard
next prev parent reply other threads:[~2010-11-30 7:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-30 6:37 [U-Boot] [PATCH 0/4] get at91rm9200ek working with ARM relocation Andreas Bießmann
2010-11-30 6:37 ` [U-Boot] [PATCH 1/4] at91rm9200ek: add configure target for RAM boot Andreas Bießmann
2010-11-30 6:37 ` [U-Boot] [PATCH 2/4] MAKEALL: fix AT91 Andreas Bießmann
2010-11-30 6:37 ` [U-Boot] [PATCH 3/4] arm920t: fix linker skript for -pie linking Andreas Bießmann
2010-12-08 22:52 ` Wolfgang Denk
2010-12-09 7:24 ` Andreas Bießmann
2010-12-09 7:33 ` Albert ARIBAUD
2010-12-09 9:45 ` Wolfgang Denk
2010-12-09 10:32 ` Wolfgang Denk
2010-12-09 10:51 ` Andreas Bießmann
2010-11-30 6:37 ` [U-Boot] [PATCH 4/4] arm920t/at91/timer: replace bss variables by gd Andreas Bießmann
2010-11-30 7:17 ` Reinhard Meyer [this message]
2010-11-30 8:03 ` Andreas Bießmann
2010-11-30 8:16 ` Wolfgang Denk
2010-11-30 8:48 ` Andreas Bießmann
2010-11-30 9:14 ` [U-Boot] TIMER cleanup RFC, was: " Reinhard Meyer
2010-11-30 15:11 ` J. William Campbell
2010-11-30 15:48 ` Reinhard Meyer
2010-11-30 17:29 ` J. William Campbell
2010-11-30 18:06 ` [U-Boot] [PATCH 0/4] get at91rm9200ek working with ARM relocation Andreas Bießmann
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=4CF4A503.50104@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox