Merge branch 'Unlock-new-potential-in-SJA1105-with-PTP-system-timestamping'
authorDavid S. Miller <davem@davemloft.net>
Mon, 11 Nov 2019 20:45:31 +0000 (12:45 -0800)
committerDavid S. Miller <davem@davemloft.net>
Mon, 11 Nov 2019 20:45:31 +0000 (12:45 -0800)
commit26285f1359695e94751e01a4755d322af0e74145
treee7c5ea7ba04cf99632c0bfe8ed6ad12b17d38eda
parent7941af9b38fa97f4b800fc7c0a097cc71415df5e
parentaf580ae2dcb250719857b4b7024bd4bb0c2e05fb
Merge branch 'Unlock-new-potential-in-SJA1105-with-PTP-system-timestamping'

Vladimir Oltean says:

====================
Unlock new potential in SJA1105 with PTP system timestamping

The SJA1105 being an automotive switch means it is designed to live in a
set-and-forget environment, far from the configure-at-runtime nature of
Linux. Frequently resetting the switch to change its static config means
it loses track of its PTP time, which is not good.

This patch series implements PTP system timestamping for this switch
(using the API introduced for SPI here:
https://www.mail-archive.com/netdev@vger.kernel.org/msg316725.html),
adding the following benefits to the driver:
- When under control of a user space PTP servo loop (ptp4l, phc2sys),
  the loss of sync during a switch reset is much more manageable, and
  the switch still remains in the s2 (locked servo) state.
- When synchronizing the switch using the software technique (based on
  reading clock A and writing the value to clock B, as opposed to
  relying on hardware timestamping), e.g. by using phc2sys, the sync
  accuracy is vastly improved due to the fact that the actual switch PTP
  time can now be more precisely correlated with something of better
  precision (CLOCK_REALTIME). The issue is that SPI transfers are
  inherently bad for measuring time with low jitter, but the newly
  introduced API aims to alleviate that issue somewhat.

This series is also a requirement for a future patch set that adds full
time-aware scheduling offload support for the switch.
====================

Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>