mbox series

[RFC,net-next,0/7] Add basic SyncE interfaces

Message ID 20210816160717.31285-1-arkadiusz.kubalewski@intel.com (mailing list archive)
Headers show
Series Add basic SyncE interfaces | expand

Message

Arkadiusz Kubalewski Aug. 16, 2021, 4:07 p.m. UTC
SyncE - Synchronous Ethernet is defined in ITU-T Rec. G.8264
(https://www.itu.int/rec/T-REC-G.8264)

SyncE allows synchronizing the frequency of ethernet PHY clock signal
(the frequency used to send the data onto wire), to some reference
clock signal.

Multiple reference clock sources can be available. PHY ports recover
the frequency at which the transmitter sent the data on the RX side.
Alternatively, we can use external sources like 1PPS GPS, etc.

This patch series introduces basic interfaces for communication
with a SyncE capable device.

The first part of the interface allows acquiring the synchronization
state of DPLL (Digital Phase Locked Loop). DPLL LOCKED state means
that the frequency generated by it is locked to the input frequency.
As a result, PHYs connected to it are synchronized to the chosen input
frequency signal.

The second part can be used to select the port from which the clock
gets recovered. Each PHY chip can have multiple pins on which the
recovered clock can be propagated. For example, a SyncE-capable PHY
can recover the carrier frequency of the first port, divide it
internally, and output it as a reference clock on PIN 0.
When such a signal is enabled, the DPLL can LOCK to the frequency
recovered on PIN 0.

Next steps:
 - Add CONFIG_SYNCE definition into Kconfig
 - Add more configuration interfaces. Aiming at devlink, since this
   would be device-wide configuration

Arkadiusz Kubalewski (7):
  ptp: Add interface for acquiring DPLL state
  selftests/ptp: Add usage of PTP_DPLL_GETSTATE ioctl in testptp
  ice: add get_dpll_state ptp interface usage
  net: add ioctl interface for recover reference clock on netdev
  selftests/net: Add test app for SIOC{S|G}SYNCE
  ice: add SIOC{S|G}SYNCE interface usage to recover reference signal
  ice: add sysfs interface to configure PHY recovered reference signal

 .../net/ethernet/intel/ice/ice_adminq_cmd.h   |  62 +++++
 drivers/net/ethernet/intel/ice/ice_common.c   | 101 ++++++++
 drivers/net/ethernet/intel/ice/ice_common.h   |   9 +
 drivers/net/ethernet/intel/ice/ice_main.c     |   4 +
 drivers/net/ethernet/intel/ice/ice_ptp.c      | 234 +++++++++++++++++-
 drivers/net/ethernet/intel/ice/ice_ptp.h      |   9 +
 drivers/net/ethernet/intel/ice/ice_ptp_hw.h   |   6 +
 drivers/ptp/ptp_chardev.c                     |  15 ++
 drivers/ptp/ptp_clockmatrix.h                 |  12 -
 drivers/ptp/ptp_private.h                     |   2 +
 drivers/ptp/ptp_sysfs.c                       |  48 ++++
 include/linux/ptp_clock_kernel.h              |   9 +
 include/uapi/linux/net_synce.h                |  21 ++
 include/uapi/linux/ptp_clock.h                |  27 ++
 include/uapi/linux/sockios.h                  |   4 +
 net/core/dev_ioctl.c                          |   6 +-
 tools/testing/selftests/net/Makefile          |   1 +
 tools/testing/selftests/net/phy_ref_clk.c     | 138 +++++++++++
 tools/testing/selftests/ptp/testptp.c         |  27 +-
 19 files changed, 720 insertions(+), 15 deletions(-)
 create mode 100644 include/uapi/linux/net_synce.h
 create mode 100644 tools/testing/selftests/net/phy_ref_clk.c


base-commit: aba1e4adb54e020d3ca85a4df3ef0f8febe87548

Comments

Richard Cochran Aug. 18, 2021, 5:05 p.m. UTC | #1
On Mon, Aug 16, 2021 at 06:07:10PM +0200, Arkadiusz Kubalewski wrote:

> The second part can be used to select the port from which the clock
> gets recovered. Each PHY chip can have multiple pins on which the
> recovered clock can be propagated. For example, a SyncE-capable PHY
> can recover the carrier frequency of the first port, divide it
> internally, and output it as a reference clock on PIN 0.

This really sounds like its own thing, and not a PHC at all.

> Next steps:
>  - Add CONFIG_SYNCE definition into Kconfig
>  - Add more configuration interfaces. Aiming at devlink, since this
>    would be device-wide configuration

As a first step, finding an appropriate kernel/user space API would be
needed.

Thanks,
Richard
Richard Cochran Aug. 18, 2021, 5:08 p.m. UTC | #2
On Mon, Aug 16, 2021 at 06:07:10PM +0200, Arkadiusz Kubalewski wrote:

> Multiple reference clock sources can be available. PHY ports recover
> the frequency at which the transmitter sent the data on the RX side.
> Alternatively, we can use external sources like 1PPS GPS, etc.

There is a generic PHY subsystem (drivers/phy) used by USB, PCIe, CAN,
and so on.  Why not use that?

Thanks,
Richard