When running ptp4l as a slave I occasionally (every few minutes) get the following error:
ptp4l[556.407]: timed out while polling for tx timestamp
ptp4l[556.408]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
If I do increase tx_timestamp_timeout, the error happens less frequently, but at 10 ms, ten times the default, it still happens.
As I understand it, the tx timpestamp is returned by the SoC itself after sending the delay request message, so it is strange that it should take this much time. I don't wether the ptp4l author means that it is a driver bug when it takes much time, or when the timestamp does not arrive at all. I can see that the timestamp always arrive eventually when this happens by re-polling.
How come it takes so long time to get back the timestamp? Is this a bug? If not, how long should the timeout value be?
My kernel is based on linux 4.14 from LSDK 18.12, and the SoC is LS2044A.