On Fri, 23 Aug 2019 at 08:22, Richard Cochran <richardcochran@xxxxxxxxx> wrote: > > On Thu, Aug 22, 2019 at 07:13:12PM +0300, Vladimir Oltean wrote: > > You do think that I understand the problem? But I don't! > > ;^) > > > > And who generates Local_sync_resp? > > > > > > > Local_sync_resp is the same as Local_sync_req except maybe with a > > custom tag added by the switch. Irrelevant as long as the DSA master > > can timestamp it. > > So this is point why it won't work. The time stamping logic in the > switch only recognizes PTP frames. > > Thanks, > Richard So to summarize the pros and cons of a PHC-to-PHC loopback sync: Pros: - At least two orders of magnitude improvement in offset compared to a software timestamping solution, even in the situation where the software timestamp is fully optimized - Does not depend on the availability of PPS hardware - In the case where both MACs support this, the synchronization can simply reuse the DSA link with no dedicated circuitry Cons: - DSA framework for retrieving timestamps would need to be reworked - The solution would have to be implemented in the kernel - A separate protocol from PTP would have to be devised - Not all DSA masters support hardware timestamping. Of those that do, not all may support timestamping generic frames - Not all PTP-capable DSA switches support timestamping generic frames - Not all DSA switches may be able to loop back traffic from their CPU port. I think this is called "hairpinning". - The solution only covers the sync of the top-most switch in the DSA tree. The hairpinning described above would need to be selective as well, not just possible. So at this point, the solution is not generic enough for me to be compelled to prototype it. Taking system clock timestamps in the SPI driver is "good enough". We'll just need to work out a way with Mark that this can be added to the SPI subsystem, given the valid objections already expressed. Thanks, -Vladimir