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 --]
next prev 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).