netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Richard Cochran <richardcochran@gmail.com>,
	Johannes Zink <j.zink@pengutronix.de>,
	linux-kernel@vger.kernel.org, kernel@pengutronix.de,
	netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Russell King <linux@armlinux.org.uk>,
	kernel test robot <lkp@intel.com>,
	Eric Dumazet <edumazet@google.com>,
	Jose Abreu <joabreu@synopsys.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	Paolo Abeni <pabeni@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	linux-arm-kernel@lists.infradead.org,
	patchwork-jzi@pengutronix.de
Subject: Re: [PATCH v2] net: stmmac: correct MAC propagation delay
Date: Wed, 26 Jul 2023 07:50:11 +0200	[thread overview]
Message-ID: <20230726-subsector-unguided-8f1fc1edb037-mkl@pengutronix.de> (raw)
In-Reply-To: <20230725200606.5264b59c@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 2176 bytes --]

On 25.07.2023 20:06:06, Jakub Kicinski wrote:
> On Mon, 24 Jul 2023 12:01:31 +0200 Johannes Zink wrote:
> > The IEEE1588 Standard specifies that the timestamps of Packets must be
> > captured when the PTP message timestamp point (leading edge of first
> > octet after the start of frame delimiter) crosses the boundary between
> > the node and the network. As the MAC latches the timestamp at an
> > internal point, the captured timestamp must be corrected for the
> > additional path latency, as described in the publicly available
> > datasheet [1].
> > 
> > This patch only corrects for the MAC-Internal delay, which can be read
> > out from the MAC_Ingress_Timestamp_Latency register, since the Phy
> > framework currently does not support querying the Phy ingress and egress
> > latency. The Closs Domain Crossing Circuits errors as indicated in [1]
> > are already being accounted in the stmmac_get_tx_hwtstamp() function and
> > are not corrected here.
> > 
> > As the Latency varies for different link speeds and MII
> > modes of operation, the correction value needs to be updated on each
> > link state change.
> > 
> > As the delay also causes a phase shift in the timestamp counter compared
> > to the rest of the network, this correction will also reduce phase error
> > when generating PPS outputs from the timestamp counter.
> > 
> > [1] i.MX8MP Reference Manual, rev.1 Section 11.7.2.5.3 "Timestamp
> > correction"
> 
> Hi Richard,
> 
> any opinion on this one?
> 
> The subject read to me like it's about *MII clocking delays, I figured
> you may have missed it, too.

The patch description clarifies what is being corrected, namely the
"MAC-internal delay, which can be read out from the
MAC_Ingress_Timestamp_Latency register".

The next step would be to correct PHY latency, but there is no support
for querying PHY latency yet.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2023-07-26  5:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-24 10:01 [PATCH v2] net: stmmac: correct MAC propagation delay Johannes Zink
2023-07-26  3:06 ` Jakub Kicinski
2023-07-26  3:22   ` Richard Cochran
2023-07-26  3:39     ` Jakub Kicinski
2023-07-26  6:04     ` Marc Kleine-Budde
2023-07-26 15:34       ` Richard Cochran
2023-07-27  6:40         ` Johannes Zink
2023-07-27 13:30           ` Richard Cochran
2023-07-26  6:10     ` Johannes Zink
2023-07-26 15:43       ` Richard Cochran
2023-07-27  6:39         ` Johannes Zink
2023-07-27  6:55           ` Johannes Zink
2023-07-27  7:41             ` Johannes Zink
2023-07-27  7:15           ` Kurt Kanzenbach
2023-07-27  7:18             ` Johannes Zink
2023-07-26  5:50   ` Marc Kleine-Budde [this message]
2023-07-26  3:50 ` patchwork-bot+netdevbpf
2023-07-26 18:00 ` Richard Cochran
2023-07-27  6:42   ` Johannes Zink
2023-07-27 13:34     ` Richard Cochran
2023-07-26 20:57 ` Richard Cochran
2023-07-27  7:20   ` Johannes Zink
2023-07-27 13:36     ` Richard Cochran
2023-07-31  7:00       ` Johannes Zink
2023-07-31 13:44         ` 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=20230726-subsector-unguided-8f1fc1edb037-mkl@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=alexandre.torgue@foss.st.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=j.zink@pengutronix.de \
    --cc=joabreu@synopsys.com \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --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=lkp@intel.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=patchwork-jzi@pengutronix.de \
    --cc=peppe.cavallaro@st.com \
    --cc=richardcochran@gmail.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).