On Tue, Jul 23, 2013 at 11:04 AM, Jeremy Bennett <[email protected]> wrote: > On 23/07/13 07:35, Stefan Kristiansson wrote: >> >> When the continous mode is set and the current timer value >> matches what is in timer period (TP), the timer is disabled. >> This does not match the behaviour that is described in the arch >> specification, nor does any of the major implementations behave >> like this. >> --- >> tick/tick.c | 8 -------- >> 1 file changed, 8 deletions(-) >> >> diff --git a/tick/tick.c b/tick/tick.c >> index d2ad148..266d539 100644 >> --- a/tick/tick.c >> +++ b/tick/tick.c >> @@ -201,14 +201,6 @@ spr_write_ttmr (uorreg_t prev_val) >> >> tick_counting = value & SPR_TTMR_M; >> >> - /* If TTCR==TTMR_TP when setting MR, we disable counting?? >> - I think this should be looked at - Julius */ >> - if ((tick_counting == SPR_TTMR_CR) && >> - (cpu_state.sprs[SPR_TTCR] == (value & SPR_TTMR_TP))) >> - { >> - tick_counting = 0; >> - } >> - >> sched_timer_job (prev_val); >> } >> >> > Hi Stefan, > > Thanks for this. Assuming regression still passes (you may need to adjust > any timer tests, and if necessary add new ones), would you commit it to > Or1ksim. Both or1k and or32 branches. >
I've committed this to both or1k and or32 branches, accompanied with a new test and ChangeLog entries. It didn't introduce any test fails on neither the or1k nor the or32 branch. Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
