Use counter drivers as a system clock source

[pizi-nordic]

At the moment the system clock source needs dedicated driver, which exports both tick interface (z_clock_*()) as well as cycle interface (_timer_cycle_get_32()). Any change in the area needs rework of several drivers (see the #10556 as the example).

Moreover, adding a new platform or extending current ones is also tricky. For example, the nRF5x platform could use different peripherals as a system clock source (RTC running at 32kHz or TIMER running at 1-16 MHz). The driver for TIMER is available, however it cannot be easily plugged in as a system clock source.

There is another drawback of current situation: The kernel expects some behaviour from the time source provided by the driver: The clock counter has to count up and has to be exactly 32-bit. Any platform which does not meet the expectations, has to implement software translation, which cannot be reused by other platforms or subsystems.

The recent feature requests (#9043 (comment), #6498, #2921), suggests that the rework of timers is not done and we might benefit from a kind of cleanup of this subsystem.

Part of such rework is already ongoing: #8331. I would like to take further steps and implement 2 hardware independent layers on top of the counter interface.

The first proposed layer would implement a generic counter and make it available for the system as well as the application. Such generic counter will have fixed width (for example 64 bits) and will always count up regardless of underlying hardware capabilities. Such interface might be generic implementation of k_cycle_get_32() (or even the k_cycle_get_64()) as well as provide a stable base for other subsystems.

The second proposed layer, would implement generic system clock source (the tick interface). As capabilities of the underlying "hardware" will be fixed, this layer will be generic and easy to extend and maintain.

Benefits of the proposed approach:

• Hardware drivers will be simple, easy to test and maintain as they only have to export HW capabilities over new counter.h interface.
• System and application could use the generic counter abstraction to be portable.
• We will be able to create counters having arbitrary number of bits and channels, if such need will pop up.
• There will be single implementation of common procedures (prescaling, length extension) as well as system timer. This should greatly reduce work needed to fix, debug and maintain all timer-related stuff.

[pizi-nordic]

FYI: @carlescufi, @ioannisg, @nordic-krch, @nashif, @andyross, @andrewboie

[pdunaj]

The generic solution may add additional sources of increased latency.
Still I guess the logic required for abstraction is already present here and there. Additional overhead will be probably smaller then could be anticipated from the first look here. And if properly implemented it will help with keeping the bugs away.

[pabigot]

Back here the motivation for preserving tick as a distinct kernel time unit was that some architectures tick so fast that a u32_t is insufficient to support reasonable timeouts.

If we base system time on a 64-bit--capable counter, is this distinction still necessary? I.e., do we need a tick interface that's different from the cycle interface?

I very much want to see a 64-bit system time (capable of measuring up to 10 years) on any IoT device I develop for, and to not have to muck about with converting between different units (ticks, ms, whatever).

[nashif]

TSC: defer after 1.14 and allow for basic prototyping once counter is merged.

[carlescufi]

@nordic-krch should we close this now?

[nashif]

outdated, closing.