Hi Andrew, The 03/08/2022 14:54, Andrew Lunn wrote: > > > > Thanks for the reply, but you did not answer my question: > > > > > > Does this mean the hardware itself cannot tell you it is missing the > > > needed hardware? > > > > > > Don't you have different IDs in register 2 and 3 for those devices with clock > > > register and those without? > > > > > > > > The purpose of this option is, if both PHY and MAC supports > > timestamping then always timestamping is done in PHY. If > > timestamping need to be done in MAC we need a way to stop PHY > > timestamping. If this flag is used then timestamping is taken care > > by MAC. > > This is not a valid use of DT, since this is configuration, not > describing the hardware. There has been recent extension in the UAPI > to allow user space to do this configuration. Please look at that > work. Ah ... now we have found Richard patch series. So we will remove this option and once Richard's patch series will be accepted we will use that. > > > Sorry I answered wrong. Latency values vary depending on the position of PHY in board. > > We have used this PHY in different hardware's, where latency values differs based on PHY positioning. > > So we used latency option in DTS file. > > If you have other ideas or I'm wrong please let me know? > > So this is a function of the track length between the MAC and the PHY? Nope. This latency represents the time it takes for the frame to travel from RJ45 module to the timestamping unit inside the PHY. To be more precisely, the timestamping unit will do the timestamp when it detects the end of the start of the frame. So it represents the time from when the frame reaches the RJ45 to when the end of start of the frame reaches the timestamping unit inside the PHY. And because each board manufacture could put the same PHY but in different places, then each of them would have a different latency. That is the main reason why we put this latencies in the DT and not put them inside the driver. Because we think each board manufacture will need to use different values. Another reason is that we want the board manufacture to determine these values and not the end users. I have seen that also Richard commenting on this, saying that the latencies should not be in DT. Currently I don't know where else they can be. I know that ptp4l has these option in SW to update the ingress/egress latencies but if someone else is running another application, what will they do? > How do you determine these values? This is a little bit more complicated. So first you will need a device that you know already that is calibrated. Then you connect the device that you want to calibrate to the calibrated one with a known length cable. We presume that there is a 5ns delay per meter of the cable. And then basically we run ptp4l on each device where the master will be the calibrated one and the slave will be the device that will be calibrated. When we run ptp4l we can see mean path delay, and we subtract the delay introduced by the cable(5ns) and then we take this value and divided by 2. And then the result is added to the current rx latency and subtracted from tx latency. This is how we have calculated the values. > There is no point having > configuration values if you don't document how to determine what value > should be used. I agree, we should do a better job at this and also explaining what these values represent. Definitely we will do that in the next patch. > > Andrew -- /Horatiu
