| Message ID | 1295600199-3461-1-git-send-email-hs@denx.de |
|---|---|
| State | Accepted |
| Commit | c9ac3ba129b242b5977b03c17ed8d2f0d000e085 |
| Delegated to: | Albert ARIBAUD |
| Headers | show |
Hi Heiko, Le 21/01/2011 09:56, Heiko Schocher a écrit : > Reuse the gd->tbl value for timestamp and add gd->lastinc for lastinc bss > values in the arm926ejs timers implementation. > > The usage of bss values in drivers before initialisation of bss is forbidden. > In that special case some data in .rel.dyn gets corrupted. > > This patch is similiar to the patch Dirk Behme posted > for the armv7/omap-common/timer.c and added suggestions > from Reinhard Meyer. > > Tested on the arm926ejs mx27 based magnesium board > Tested on the arm926ejs kirkwood based suen3 board > > Signed-off-by: Heiko Schocher<hs@denx.de> > cc: Albert ARIBAUD<albert.aribaud@free.fr> > cc: Prafulla Wadaskar<prafulla@marvell.com> > cc: Stefano Babic<sbabic@denx.de> > cc: Reinhard Meyer<u-boot@emk-elektronik.de> Applied to u-boot-arm, thanks. Amicalement,
Hello, Am 21.01.2011 09:56, schrieb Heiko Schocher: > -static ulong timestamp; > -static ulong lastdec; > +DECLARE_GLOBAL_DATA_PTR; > + > +#define timestamp gd->tbl > +#define lastdec gd->lastinc I'm the only one who doesn't like such defines? They might be handy for quick fixes, but in regard to style and readablity I don't like them. When looking at teh code where they will used, you won't see the actual place where they are stored. And in more complex expression they might become dangerous to use because they hide the operator "->". Regards, Alexander
Le 22/01/2011 06:39, Alexander Holler a écrit : > Hello, > > Am 21.01.2011 09:56, schrieb Heiko Schocher: > >> -static ulong timestamp; >> -static ulong lastdec; >> +DECLARE_GLOBAL_DATA_PTR; >> + >> +#define timestamp gd->tbl >> +#define lastdec gd->lastinc > > I'm the only one who doesn't like such defines? They might be handy for > quick fixes, but in regard to style and readablity I don't like them. > When looking at teh code where they will used, you won't see the actual > place where they are stored. And in more complex expression they might > become dangerous to use because they hide the operator "->". I accept the patch because it un-breaks support for ARM cpus, and I prefer a working fix to a perfect fix in this specific, transitional, situation. However a general rework of ARM timer code is in order so that all SoCs and CPUs share the same set of gd variables with the same names and the same logic; and when we get that, this code shall move along. About this rework, as the saying goes... "Patches Welcome ©". :) > Regards, > > Alexander Amicalement,
Dear Albert ARIBAUD, > However a general rework of ARM timer code is in order so that all SoCs > and CPUs share the same set of gd variables with the same names and the > same logic; and when we get that, this code shall move along. > > About this rework, as the saying goes... "Patches Welcome ©". :) There were several suggestions about that in the past (including from me) that involve rework everywhere HZ related timeouts are used. I still prefer a method as follows (because it does not need repeated mul/div calculations nor necessarily 64 bit arithmetic): u32 timeout = timeout_init(100); /* 100ms timeout */ do {...} while (!timed_out(timeout)); Internally it would be like: timeout_init(x): return fast_tick + (x * fast_tick_rate) / CONFIG_SYS_HZ; /* this might need 64 bit precision in some implementations */ time_out(x): return ((i32)(x - fast_tick)) < 0; If the tick were really high speed (and then 64 bits), fast_tick could be derived by shifting the tick some bits to the right. But, as long as we cannot agree on something, there will be no time spent to make patches... Best Regards, Reinhard
Am 22.01.2011 08:46, schrieb Albert ARIBAUD: > Le 22/01/2011 06:39, Alexander Holler a écrit : >> Hello, >> >> Am 21.01.2011 09:56, schrieb Heiko Schocher: >> >>> -static ulong timestamp; >>> -static ulong lastdec; >>> +DECLARE_GLOBAL_DATA_PTR; >>> + >>> +#define timestamp gd->tbl >>> +#define lastdec gd->lastinc >> >> I'm the only one who doesn't like such defines? They might be handy for >> quick fixes, but in regard to style and readablity I don't like them. >> When looking at teh code where they will used, you won't see the actual >> place where they are stored. And in more complex expression they might >> become dangerous to use because they hide the operator "->". > > I accept the patch because it un-breaks support for ARM cpus, and I > prefer a working fix to a perfect fix in this specific, transitional, > situation. My experience is that such quick fixes (or workarounds) usually manifests (because they become forgotten) and later on might even be copied to other places. ;) Anyway, I'll have to thank for that patch, because it fixes at least one of the problems I have while trying to chainload a 2010.12 from a 2010.12 on a kirkwood system. Regards, and again, thanks for the patch, even if I found it ugly, Alexander
Hello Alexander, Alexander Holler wrote: > Am 22.01.2011 08:46, schrieb Albert ARIBAUD: >> Le 22/01/2011 06:39, Alexander Holler a écrit : >>> Hello, >>> >>> Am 21.01.2011 09:56, schrieb Heiko Schocher: >>> >>>> -static ulong timestamp; >>>> -static ulong lastdec; >>>> +DECLARE_GLOBAL_DATA_PTR; >>>> + >>>> +#define timestamp gd->tbl >>>> +#define lastdec gd->lastinc >>> >>> I'm the only one who doesn't like such defines? They might be handy for >>> quick fixes, but in regard to style and readablity I don't like them. >>> When looking at teh code where they will used, you won't see the actual >>> place where they are stored. And in more complex expression they might >>> become dangerous to use because they hide the operator "->". >> >> I accept the patch because it un-breaks support for ARM cpus, and I >> prefer a working fix to a perfect fix in this specific, transitional, >> situation. > > My experience is that such quick fixes (or workarounds) usually > manifests (because they become forgotten) and later on might even be As this is a open source project, feel free to work with us, that this get not forgotten! > copied to other places. ;) Yes, it is not the best solution, but it fixes a bug. The patch is some days old (and made as a quick fix), and I vote also to make a better approach for timers on arm, but in the time this patch was pending none did a better (accepted) approach... > Anyway, I'll have to thank for that patch, because it fixes at least one > of the problems I have while trying to chainload a 2010.12 from a > 2010.12 on a kirkwood system. > > Regards, and again, thanks for the patch, even if I found it ugly, As I said above, feel free to post a patch with a better approach. bye, Heiko
diff --git a/arch/arm/cpu/arm926ejs/kirkwood/timer.c b/arch/arm/cpu/arm926ejs/kirkwood/timer.c index 2ec6a93..3e80329 100644 --- a/arch/arm/cpu/arm926ejs/kirkwood/timer.c +++ b/arch/arm/cpu/arm926ejs/kirkwood/timer.c @@ -83,8 +83,10 @@ struct kwtmr_registers *kwtmr_regs = (struct kwtmr_registers *)KW_TIMER_BASE; #define READ_TIMER (readl(CNTMR_VAL_REG(UBOOT_CNTR)) / \ (CONFIG_SYS_TCLK / 1000)) -static ulong timestamp; -static ulong lastdec; +DECLARE_GLOBAL_DATA_PTR; + +#define timestamp gd->tbl +#define lastdec gd->lastinc void reset_timer_masked(void) { diff --git a/arch/arm/cpu/arm926ejs/mb86r0x/timer.c b/arch/arm/cpu/arm926ejs/mb86r0x/timer.c index 9175b71..6966b0d 100644 --- a/arch/arm/cpu/arm926ejs/mb86r0x/timer.c +++ b/arch/arm/cpu/arm926ejs/mb86r0x/timer.c @@ -33,8 +33,10 @@ #define TIMER_LOAD_VAL 0xffffffff #define TIMER_FREQ (CONFIG_MB86R0x_IOCLK / 256) -static unsigned long long timestamp; -static ulong lastdec; +DECLARE_GLOBAL_DATA_PTR; + +#define timestamp gd->tbl +#define lastdec gd->lastinc static inline unsigned long long tick_to_time(unsigned long long tick) { diff --git a/arch/arm/cpu/arm926ejs/mx25/timer.c b/arch/arm/cpu/arm926ejs/mx25/timer.c index 11d41a8..14f0c2d 100644 --- a/arch/arm/cpu/arm926ejs/mx25/timer.c +++ b/arch/arm/cpu/arm926ejs/mx25/timer.c @@ -41,8 +41,10 @@ #include <asm/io.h> #include <asm/arch/imx-regs.h> -static ulong timestamp; -static ulong lastinc; +DECLARE_GLOBAL_DATA_PTR; + +#define timestamp gd->tbl +#define lastinc gd->lastinc /* * "time" is measured in 1 / CONFIG_SYS_HZ seconds, diff --git a/arch/arm/cpu/arm926ejs/mx27/timer.c b/arch/arm/cpu/arm926ejs/mx27/timer.c index 8f1d47b..5c1cf01 100644 --- a/arch/arm/cpu/arm926ejs/mx27/timer.c +++ b/arch/arm/cpu/arm926ejs/mx27/timer.c @@ -43,8 +43,10 @@ #define GPTCR_CLKSOURCE_32 (4 << 1) /* Clock source */ #define GPTCR_TEN 1 /* Timer enable */ -static ulong timestamp; -static ulong lastinc; +DECLARE_GLOBAL_DATA_PTR; + +#define timestamp gd->tbl +#define lastinc gd->lastinc /* * "time" is measured in 1 / CONFIG_SYS_HZ seconds, diff --git a/arch/arm/cpu/arm926ejs/omap/timer.c b/arch/arm/cpu/arm926ejs/omap/timer.c index 7d4b6e6..88a0ee6 100644 --- a/arch/arm/cpu/arm926ejs/omap/timer.c +++ b/arch/arm/cpu/arm926ejs/omap/timer.c @@ -42,8 +42,10 @@ /* macro to read the 32 bit timer */ #define READ_TIMER (*(volatile ulong *)(CONFIG_SYS_TIMERBASE+8)) -static ulong timestamp; -static ulong lastdec; +DECLARE_GLOBAL_DATA_PTR; + +#define timestamp gd->tbl +#define lastdec gd->lastinc int timer_init (void) { diff --git a/arch/arm/cpu/arm926ejs/orion5x/timer.c b/arch/arm/cpu/arm926ejs/orion5x/timer.c index 089ef47..bbab226 100644 --- a/arch/arm/cpu/arm926ejs/orion5x/timer.c +++ b/arch/arm/cpu/arm926ejs/orion5x/timer.c @@ -90,8 +90,10 @@ static inline ulong read_timer(void) / (CONFIG_SYS_TCLK / 1000); } -static ulong timestamp; -static ulong lastdec; +DECLARE_GLOBAL_DATA_PTR; + +#define timestamp gd->tbl +#define lastdec gd->lastinc void reset_timer_masked(void) { diff --git a/arch/arm/cpu/arm926ejs/spear/timer.c b/arch/arm/cpu/arm926ejs/spear/timer.c index 06858b4..66cf4de 100644 --- a/arch/arm/cpu/arm926ejs/spear/timer.c +++ b/arch/arm/cpu/arm926ejs/spear/timer.c @@ -36,8 +36,10 @@ static struct gpt_regs *const gpt_regs_p = static struct misc_regs *const misc_regs_p = (struct misc_regs *)CONFIG_SPEAR_MISCBASE; -static ulong timestamp; -static ulong lastdec; +DECLARE_GLOBAL_DATA_PTR; + +#define timestamp gd->tbl +#define lastdec gd->lastinc int timer_init(void) { diff --git a/arch/arm/cpu/arm926ejs/versatile/timer.c b/arch/arm/cpu/arm926ejs/versatile/timer.c index 81d6749..2e243b1 100644 --- a/arch/arm/cpu/arm926ejs/versatile/timer.c +++ b/arch/arm/cpu/arm926ejs/versatile/timer.c @@ -42,8 +42,10 @@ /* macro to read the 32 bit timer */ #define READ_TIMER (*(volatile ulong *)(CONFIG_SYS_TIMERBASE+4)) -static ulong timestamp; -static ulong lastdec; +DECLARE_GLOBAL_DATA_PTR; + +#define timestamp gd->tbl +#define lastdec gd->lastinc #define TIMER_ENABLE (1 << 7) #define TIMER_MODE_MSK (1 << 6)
Reuse the gd->tbl value for timestamp and add gd->lastinc for lastinc bss values in the arm926ejs timers implementation. The usage of bss values in drivers before initialisation of bss is forbidden. In that special case some data in .rel.dyn gets corrupted. This patch is similiar to the patch Dirk Behme posted for the armv7/omap-common/timer.c and added suggestions from Reinhard Meyer. Tested on the arm926ejs mx27 based magnesium board Tested on the arm926ejs kirkwood based suen3 board Signed-off-by: Heiko Schocher <hs@denx.de> cc: Albert ARIBAUD <albert.aribaud@free.fr> cc: Prafulla Wadaskar <prafulla@marvell.com> cc: Stefano Babic <sbabic@denx.de> cc: Reinhard Meyer <u-boot@emk-elektronik.de> --- - changes since v1: rebased and fixed an trivial merge issue in arch/arm/cpu/arm926ejs/davinci/timer.c - changes since v2: removed changes in arch/arm/cpu/arm926ejs/davinci/timer.c complete, as this is fixed in the meantime arch/arm/cpu/arm926ejs/kirkwood/timer.c | 6 ++++-- arch/arm/cpu/arm926ejs/mb86r0x/timer.c | 6 ++++-- arch/arm/cpu/arm926ejs/mx25/timer.c | 6 ++++-- arch/arm/cpu/arm926ejs/mx27/timer.c | 6 ++++-- arch/arm/cpu/arm926ejs/omap/timer.c | 6 ++++-- arch/arm/cpu/arm926ejs/orion5x/timer.c | 6 ++++-- arch/arm/cpu/arm926ejs/spear/timer.c | 6 ++++-- arch/arm/cpu/arm926ejs/versatile/timer.c | 6 ++++-- 8 files changed, 32 insertions(+), 16 deletions(-)