Linux mainline fork with MSM8998 patches | https://mainline.space | Currently supported devices:
OnePlus 5/5T, Xiaomi Mi 6, F(x)tec Pro¹ (2019 QX1000 model) & Sony Xperia XZ Premium (UNTESTED!)
0d0bcacc54
Ido Schimmel says: ==================== mlxsw: PTP timestamping support This is the second patchset adding PTP support in mlxsw. Next patchset will add PTP shapers which are required to maintain accuracy under rates lower than 40Gb/s, while subsequent patchsets will add tracepoints and selftests. Petr says: This patch set introduces support for retrieving and processing hardware timestamps for PTP packets. The way PTP timestamping works on Spectrum-1 is that there are two queues associated with each front panel port. When a packet is timestamped, the timestamp is put to one of the queues: timestamps for transmitted packets to one and for received packets to the other. Activity on these queues is signaled through the events PTP_ING_FIFO and PTP_EGR_FIFO. Packets themselves arrive through two traps: PTP0 and PTP1. It is possible to configure which PTP messages should be trapped under which PTP trap. On Spectrum systems, mlxsw will use PTP0 for event messages (which need timestamping), and PTP1 for general messages (which do not). There are therefore four relevant traps: receive of PTP event resp. general message, and receive of timestamp for a transmitted resp. received PTP packet. The obvious point where to put the new logic is a custom listener to the mentioned traps. Besides handling ingress traffic (be in packets or timestamps), the driver also needs to handle timestamping of transmitted packets. One option would be to invoke the relevant logic from mlxsw_core_ptp_transmitted(). However on Spectrum-2, the timestamps are actually delivered through the completion queue, and for that reason this patchset opts to invoke the logic from the PCI code, via core and the driver, to a chip-specific operation. That way the invocation will be done in a place where a Spectrum-2 implementation will have an opportunity to extract the timestamp. As indicated above, the PTP FIFO signaling happens independently from packet delivery. A packet corresponding to any given timestamp could be delivered sooner or later than the timestamp itself. Additionally, the queues are only four elements deep, and it is therefore possible that the timestamp for a delivered packet never arrives at all. Similarly a PTP packet might be dropped due to CPU traffic pressure, and never be delivered even if the corresponding timestamp was. The driver thus needs to hold a cache of as-yet-unmatched SKBs and timestamps. The first piece to arrive (be it timestamp or SKB) is put to this cache. When the other piece arrives, the timestamp is attached to the SKB and that is passed on. A delayed work is run at regular intervals to prune the old unmatched entries. As mentioned above, the mechanism for timestamp delivery changes on Spectrum-2, where timestamps are part of completion queue elements, and all packets are timestamped. All this bookkeeping is therefore unnecessary on Spectrum-2. For this reason, this patchset spends some time introducing Spectrum-1 specific artifacts such as a possibility to register a given trap only on Spectrum-1. Patches #1-#4 describe new registers. Patches #5 and #6 introduce the possibility to register certain traps only on some systems. The list of Spectrum-1 specific traps is left empty at this point. Patch #7 hooks into packet receive path by registering PTP traps and appropriate handlers (that however do nothing of substance yet). Patch #8 adds a helper to allow storing custom data to SKB->cb. Patch #9 adds a call into the PCI completion queue handler that invokes, via core and spectrum code, a PTP transmit handler. (Which also does not do anything interesting yet.) Patch #10 introduces code to invoke PTP initialization and adds data types for the cache of unmatched entries. Patches #11 and #12 implement the timestamping itself. In #11, the PHC spin_locks are converted to _bh variants, because unlike normal PHC path, which runs in process context, timestamp processing runs as soft interrupt. Then #12 introduces the code for saving and retrieval of unmatched entries, invokes PTP classifier to identify packets of interest, registers timestamp FIFO events, and handles decoding and attaching timestamps to packets. Patch #13 introduces a garbage collector for left-behind entries that have not been matched for about a second. In patch #14, PTP message types are configured to arrive as PTP0 (events) or PTP1 (everything else) as appropriate. At this point, the PTP packets start arriving through the traps, but because PTP is disabled and there is no way to enable it yet, they are always just passed to the usual receive path right away. Finally patches #15 and #16 add the plumbing to actually make it possible to enable this code through SIOCSHWTSTAMP ioctl, and to advertise the hardware timestamping capabilities through ethtool. v2: - Patch #12: - In mlxsw_sp1_ptp_fifo_event_func(), post-increment when iterating over PTP FIFO records. - Patch #14: - Change namespace of message type enumerators from MLXSW_ to MLXSW_SP_. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|---|---|---|
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.