Greg Ungerer wrote: > >>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. Agreed.
> 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). Not only mine :) The previous one was also correct for that. > > I'll apply as it was. Thanks Philippe _______________________________________________ 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
