On 01.04.2022 14:57, Andrew Lunn wrote:
On Fri, Apr 01, 2022 at 01:05:19PM +0200, Horatiu Vultur wrote:
Remove the latencies support both from the PHY driver and from the DT.
The IP already has some default latencies values which can be used to get
decent results. It has the following values(defined in ns):
rx-1000mbit: 429
tx-1000mbit: 201
rx-100mbit: 2346
tx-100mbit: 705
So one alternative option here is that ptp4l looks at
/sys/class/net/<ifname>/phydev/phy_id
to identify the PHY, listens to netlink messages to determine the link
speed and then applies the correction itself in user space. That gives
you a pretty generic solution, works for any existing PHY and pretty
much any existing kernel version. And if you want board specific
values you can override them in the ptp4l configuration file.
I think it is good to have both options. If you want PTP4L to compensate
in user-space, do not call the tunable, if you want to HW to compensate,
call the tunable (this is useful both for users using ptp4l and other
ptpimplementations).
If system behaves strange, it is easy to see what delays has been
applied.
We are planning on creating a small proejct, which go through all PHYs
in the current system. It shall check a config file to see if the user
has configured interface specific numbers, then apply them, other wise
see if we have default numbers based on the PHY-ID (like you describe).
Idea is to run this at boot as a one-off. It will apply the adjustments
on all speeds, all capable PHYs regardless of they PHY-Timestamping is
used or not.
BTW: If there is a desire, we can add a flag to this tool which can set
all the delay-values to zero.
Just for the record: It is not that I do not like PTP4L - it is by far
the best PTP implementation I have seen. But I'm keen on having a
solution that also works for non-ptp4l users.
/Allan
