From: Vladimir Oltean <olteanv@gmail.com>
To: f.fainelli@gmail.com, vivien.didelot@gmail.com, andrew@lunn.ch,
davem@davemloft.net, richardcochran@gmail.com,
john.stultz@linaro.org, tglx@linutronix.de, sboyd@kernel.org
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Vladimir Oltean <olteanv@gmail.com>
Subject: [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver
Date: Wed, 29 May 2019 02:56:22 +0300 [thread overview]
Message-ID: <20190528235627.1315-1-olteanv@gmail.com> (raw)
This patchset adds the following:
- A timecounter/cyclecounter based PHC for the free-running
timestamping clock of this switch.
- A state machine implemented in the DSA tagger for SJA1105, which
keeps track of metadata follow-up Ethernet frames (the switch's way
of transmitting RX timestamps).
- Some common-sense on whether or not frames should be timestamped was
taken out of the mv88e6xxx driver (the only other DSA driver with PTP
support) and moved to the generic framework. An option was also
added for drivers to override these common-sense decisions, and
timestamp some more frames. This was the path of least resistance
after implementing the aforementioned state machine - metadata
follow-up frames need to be tracked anyway even if only to discard
them and not pass them up the network stack. And since the switch
can't just be told to timestamp only what the kernel wants (PTP
frames), simply use all the timestamps it provides.
- A generic helper in the timecounter/cyclecounter code for
reconstructing partial PTP timestamps, such as those generated by the
SJA1105.
Not all is rosy, though.
PTP timestamping will only work when the ports are bridged. Otherwise,
the metadata follow-up frames holding RX timestamps won't be received
because they will be blocked by the master port's MAC filter. Linuxptp
tries to put the net device in ALLMULTI/PROMISC mode, but DSA doesn't
pass this on to the master port, which does the actual reception.
The master port is put in promiscous mode when the slave ports are
enslaved to a bridge.
Also, even with software-corrected timestamps, one can observe a
negative path delay reported by linuxptp:
ptp4l[55.600]: master offset 8 s2 freq +83677 path delay -2390
ptp4l[56.600]: master offset 17 s2 freq +83688 path delay -2391
ptp4l[57.601]: master offset 6 s2 freq +83682 path delay -2391
ptp4l[58.601]: master offset -1 s2 freq +83677 path delay -2391
Without investigating too deeply, this appears to be introduced by the
correction applied by linuxptp to t4 (t4c: corrected master rxtstamp)
during the path delay estimation process (removing the correction makes
the path delay positive). This does not appear to have an obvious
negative effect upon the synchronization.
Lastly, clock manipulations on the actual hardware PTP clock will have
to be implemented anyway, for the TTEthernet block and the time-based
ingress policer.
Vladimir Oltean (5):
timecounter: Add helper for reconstructing partial timestamps
net: dsa: sja1105: Add support for the PTP clock
net: dsa: mv88e6xxx: Let taggers specify a can_timestamp function
net: dsa: sja1105: Add support for PTP timestamping
net: dsa: sja1105: Increase priority of CPU-trapped frames
drivers/net/dsa/mv88e6xxx/hwtstamp.c | 25 +-
drivers/net/dsa/mv88e6xxx/hwtstamp.h | 4 +-
drivers/net/dsa/sja1105/Kconfig | 7 +
drivers/net/dsa/sja1105/Makefile | 1 +
drivers/net/dsa/sja1105/sja1105.h | 30 ++
.../net/dsa/sja1105/sja1105_dynamic_config.c | 2 +
drivers/net/dsa/sja1105/sja1105_main.c | 272 ++++++++++++-
drivers/net/dsa/sja1105/sja1105_ptp.c | 357 ++++++++++++++++++
drivers/net/dsa/sja1105/sja1105_ptp.h | 48 +++
drivers/net/dsa/sja1105/sja1105_spi.c | 28 ++
.../net/dsa/sja1105/sja1105_static_config.c | 59 +++
.../net/dsa/sja1105/sja1105_static_config.h | 10 +
include/linux/dsa/sja1105.h | 15 +
include/linux/timecounter.h | 7 +
include/net/dsa.h | 6 +-
kernel/time/timecounter.c | 33 ++
net/dsa/dsa.c | 25 +-
net/dsa/slave.c | 20 +-
net/dsa/tag_sja1105.c | 135 ++++++-
19 files changed, 1043 insertions(+), 41 deletions(-)
create mode 100644 drivers/net/dsa/sja1105/sja1105_ptp.c
create mode 100644 drivers/net/dsa/sja1105/sja1105_ptp.h
--
2.17.1
next reply other threads:[~2019-05-28 23:59 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-28 23:56 Vladimir Oltean [this message]
2019-05-28 23:56 ` [PATCH net-next 1/5] timecounter: Add helper for reconstructing partial timestamps Vladimir Oltean
2019-05-29 2:14 ` John Stultz
2019-05-29 4:40 ` Richard Cochran
2019-05-29 20:23 ` Vladimir Oltean
2019-05-28 23:56 ` [PATCH net-next 2/5] net: dsa: sja1105: Add support for the PTP clock Vladimir Oltean
2019-05-28 23:56 ` [PATCH net-next 3/5] net: dsa: mv88e6xxx: Let taggers specify a can_timestamp function Vladimir Oltean
2019-05-29 4:49 ` Richard Cochran
2019-05-29 20:33 ` Vladimir Oltean
2019-05-30 3:51 ` Richard Cochran
2019-05-30 7:42 ` Vladimir Oltean
2019-05-30 14:23 ` Richard Cochran
2019-05-30 14:40 ` Richard Cochran
2019-05-30 14:47 ` Vladimir Oltean
2019-05-30 15:01 ` Richard Cochran
2019-11-19 11:35 ` Design issue in DSA RX timestamping (Was "Re: [PATCH net-next 3/5] net: dsa: mv88e6xxx: Let taggers specify a can_timestamp function") Vladimir Oltean
2019-11-19 14:03 ` Richard Cochran
2019-05-28 23:56 ` [PATCH net-next 4/5] net: dsa: sja1105: Add support for PTP timestamping Vladimir Oltean
2019-05-28 23:56 ` [PATCH net-next 5/5] net: dsa: sja1105: Increase priority of CPU-trapped frames Vladimir Oltean
2019-05-29 4:52 ` [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver Richard Cochran
2019-05-29 20:41 ` Vladimir Oltean
2019-05-30 3:45 ` Richard Cochran
2019-05-30 9:01 ` Vladimir Oltean
2019-05-30 14:30 ` Richard Cochran
2019-05-30 14:57 ` Vladimir Oltean
2019-05-30 15:05 ` Richard Cochran
2019-05-30 15:23 ` Vladimir Oltean
2019-05-31 4:34 ` Richard Cochran
2019-05-31 13:23 ` Vladimir Oltean
2019-05-31 14:08 ` Richard Cochran
2019-05-31 14:27 ` Vladimir Oltean
2019-05-31 15:11 ` Richard Cochran
2019-05-31 15:21 ` Richard Cochran
2019-05-31 15:23 ` Vladimir Oltean
2019-05-31 16:09 ` Richard Cochran
2019-05-31 16:16 ` Vladimir Oltean
2019-05-31 18:12 ` Vladimir Oltean
2019-06-01 5:07 ` Richard Cochran
2019-06-01 10:31 ` Vladimir Oltean
2019-06-01 12:06 ` Vladimir Oltean
2019-06-02 2:18 ` Richard Cochran
2019-06-02 2:17 ` Richard Cochran
2019-06-01 5:03 ` 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=20190528235627.1315-1-olteanv@gmail.com \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.com \
--cc=sboyd@kernel.org \
--cc=tglx@linutronix.de \
--cc=vivien.didelot@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).