The generic clock and timekeeping infrastructure supports only the already
defined clocks and as they are not independent there is no need of
generalization of data structures. But PTP clocks can be independent from
CLOCK_TAI.

PTP clocks already have clock_gettime() support via the file descriptor
based posix clocks. These interfaces access the PTP hardware and are
therefore slow and cannot be used from within the kernel, e.g. TSN
networking.

This problem can be solved by emulating clock_gettime() via the system
clock source e.g. TSC on x86. Such emulation requires:

1. timekeeping mechanism similar to the existing system timekeeping
2. clock steering equivalent to NTP/adjtimex()

In the already existing system timekeeping implementation the lock and
shadow timekeeper are separate from the timekeeper and sequence
counter. Move this information into a new struct type "tk_data" to be able
to recycle it for the above explained approach.

NTP/adjtimex() related information is all stored in static variables. Move
all of them into the new struct type ntp_data to make it reusable.

Even without the furture support for independent PTP clocks, the
generalization of timekeeping and NTP/adjtimex() improves the structure and
readability of the already existing code.

Once this is implemented clock_gettime() support for these clocks via vdso
can be implement as well but this is an orthogonal task.

This queue covers only the generalization of ntp:

- Patch 1-6:  Basic cleanups
- Patch 7-21: Introduction of struct ntp_data and move all static variables
	      to the struct

The queue is available here:

  git://git.kernel.org/pub/scm/linux/kernel/git/anna-maria/linux-devel.git timers/ptp/ntp

Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: Miroslav Lichvar <mlichvar@redhat.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Christopher S Hall <christopher.s.hall@intel.com>
To: John Stultz <jstultz@google.com>
To: Frederic Weisbecker <frederic@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>

Thanks,

Anna-Maria

---
Anna-Maria Behnsen (1):
      ntp: Cleanup formatting of code

Thomas Gleixner (20):
      ntp: Remove unused tick_nsec
      ntp: Make tick_usec static
      ntp: Clean up comments
      ntp: Convert functions with only two states to bool
      ntp: Read reference time only once
      ntp: Introduce struct ntp_data
      ntp: Move tick_length* into ntp_data
      ntp: Move tick_stat* into ntp_data
      ntp: Move time_offset/constant into ntp_data
      ntp: Move time_max/esterror into ntp_data
      ntp: Move time_freq/reftime into ntp_data
      ntp: Move time_adj/ntp_tick_adj into ntp_data
      ntp: Move ntp_next_leap_sec into ntp_data
      ntp: Move pps_valid into ntp_data
      ntp: Move pps_ft into ntp_data
      ntp: Move pps_jitter into ntp_data
      ntp: Move pps_fbase into ntp_data
      ntp: Move pps_shift/intcnt into ntp_data
      ntp: Move pps_freq/stabil into ntp_data
      ntp: Move pps monitors into ntp_data

 arch/x86/include/asm/timer.h |   2 -
 include/linux/timex.h        |   8 -
 kernel/time/ntp.c            | 840 +++++++++++++++++++++----------------------
 3 files changed, 419 insertions(+), 431 deletions(-)

On Wed, Sep 11, 2024 at 03:17:36PM +0200, Anna-Maria Behnsen wrote:
> This problem can be solved by emulating clock_gettime() via the system
> clock source e.g. TSC on x86. Such emulation requires:
> 
> 1. timekeeping mechanism similar to the existing system timekeeping
> 2. clock steering equivalent to NTP/adjtimex()

I'm trying to understand what independent PTP clocks means here. Is
the goal to provide virtual PTP clocks running on top of the system
clocksource (e.g. TSC) similarly to what is currently done for
physical PTP clocks by writing to /sys/class/ptp/ptp*/n_vclocks,
expecting the virtual clocks to be synchronized by applications like
phc2sys?

Or is this more about speeding up the reading of the PHC, where the
kernel itself would be tracking the offset using one of the PTP
driver's PTP_SYS_OFFSET operations and emulating a fast-reading PHC?

-- 
Miroslav Lichvar

Miroslav Lichvar <mlichvar@redhat.com> writes:

> On Wed, Sep 11, 2024 at 03:17:36PM +0200, Anna-Maria Behnsen wrote:
>> This problem can be solved by emulating clock_gettime() via the system
>> clock source e.g. TSC on x86. Such emulation requires:
>> 
>> 1. timekeeping mechanism similar to the existing system timekeeping
>> 2. clock steering equivalent to NTP/adjtimex()
>
> I'm trying to understand what independent PTP clocks means here. Is
> the goal to provide virtual PTP clocks running on top of the system
> clocksource (e.g. TSC) similarly to what is currently done for
> physical PTP clocks by writing to /sys/class/ptp/ptp*/n_vclocks,
> expecting the virtual clocks to be synchronized by applications like
> phc2sys?
>
> Or is this more about speeding up the reading of the PHC, where the
> kernel itself would be tracking the offset using one of the PTP
> driver's PTP_SYS_OFFSET operations and emulating a fast-reading PHC?

That's one aspect.

The independant PTP clocks are PTP clocks which are not synchronized
with CLOCK_TAI. They are "standalone". They are used in automation and
automotive setups. They have a grand clock master which is not
synchronized to anything. There are also requirements for redundant
networks where the clocks are not allowed to be synchronized between the
networks to prevent common cause failures.

These clocks are used for TSN and both applications and the network
stack needs to be able to read the time. Going through the file
decriptor based interfaces is slow and not possible in the kernel.

The goal is to provide infrastructure which allows these clocks to be
read via kernel interfaces and clock_gettime(PTPID) by emulating the
clock via the system clocksource (e.g. TSC).

That means they need timekeeping and steering infrastructure, to keep
them in sync with the PHC. It's the identical mechanism to what system
timekeeping and NTP do for the system clocks.

So instead of creating duplicate infrastructure, this aims to reuse the
existing one.

Hope this helps to make it more clear.

Thanks,

        Anna-Maria

On Thu, Sep 12, 2024 at 10:12:59AM +0200, Miroslav Lichvar wrote:
> I'm trying to understand what independent PTP clocks means here.

Me, too.

It is not easy to see where this is going...

Thanks,
Richard