netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc: "Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Jose Abreu" <joabreu@synopsys.com>,
	"Andrew Lunn" <andrew+netdev@lunn.ch>,
	davem@davemloft.net, "Eric Dumazet" <edumazet@google.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Richard Cochran" <richardcochran@gmail.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"Köry Maincent" <kory.maincent@bootlin.com>,
	"Alexis Lothoré" <alexis.lothore@bootlin.com>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 2/3] net: stmmac: Allow supporting coarse adjustment mode
Date: Fri, 17 Oct 2025 18:23:58 -0700	[thread overview]
Message-ID: <20251017182358.42f76387@kernel.org> (raw)
In-Reply-To: <20251015102725.1297985-3-maxime.chevallier@bootlin.com>

On Wed, 15 Oct 2025 12:27:22 +0200 Maxime Chevallier wrote:
> The DWMAC1000 supports 2 timestamping configurations to configure how
> frequency adjustments are made to the ptp_clock, as well as the reported
> timestamp values.
> 
> There was a previous attempt at upstreaming support for configuring this
> mode by Olivier Dautricourt and Julien Beraud a few years back [1]
> 
> In a nutshell, the timestamping can be either set in fine mode or in
> coarse mode.
> 
> In fine mode, which is the default, we use the overflow of an accumulator to
> trigger frequency adjustments, but by doing so we lose precision on the
> timetamps that are produced by the timestamping unit. The main drawback
> is that the sub-second increment value, used to generate timestamps, can't be
> set to lower than (2 / ptp_clock_freq).
> 
> The "fine" qualification comes from the frequent frequency adjustments we are
> able to do, which is perfect for a PTP follower usecase.
> 
> In Coarse mode, we don't do frequency adjustments based on an
> accumulator overflow. We can therefore have very fine subsecond
> increment values, allowing for better timestamping precision. However
> this mode works best when the ptp clock frequency is adjusted based on
> an external signal, such as a PPS input produced by a GPS clock. This
> mode is therefore perfect for a Grand-master usecase.
> 
> We therefore attempt to map these 2 modes with the newly introduced
> hwtimestamp qualifiers (precise and approx).
> 
> Precise mode is mapped to stmmac fine mode, and is the expected default,
> suitable for all cases and perfect for follower mode
> 
> Approx mode is mapped to coarse mode, suitable for Grand-master.

I failed to understand what this device does and what the problem is :(

What is your ptp_clock_freq? Isn't it around 50MHz typically? 
So 2 / ptp_freq is 40nsec (?), not too bad?

My recollection of the idea behind that timestamping providers
was that you can configure different filters for different providers.
IOW that you'd be able to say:
 - [precise] Rx stamp PTP packets 
 -  [approx] Rx stamp all packets
not that you'd configure precision of one piece of HW..

If the HW really needs it, just lob a devlink param at it?

  reply	other threads:[~2025-10-18  1:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-15 10:27 [PATCH net-next 0/3] net: stmmac: Add support for coarse timestamping Maxime Chevallier
2025-10-15 10:27 ` [PATCH net-next 1/3] net: stmmac: Move subsecond increment configuration in dedicated helper Maxime Chevallier
2025-10-15 15:06   ` Russell King (Oracle)
2025-10-15 16:20     ` Maxime Chevallier
2025-10-15 17:20       ` Russell King (Oracle)
2025-10-15 10:27 ` [PATCH net-next 2/3] net: stmmac: Allow supporting coarse adjustment mode Maxime Chevallier
2025-10-18  1:23   ` Jakub Kicinski [this message]
2025-10-18  7:42     ` Maxime Chevallier
2025-10-20  9:00       ` Kory Maincent
2025-10-20  9:32         ` Maxime Chevallier
2025-10-20 12:52           ` Kory Maincent
2025-10-21  1:03       ` Jakub Kicinski
2025-10-21  8:02         ` Maxime Chevallier
2025-10-21 23:02           ` Jakub Kicinski
2025-10-23  8:29             ` Maxime Chevallier
2025-10-23  8:35               ` Kory Maincent
2025-10-15 10:27 ` [PATCH net-next 3/3] net: ethtool: tsconfig: Re-configure hwtstamp upon provider change Maxime Chevallier
2025-10-15 12:45   ` Kory Maincent
2025-10-16  8:01     ` Maxime Chevallier
2025-10-16  8:44       ` Kory Maincent
2025-10-16  8:53     ` Russell King (Oracle)
2025-10-15 12:55 ` [PATCH net-next 0/3] net: stmmac: Add support for coarse timestamping Kory Maincent
2025-10-16  8:14   ` Maxime Chevallier

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=20251017182358.42f76387@kernel.org \
    --to=kuba@kernel.org \
    --cc=alexandre.torgue@foss.st.com \
    --cc=alexis.lothore@bootlin.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=joabreu@synopsys.com \
    --cc=kory.maincent@bootlin.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux@armlinux.org.uk \
    --cc=maxime.chevallier@bootlin.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=richardcochran@gmail.com \
    --cc=thomas.petazzoni@bootlin.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).