[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZuKii1KDGHSXElB6@localhost>
Date: Thu, 12 Sep 2024 10:12:59 +0200
From: Miroslav Lichvar <mlichvar@...hat.com>
To: Anna-Maria Behnsen <anna-maria@...utronix.de>
Cc: John Stultz <jstultz@...gle.com>,
Frederic Weisbecker <frederic@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, Richard Cochran <richardcochran@...il.com>,
Christopher S Hall <christopher.s.hall@...el.com>
Subject: Re: [PATCH 00/21] ntp: Rework to prepare support of indenpendent PTP
clocks
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
Powered by blists - more mailing lists