netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Richard Cochran <richardcochran@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	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 08:04:37 +0200	[thread overview]
Message-ID: <20230726-dreamboat-cornhusk-1bd71d19d0d4-mkl@pengutronix.de> (raw)
In-Reply-To: <ZMCRjcRF9XqEPg/Z@hoboy.vegasvil.org>

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

On 25.07.2023 20:22:53, Richard Cochran wrote:
> On Tue, Jul 25, 2023 at 08:06:06PM -0700, Jakub Kicinski wrote:
> 
> > any opinion on this one?
> 
> Yeah, I saw it, but I can't get excited about drivers trying to
> correct delays.  I don't think this can be done automatically in a
> reliable way,

At least the datasheet of the IP core tells to read the MAC delay from
the IP core (1), add the PHY delay (2) and the clock domain crossing
delay (3) and write it to the time stamp correction register.

(1) added in this patch
(2) future work
(3) already in the driver,
    though corrected manually when reading the timestamp

At least in our measurements the peer delay is better with this patch
(measured with ptp4linux) and the end-to-end delay (comparison of 2 PPS
signals on a scope) is also better.

> and so I expect that the few end users who are really
> getting into the microseconds and nanoseconds will calibrate their
> systems end to end, maybe even patching out this driver nonsense in
> their kernels.

What issues make you think this change/approach is counterproductive?

> Having said that, I won't stand in the way of such driver stuff.
> After all, who cares about a few microseconds time error one way or
> the other?

There are several companies that use or plan to use PTP in their
products and are striving to achieve sub-microsecond synchronization.

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  6:05 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 [this message]
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
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-dreamboat-cornhusk-1bd71d19d0d4-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).