Hi Philippe,
Philippe De Muyter wrote:
Greg Ungerer wrote:
Philippe De Muyter wrote:
The coldfire timer runs from 0 to trr included, then 0 again and so on.
It counts thus actually trr + 1 steps for 1 tick, not trr. Fix that
Actual debugging work has been made on a 5272. I hope it's the same for
the other coldfire's.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
diff -r 9ed3c4dc013f arch/m68knommu/platform/5307/timers.c
--- a/arch/m68knommu/platform/5307/timers.c Wed Feb 21 13:02:17 2007
-0800
+++ b/arch/m68knommu/platform/5307/timers.c Mon Mar 19 16:48:00 2007
+0100
@@ -62,10 +62,13 @@ void coldfire_tick(void)
/***************************************************************************/
+static int ticks_per_intr;
+
void coldfire_timer_init(irq_handler_t handler)
{
__raw_writew(MCFTIMER_TMR_DISABLE, TA(MCFTIMER_TMR));
- __raw_writetrr(((MCF_BUSCLK / 16) / HZ), TA(MCFTIMER_TRR));
+ ticks_per_intr = (MCF_BUSCLK / 16) / HZ;
+ __raw_writetrr(ticks_per_intr - 1, TA(MCFTIMER_TRR));
__raw_writew(MCFTIMER_TMR_ENORI | MCFTIMER_TMR_CLK16 |
MCFTIMER_TMR_RESTART | MCFTIMER_TMR_ENABLE,
TA(MCFTIMER_TMR));
@@ -84,8 +87,7 @@ unsigned long coldfire_timer_offset(void
unsigned long trr, tcn, offset;
tcn = __raw_readw(TA(MCFTIMER_TCN));
- trr = __raw_readtrr(TA(MCFTIMER_TRR));
- offset = (tcn * (1000000 / HZ)) / trr;
+ offset = ((tcn + 1) * (1000000 / HZ)) / ticks_per_intr;
Looking at this isn't it mis-handling the case where the
TCN reads back as the maximal count (so ticks_per_intr in
this case).
Well thought :)
My understanding is that could occur after it
has clocked over to the maximal count value, and after we have
serviced the timer interrupt that it will generate
(assuming the interrupt was serviced quickly enough).
Actually, as we initialize the timer with MCFTIMER_TMR_CLK16, tcn will give
back the same value during 16 cycles. The interrupt should thus be faster
than 16 cycles for this case to happen. SAVE_ALL+RESTORE_ALL and even
SAVE_LOCAL+RESTORE_LOCAL are slower than that (rte alone already takes
10 cycles on MCF5272), so I think that this case can not happen.
Agreed, I doubt the interrupt could be that quick.
The case on the otherside can happen. That is the count reaches
the maximal count after locking but before we read the TCN
register. So we want that to be correct (which I think your
code is).
I'll apply as it was.
Thanks
Greg
This code as is will return a large offset for this, when
in fact it should be 0.
Maybe something like this is better:
tcn = (tcn >= (ticks_per_intr-1)) ? 0 : (tcn+1);
offset = (tcn * (1000000 / HZ)) / ticks_per_intr;
Comments?
Regards
Greg
/* Check if we just wrapped the counters and maybe missed a tick */
if ((offset < (1000000 / HZ / 2)) && mcf_timerirqpending(1))
--
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
