Hi Finn,
Am 12.11.18 um 17:34 schrieb Finn Thain:
On Mon, 12 Nov 2018, Michael Schmitz wrote:
That's ultimately for Geert to decide - I'll yet have to look at your
mac patches to even get a vague idea what this conversion involves, but
I can certainly test whatever you came up with for Mac on Atari.
Thanks. I'll send out the latest patches for people to test.
Thanks - I just had a look at the Atari clocksource implementation and
it looks fine to me. I'm wondering if disabling interrupts really is
required when updating the ticks counter in mfp_timer_handler, or
whether READ_ONCE() and WRITE_ONCE() would work as well.
Note that there's a mfptimer_handler() in arch/m68k/atari/ataints.c
already (timer D, for polling interrupt-less hardware - I used to have
patches to adjust the rate of that timer at runtime...). Might be best
to rename the two (mfp_timerc_handler(), mfp_timerd_handler()) for
clarity. Or hook that timer function into the generic clocksource timer.
Tick granularity is 40 us at best on Atari with the current timer
configuration, and can't be increased without increasing HZ. I suspect
the limitations on Mac are similar?
If I understand correctly, removing arch_gettimeoffset without adding a
clocksource would reduce timer accuracy to 10 ms regardless of platform
(because that's what the default jiffies clocksource offers).
That's my understanding. I now see that we could quite easily change the
timer C divisor to 10 while retaining the timer C data (246) and obtain
a clocksource rate of 2500. Setting that in the clocksource 'rating'
field will keep the scheduling timer at 100 Hz, is that correct?
With only the timer C interrupt running at increased rate, I don't think
the impact on the system would be all that severe.
Cheers,
Michael
