* [U-Boot] [Timer]Help need to clean up udelay() for several ARM CPUs
@ 2011-06-03 12:18 Graeme Russ
0 siblings, 0 replies; only message in thread
From: Graeme Russ @ 2011-06-03 12:18 UTC (permalink / raw)
To: u-boot
Hi Guys,
I'm trying to cleanup the old timer API as much as possible in preparation
for the new API. I've managed to purge reset_timer() for all but Nios2 as
well as get_timer(). Where timer_init() was calling set_timer() or
reset_timer() I folded the code into timer_init()
I have then proceeded to do the same to reset_timer_masked() - Mostly this
was only called by reset_timer() which in turn was only called by
timer_init(), but the following 8 files have reset_timer_masked() used in
udelay()
arch/arm/cpu/arm926ejs/omap/timer.c
arch/arm/cpu/arm926ejs/versatile/timer.c
arch/arm/cpu/arm1136/omap24xx/timer.c
arch/arm/cpu/arm1136/mx35/timer.c
arch/arm/cpu/arm920t/a320/timer.c
arch/arm/cpu/armv7/s5p-common/timer.c
arch/arm/cpu/lh7a40x/timer.c
board/armltd/vexpress/ca9x4_ct_vxp.c
Now I'm sure something very funky is going on which allows udelay() to call
reset_timer_masked() with impacting on get_timer() but I don't know ARM at
all and I'm not willing to mess around with these for fear of causing a
rather large breakage.
Can someone please look into these and let me know how I can safely
sanitise these 8 implementations of udelay()?
If all else fails, I'll just make reset_timer_masked static in these files
Thanks in advance
Graeme
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2011-06-03 12:18 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-03 12:18 [U-Boot] [Timer]Help need to clean up udelay() for several ARM CPUs Graeme Russ
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox