From: Thomas Gleixner <tglx@linutronix.de>
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
netdev@vger.kernel.org,
"Richard Cochran" <richardcochran@gmail.com>,
"Christopher Hall" <christopher.s.hall@intel.com>,
"David Zage" <david.zage@intel.com>,
"John Stultz" <jstultz@google.com>,
"Frederic Weisbecker" <frederic@kernel.org>,
"Anna-Maria Behnsen" <anna-maria@linutronix.de>,
"Werner Abt" <werner.abt@meinberg-usa.com>,
"David Woodhouse" <dwmw2@infradead.org>,
"Stephen Boyd" <sboyd@kernel.org>,
"Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
"Kurt Kanzenbach" <kurt@linutronix.de>,
"Nam Cao" <namcao@linutronix.de>,
"Alex Gieringer" <gieri@linutronix.de>
Subject: Re: [patch 00/26] timekeeping: Provide support for independent PTP timekeepers
Date: Wed, 14 May 2025 10:54:33 +0200 [thread overview]
Message-ID: <871psrk1x2.ffs@tglx> (raw)
In-Reply-To: <aCRCe8STiX03WcxU@localhost>
On Wed, May 14 2025 at 09:12, Miroslav Lichvar wrote:
> On Tue, May 13, 2025 at 05:12:54PM +0200, Thomas Gleixner wrote:
>> This series addresses the timekeeping part by utilizing the existing
>> timekeeping and NTP infrastructure, which has been prepared for
>> multi-instance in recent kernels.
>
> This looks very interesting. I ran some quick tests and it seems to
> work as expected from the user space point of view. I can enable the
> clock and synchronize it to a PTP HW clock or the system REALTIME
> clock. ADJ_TICK works too.
Cool.
> To get accuracy and stability comparable to CLOCK_REALTIME, there will
> need to be some support for cross timestamping against CLOCK_REALTIME
> and/or PTP HW clocks, e.g. a variant of the PTP_SYS_OFFSET_PRECISE and
> PTP_SYS_OFFSET_EXTENDED ioctls where the target clock can be selected.
Yes, that's required, but for that to implement we need the core muck
first :)
> The "PTP" naming of these new clocks doesn't seem right to me though
> and I suspect it would just create more confusion. I don't see
> anything specific to PTP here. There is no timestamping of network
> packets, no /dev/ptp device, no PTP ioctls. To me they look like
> secondary or auxiliary system realtime clocks. I propose to rename
> them from CLOCK_PTP0-7 to CLOCK_REALTIME2-9, CLOCK_AUXILIARY0-7, or
> CLOCK_AUX0-7.
CLOCK_REALTIME2-9 would be weird as those clocks have not necessarily a
relationship to CLOCK_REALTIME. They can have a seperate resulting
frequency and starting point when they are soleley used for application
specific purposes within a network (think automation, automotive, audio
etc.).
CLOCK_AUX0-7 sounds really good to me and makes sense. I picked PTP
because that's where I was coming from. I'll rework that accordingly and
make the config enablement independent of PTP as well:
config POSIX_CLOCKS_AUX
bool "Enable auxiliary POSIX clocks" if POSIX_TIMERS
help
Add blurb
and PTP can eventually select it (or not). Something like that.
Thanks,
tglx
next prev parent reply other threads:[~2025-05-14 8:54 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-13 15:12 [patch 00/26] timekeeping: Provide support for independent PTP timekeepers Thomas Gleixner
2025-05-13 15:12 ` [patch 01/26] timekeeping: Remove hardcoded access to tk_core Thomas Gleixner
2025-05-13 15:12 ` [patch 02/26] timekeeping: Cleanup kernel doc of __ktime_get_real_seconds() Thomas Gleixner
2025-05-13 15:13 ` [patch 03/26] timekeeping: Avoid double notification in do_adjtimex() Thomas Gleixner
2025-05-13 15:13 ` [patch 04/26] timekeeping: Introduce timekeeper ID Thomas Gleixner
2025-05-13 15:13 ` [patch 05/26] time: Introduce PTP clocks Thomas Gleixner
2025-05-13 15:13 ` [patch 06/26] ntp: Add support for PTP timekeepers Thomas Gleixner
2025-05-13 15:13 ` [patch 07/26] ntp: Add timekeeper ID arguments to public functions Thomas Gleixner
2025-05-13 15:13 ` [patch 08/26] ntp: Rename __do_adjtimex() to ntp_adjtimex() Thomas Gleixner
2025-05-13 15:13 ` [patch 09/26] timekeeping: Make __timekeeping_advance() reusable Thomas Gleixner
2025-05-13 15:13 ` [patch 10/26] timekeeping: Prepare timekeeping_update_from_shadow() Thomas Gleixner
2025-05-13 15:13 ` [patch 11/26] timekeeping: Add clock_valid flag to timekeeper Thomas Gleixner
2025-05-13 15:13 ` [patch 12/26] timekeeping: Introduce PTP time keepers Thomas Gleixner
2025-05-13 15:13 ` [patch 13/26] timekeeping: Provide ktime_get_ntp_seconds() Thomas Gleixner
2025-05-13 15:13 ` [patch 14/26] ntp: Use ktime_get_ntp_seconds() Thomas Gleixner
2025-05-13 15:13 ` [patch 15/26] timekeeping: Add PTP offset to timekeeper Thomas Gleixner
2025-05-13 15:13 ` [patch 16/26] timekeeping: Update PTP timekeepers on clocksource change Thomas Gleixner
2025-05-13 15:13 ` [patch 17/26] timekeeping: Provide time getters for PTP clocks Thomas Gleixner
2025-05-13 15:13 ` [patch 18/26] timekeeping: Add minimal posix-timers support " Thomas Gleixner
2025-05-13 15:13 ` [patch 19/26] timekeeping: Provide time setter " Thomas Gleixner
2025-05-13 15:13 ` [patch 20/26] timekeeping: Make timekeeping_inject_offset() reusable Thomas Gleixner
2025-05-13 15:13 ` [patch 21/26] timekeeping: Add PTP clock support to __timekeeping_inject_offset() Thomas Gleixner
2025-05-13 15:13 ` [patch 22/26] timekeeping: Make do_adjtimex() reusable Thomas Gleixner
2025-05-13 15:13 ` [patch 23/26] timekeeping: Prepare do_adtimex() for PTP clocks Thomas Gleixner
2025-05-13 15:13 ` [patch 24/26] timekeeping: Provide adjtimex() " Thomas Gleixner
2025-05-13 15:13 ` [patch 25/26] timekeeping: Provide update for PTP timekeepers Thomas Gleixner
2025-05-13 15:13 ` [patch 26/26] timekeeping: Provide interface to control independent PTP clocks Thomas Gleixner
2025-05-14 8:07 ` Antoine Tenart
2025-05-14 8:37 ` Thomas Gleixner
2025-05-14 7:12 ` [patch 00/26] timekeeping: Provide support for independent PTP timekeepers Miroslav Lichvar
2025-05-14 8:54 ` Thomas Gleixner [this message]
2025-05-14 15:58 ` Richard Cochran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871psrk1x2.ffs@tglx \
--to=tglx@linutronix.de \
--cc=anna-maria@linutronix.de \
--cc=christopher.s.hall@intel.com \
--cc=david.zage@intel.com \
--cc=dwmw2@infradead.org \
--cc=frederic@kernel.org \
--cc=gieri@linutronix.de \
--cc=jstultz@google.com \
--cc=kurt@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mlichvar@redhat.com \
--cc=namcao@linutronix.de \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.com \
--cc=sboyd@kernel.org \
--cc=thomas.weissschuh@linutronix.de \
--cc=werner.abt@meinberg-usa.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.