All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Majewski <lukma@denx.de>
To: netdev@vger.kernel.org
Cc: Arun Ramadoss <arun.ramadoss@microchip.com>,
	Vladimir Oltean <olteanv@gmail.com>,
	Oleksij Rempel  <o.rempel@pengutronix.de>,
	Tristram.Ha@microchip.com,
	Richard Cochran <richardcochran@gmail.com>,
	Christian Eggers <ceggers@arri.de>
Subject: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device
Date: Mon, 16 Jun 2025 17:25:01 +0200	[thread overview]
Message-ID: <20250616172501.00ea80c4@wsk> (raw)

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

Dear Community,

As of [1] KSZ drivers support HW timestamping HWTSTAMP_TX_ONESTEP_P2P.
When used with ptp4l (config [2]) I'm able to see that two boards with
KSZ9477 can communicate and one of them is a grandmaster device.

This is OK (/dev/ptp0 is created and works properly).

From what I have understood - the device which supports p2p1step also
supports "older" approaches, so communication with other HW shall be
possible.

Hence the questions:

1. Would it be possible to communicate with beaglebone black (BBB)
connected to the same network?

root@BeagleBone:~# ethtool -T eth0
Hardware Transmit Timestamp Modes:
        off
        on
Hardware Receive Filter Modes:
        none
        ptpv2-event

My board:
# ethtool -T lan3
Hardware Transmit Timestamp Modes:
        off
        onestep-p2p
Hardware Receive Filter Modes:
        none
        ptpv2-l4-event
        ptpv2-l2-event
        ptpv2-event

(other fields are the same)

As I've stated above - onestep-p2p shall also support the "on" mode
from BBB.

The documentation of KSZ9477 states that:
- IEEE 1588v2 PTP and Clock Synchronization
- Transparent Clock (TC) with auto correction update
- Master and slave Ordinary Clock (OC) support
- End-to-end (E2E) or peer-to-peer (P2P)
- PTP multicast and unicast message support
- PTP message transport over IPv4/v6 and IEEE 802.3
- IEEE 1588v2 PTP packet filtering
- Synchronous Ethernet support via recovered clock

which looks like all PTP use cases (and other boards) for HW shall be
supported.

Is this a matter of not (yet) available in-driver support or do I need
to configure linuxptp in different way to have such support?



2. The master clock synchronization and calibration

On one board (grandmaster) (connected to lan3):
[1943.558]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
[1951.091]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
[1951.091]: selected local clock 824f12.fffe.110022 as best master
[1951.091]: port 1: assuming the grand master role

The other board:
[890.003]: port 1 (lan3): new foreign master 824f12.fffe.110022-1
[894.003]: selected best master clock 824f12.fffe.110022
[894.005]: port 1 (lan3): LISTENING to UNCALIBRATED on RS_SLAVE

The phc2sys -m -s lan3 shows some calibration...

CLOCK_REALTIME phc offset        65 s2 freq  -45509 delay 351557
CLOCK_REALTIME phc offset       591 s2 freq  -44964 delay 350475
CLOCK_REALTIME phc offset      -892 s2 freq  -46270 delay 350516
CLOCK_REALTIME phc offset    137456 s2 freq  +91811 delay 733784
CLOCK_REALTIME phc offset   -136987 s2 freq -141395 delay 350676
CLOCK_REALTIME phc offset    -41327 s2 freq  -86831 delay 350216
CLOCK_REALTIME phc offset        66 s2 freq  -57837 delay 350489
CLOCK_REALTIME phc offset     12037 s2 freq  -45846 delay 351854
CLOCK_REALTIME phc offset     12213 s2 freq  -42059 delay 350474
CLOCK_REALTIME phc offset      8984 s2 freq  -41624 delay 349682


but the "fluctuation" is too large to regard it as a "stable" and
precise source.

And probably hence it is "UNCALIBRATED" master clock.

Even more strange - the tshark -i lan3 -Y "ptp" -V

.... 1011 = messageId: Announce Message (0xb)
correction: 0.000000 nanoseconds                     
    correction: Ns: 0 nanoseconds                   
    correctionSubNs: 0 nanoseconds             

.... 0010 = messageId: Peer_Delay_Req Message (0x2)
    correction: 0.000000 nanoseconds
    correction: Ns: 0 nanoseconds
    correctionSubNs: 0 nanoseconds

shows always the correction value of 0 ns.
I do guess that it shall have some (different) values.

Any hints on fixing this problem?


3. Just to mention - I've found rather old conversation regarding PTP
support [3] on KSZ devices (but for KSZ9563)

And it looks like it has already been adopted to minline Linux. 
Am I correct? Or is anything still missing (and hence I do see the two
described above issues)?

Thanks in advance for your help :-)

Links:

[1] -
https://elixir.bootlin.com/linux/v6.16-rc1/source/drivers/net/dsa/microchip/ksz_ptp.c#L293

[2] - config for PTP (/etc/ptp4l.conf):

cat /etc/ptp4l.conf     
[global]

#twoStepFlag 0   ->  set automatically in ptp4l
time_stamping p2p1step
slaveOnly 0/1
delay_mechanism P2P
delay_filter_length 100
tx_timestamp_timeout 100
network_transport L2

[3] -
https://patchwork.ozlabs.org/project/netdev/patch/20201019172435.4416-8-ceggers@arri.de/#2570624

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

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

             reply	other threads:[~2025-06-16 15:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-16 15:25 Lukasz Majewski [this message]
2025-06-17  5:25 ` [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device Oleksij Rempel
2025-06-17  9:53   ` Lukasz Majewski
2025-06-17 16:10   ` Vadim Fedorenko
2025-06-18  5:07     ` Richard Cochran
2025-06-18  6:27       ` Oleksij Rempel
2025-06-26 21:33         ` Lukasz Majewski
2025-06-27 21:58           ` Vladimir Oltean
2025-06-29  9:28             ` Lukasz Majewski
2025-06-30  4:36               ` Oleksij Rempel

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=20250616172501.00ea80c4@wsk \
    --to=lukma@denx.de \
    --cc=Tristram.Ha@microchip.com \
    --cc=arun.ramadoss@microchip.com \
    --cc=ceggers@arri.de \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=olteanv@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.