On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
A clocksource provides a cycle counter that monotonically changes and does not wrap between clockevent events. A clock event is responsible for providing events to the system when some work is needing to be done, limited by the wrap interval of the clocksource. Each time the clock event triggers an interrupt, the clocksource is read to determine how much time has passed, using: count = (new_value - old_value) & available_bits nanosecs = count * scale >> shift; If you try to combine the clocksource and clockevent because you only have a single counter, and the counter has the behaviour of: - counting down towards zero - when reaching zero, triggers an interrupt, and reloads with N then this provides your clockevent, but you can't use this as a clock source, because each time you receive an interrupt and try to read the counter value, it will be approximately the same value. This means that the above calculation fails to register the correct number of nanoseconds passing. Hence, this does not work. Also note where I said above that the clock event device must be able to provide an interrupt _before_ the clocksource wraps - clearly with such a timer, that is utterly impossible. The simple solution is to not use such a counter as the clocksource, which means you fall back to using the jiffies clocksource, and your timekeeping has jiffy resolution - so 10ms, or possibly 1ms if you want a 1kHz timer interval. For most applications, that's simply way to coarse, as was realised in the very early days of Linux. If only there was a way to interpolate between timer interrupts... which is exactly what arch_gettimeoffset() does, and is a historical reminant of the pre-clocksource/clockevent days of the kernel - but it is the only way to get better resolution from this sort of setup.
Both of the platforms in question (RPC and EBSA110) have not defined(CONFIG_GENERIC_CLOCKEVENTS) and have not defined any struct clock_event_device, AFAICT. So, even assuming that you're right about the limitations of single-timer platforms in general, removal of arch_gettimeoffset wouldn't require the removal of any platforms, AFAICT. --
