On Mon, 12 Nov 2018, Michael Schmitz wrote:
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.
I get the impression from Documentation/core-api/atomic_ops.rst that the
author is opposed to that kind of usage of READ_ONCE() and WRITE_ONCE().
Apparently these operations are to be used solely for avoiding certain
compiler optimizations.
In this patch series I've used the same synchronization pattern for each
platform for expediency. It is probably overkill in some places.
But looking at the atari patch agin, I think there is a bug. In
atari_read_clk(), clk_total is accessed outside the irq lock. But it is
supposed to be synchronized with the timer interrupt handler and timer
interrupt flag. I'll have to change this.
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.
OK, I'll rename them.
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?
The rating is arbitrary AFAICT. I gather that it just allows the
clocksource core to select the best clocksource. The more accurate the
clocksource, the higher its rating. You can see the available clocksources
in dmesg.
With only the timer C interrupt running at increased rate, I don't think
the impact on the system would be all that severe.
If you need more timer accuracy, you'll need a faster oscillator driving
the counter. But then you get counter overflow sooner, which may or may
not be a problem.
This patch series avoids changing any device configuration (clock rates,
dividers, interrupt rates etc.)
The exception is a VIA driver bug fix patch that is part of this series
even though it is not related to the clocksource conversion. That patch
got included just because of the mechanics of testing and merging patches.
If you were to write a timer patch relevant to -stable, it could go before
my series, and I could rebase. Otherwise I suggest that it go afterwards,
either at the end of this series or submitted separately with a note about
the dependency.
--
Cheers,
??? Michael
