Op ma 19 nov. 2018 om 02:10 schreef Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx>:
hp300_gettimeoffset() never checks the timer interrupt flag and will fail to notice when the timer counter gets reloaded. That means the clock could jump backwards. Remove this code and leave this platform on the 'jiffies' clocksource. Note that this amounts to a regression in clock precision. However, adopting the 'jiffies' clocksource does resolve the monotonicity issue. Signed-off-by: Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx> --- hp300_gettimeoffset() cannot be used in a clocksource conversion unless it can be made monotonic. I can't fix this without knowing the details of the timer implementation, such as the relationship between the timer count and the interrupt flag.
I don't really like this regression... According to NetBSD sources, there are 3 timers in the chip (originally an MC6840 PTM). Timer 1 is used as the system timer, timer 3 runs at the same rate and is unused on Linux (on NetBSD it is used as the statistics/profiling timer), and timer 3 is connected to timer 2 so you can make a 32-bit timer out of the two timers together (also unused on Linux). Timers 1 counts down at 25 MHz. The interrupt flag is set when the counter reaches 0 after which it is automatically reloaded and starts counting down again.
--- arch/m68k/hp300/time.c | 19 ------------------- 1 file changed, 19 deletions(-)
