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
