mirror of
https://github.com/torvalds/linux.git
synced 2025-12-07 11:56:58 +00:00
6920fa0c76
The DWMAC1000 supports 2 timestamping configurations to configure how frequency adjustments are made to the ptp_clock, as well as the reported timestamp values. There was a previous attempt at upstreaming support for configuring this mode by Olivier Dautricourt and Julien Beraud a few years back [1] In a nutshell, the timestamping can be either set in fine mode or in coarse mode. In fine mode, which is the default, we use the overflow of an accumulator to trigger frequency adjustments, but by doing so we lose precision on the timetamps that are produced by the timestamping unit. The main drawback is that the sub-second increment value, used to generate timestamps, can't be set to lower than (2 / ptp_clock_freq). The "fine" qualification comes from the frequent frequency adjustments we are able to do, which is perfect for a PTP follower usecase. In Coarse mode, we don't do frequency adjustments based on an accumulator overflow. We can therefore have very fine subsecond increment values, allowing for better timestamping precision. However this mode works best when the ptp clock frequency is adjusted based on an external signal, such as a PPS input produced by a GPS clock. This mode is therefore perfect for a Grand-master usecase. Introduce a driver-specific devlink parameter "ts_coarse" to enable or disable coarse mode, keeping the "fine" mode as a default. This can then be changed with: devlink dev param set <dev> name ts_coarse value true cmode runtime The associated documentation is also added. [1] : https://lore.kernel.org/netdev/20200514102808.31163-1-olivier.dautricourt@orolia.com/ Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20251024070720.71174-3-maxime.chevallier@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
105 lines
2.9 KiB
ReStructuredText
105 lines
2.9 KiB
ReStructuredText
Linux Devlink Documentation
|
|
===========================
|
|
|
|
devlink is an API to expose device information and resources not directly
|
|
related to any device class, such as chip-wide/switch-ASIC-wide configuration.
|
|
|
|
Locking
|
|
-------
|
|
|
|
Driver facing APIs are currently transitioning to allow more explicit
|
|
locking. Drivers can use the existing ``devlink_*`` set of APIs, or
|
|
new APIs prefixed by ``devl_*``. The older APIs handle all the locking
|
|
in devlink core, but don't allow registration of most sub-objects once
|
|
the main devlink object is itself registered. The newer ``devl_*`` APIs assume
|
|
the devlink instance lock is already held. Drivers can take the instance
|
|
lock by calling ``devl_lock()``. It is also held all callbacks of devlink
|
|
netlink commands.
|
|
|
|
Drivers are encouraged to use the devlink instance lock for their own needs.
|
|
|
|
Drivers need to be cautious when taking devlink instance lock and
|
|
taking RTNL lock at the same time. Devlink instance lock needs to be taken
|
|
first, only after that RTNL lock could be taken.
|
|
|
|
Nested instances
|
|
----------------
|
|
|
|
Some objects, like linecards or port functions, could have another
|
|
devlink instances created underneath. In that case, drivers should make
|
|
sure to respect following rules:
|
|
|
|
- Lock ordering should be maintained. If driver needs to take instance
|
|
lock of both nested and parent instances at the same time, devlink
|
|
instance lock of the parent instance should be taken first, only then
|
|
instance lock of the nested instance could be taken.
|
|
- Driver should use object-specific helpers to setup the
|
|
nested relationship:
|
|
|
|
- ``devl_nested_devlink_set()`` - called to setup devlink -> nested
|
|
devlink relationship (could be user for multiple nested instances.
|
|
- ``devl_port_fn_devlink_set()`` - called to setup port function ->
|
|
nested devlink relationship.
|
|
- ``devlink_linecard_nested_dl_set()`` - called to setup linecard ->
|
|
nested devlink relationship.
|
|
|
|
The nested devlink info is exposed to the userspace over object-specific
|
|
attributes of devlink netlink.
|
|
|
|
Interface documentation
|
|
-----------------------
|
|
|
|
The following pages describe various interfaces available through devlink in
|
|
general.
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
devlink-dpipe
|
|
devlink-eswitch-attr
|
|
devlink-flash
|
|
devlink-health
|
|
devlink-info
|
|
devlink-linecard
|
|
devlink-params
|
|
devlink-port
|
|
devlink-region
|
|
devlink-reload
|
|
devlink-resource
|
|
devlink-selftests
|
|
devlink-trap
|
|
|
|
Driver-specific documentation
|
|
-----------------------------
|
|
|
|
Each driver that implements ``devlink`` is expected to document what
|
|
parameters, info versions, and other features it supports.
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
am65-nuss-cpsw-switch
|
|
bnxt
|
|
etas_es58x
|
|
hns3
|
|
i40e
|
|
ice
|
|
ionic
|
|
iosm
|
|
ixgbe
|
|
kvaser_pciefd
|
|
kvaser_usb
|
|
mlx4
|
|
mlx5
|
|
mlxsw
|
|
mv88e6xxx
|
|
netdevsim
|
|
nfp
|
|
octeontx2
|
|
prestera
|
|
qed
|
|
sfc
|
|
stmmac
|
|
ti-cpsw-switch
|
|
zl3073x
|