From: Vladimir Oltean <olteanv@gmail.com>
To: Richard Cochran <richardcochran@gmail.com>
Cc: Mark Brown <broonie@kernel.org>,
Hubert Feurstein <h.feurstein@gmail.com>,
Miroslav Lichvar <mlichvar@redhat.com>,
Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
linux-spi@vger.kernel.org, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH spi for-5.4 0/5] Deterministic SPI latency with NXP DSPI driver
Date: Wed, 21 Aug 2019 23:17:23 +0300 [thread overview]
Message-ID: <CA+h21hrtzU1XL-0m+BG5TYZvVh8WN6hgcM7CV5taHyq2MsR5dw@mail.gmail.com> (raw)
In-Reply-To: <20190821140815.GA1447@localhost>
Hi Richard,
On Wed, 21 Aug 2019 at 17:08, Richard Cochran <richardcochran@gmail.com> wrote:
>
> On Tue, Aug 20, 2019 at 09:38:45PM -0700, Richard Cochran wrote:
> > Overall, the PTP switch use case is well supported by Linux. The
> > synchronization of the management CPU to the PTP, while nice to have,
> > is not required to implement a Transparent Clock. Your specific
> > application might require it, but honestly, if the management CPU
> > needs good synchronization, then you really aught to feed a PPS from
> > the switch into a gpio (for example) on the CPU.
>
> Another way to achieve this is to have a second MAC interface on the
> management CPU connected to a spare port on the switch. Then time
> stamping, PHC, ptp4l, and phc2sys work as expected.
>
> Thanks,
> Richard
Of course PPS with a dedicated hardware receiver that can take input
compare timestamps is always preferable. However non-Ethernet
synchronization in the field looks to me like "make do with whatever
you can". I'm not sure a plain GPIO that raises an interrupt is better
than an interrupt-driven serial protocol controller - it's (mostly)
the interrupts that throw off the precision of the software timestamp.
And use Miroslav's pps-gpio-poll module and you're back from where you
started (try to make a sw timestamp as precise as possible).
As for dedicating a second interface pair in (basically) loopback just
for sync, that's how I'm testing PTP when I don't have a second board
and hence how the idea occurred to me. I can imagine this even getting
deployed and I can also probably name an example, but it certainly
wouldn't be my first choice. But DSA could have that built-in, and
with the added latency benefit of a MAC-to-MAC connection.
Too bad the mv88e6xxx driver can't do loopback timestamping, that's
already 50% of the DSA drivers that support PTP at all. An embedded
solution for this is less compelling now.
Regards,
-Vladimir
next prev parent reply other threads:[~2019-08-21 20:17 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-18 18:25 [PATCH spi for-5.4 0/5] Deterministic SPI latency with NXP DSPI driver Vladimir Oltean
2019-08-18 18:25 ` [PATCH spi for-5.4 1/5] spi: Use an abbreviated pointer to ctlr->cur_msg in __spi_pump_messages Vladimir Oltean
2019-08-20 18:21 ` Mark Brown
2019-08-20 19:36 ` Vladimir Oltean
2019-08-21 11:01 ` Mark Brown
2019-08-18 18:25 ` [PATCH spi for-5.4 2/5] spi: Add a PTP system timestamp to the transfer structure Vladimir Oltean
2019-08-22 17:11 ` Mark Brown
2019-08-24 12:38 ` Vladimir Oltean
2019-08-27 19:01 ` Mark Brown
2019-08-18 18:25 ` [PATCH spi for-5.4 3/5] spi: spi-fsl-dspi: Use poll mode in case the platform IRQ is missing Vladimir Oltean
2019-08-22 17:38 ` Mark Brown
2019-08-18 18:25 ` [PATCH spi for-5.4 4/5] spi: spi-fsl-dspi: Implement the PTP system timestamping for TCFQ mode Vladimir Oltean
2019-08-18 18:26 ` [PATCH spi for-5.4 5/5] spi: spi-fsl-dspi: Disable interrupts and preemption during poll mode transfer Vladimir Oltean
2019-08-20 15:57 ` [PATCH spi for-5.4 0/5] Deterministic SPI latency with NXP DSPI driver Vladimir Oltean
2019-08-20 16:57 ` Andrew Lunn
2019-08-21 4:38 ` Richard Cochran
2019-08-21 14:08 ` Richard Cochran
2019-08-21 20:17 ` Vladimir Oltean [this message]
2019-08-22 14:16 ` Richard Cochran
2019-08-22 14:56 ` Andrew Lunn
2019-08-22 14:58 ` Vladimir Oltean
2019-08-22 16:05 ` Richard Cochran
2019-08-22 16:13 ` Vladimir Oltean
2019-08-23 5:22 ` Richard Cochran
2019-08-24 12:13 ` Vladimir Oltean
2019-08-22 16:10 ` Richard Cochran
2019-08-21 4:42 ` 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=CA+h21hrtzU1XL-0m+BG5TYZvVh8WN6hgcM7CV5taHyq2MsR5dw@mail.gmail.com \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=broonie@kernel.org \
--cc=f.fainelli@gmail.com \
--cc=h.feurstein@gmail.com \
--cc=linux-spi@vger.kernel.org \
--cc=mlichvar@redhat.com \
--cc=netdev@vger.kernel.org \
--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).