On 02.08.2022 09:37:54, Pavel Pisa wrote: > > Hardware TX timestamps are now supported (c.f. supra). > > > > > + info->rx_filters = BIT(HWTSTAMP_FILTER_NONE) | > > > + BIT(HWTSTAMP_FILTER_ALL); > > I am not sure if it is good idea to report support for hardware > TX timestamps by all drivers. Precise hardware Tx timestamps > are important for some CAN applications but they require to be > exactly/properly aligned with Rx timestamps. > > Only some CAN (FD) controllers really support that feature. > For M-CAN and some others it is realized as another event > FIFO in addition to Tx and Rx FIFOs. The mcp251xfd uses the event FIFO to signal TX completion. Timestamps are optional, but always enabled in the mcp251xfd driver. > For CTU CAN FD, we have decided that we do not complicate design > and driver by separate events channel. We have configurable > and possibly large Rx FIFO depth which is logical to use for > analyzer mode and we can use loopback to receive own messages > timestamped same way as external received ones. > > See 2.14.1 Loopback mode > SETTINGS[ILBP]=1. > > in the datasheet > > http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/doc/Datasheet.pdf BTW: the datasheet says: | 3.1.36 RX_DATA | | ... this register must be read by 32 bit access. While there is a section that uses 8-bit accessed on that register: | 2.10.10 Sample code 2 - Frame reception in manual mode (8-bit access) > There is still missing information which frames are received > locally and from which buffer they are in the Rx message format, > but we plan to add that into VHDL design. > > In such case, we can switch driver mode and release Tx buffers > only after corresponding message is read from Rx FIFO and > fill exact finegrain (10 ns in our current design) timestamps > to the echo skb. The order of received messages will be seen > exactly mathing the wire order for both transmitted and received > messages then. Which I consider as proper solution for the > most applications including CAN bus analyzers. > > So I consider to report HW Tx timestamps for cases where exact, > precise timestamping is not available for loopback messages > as problematic because you cannot distinguish if you talk > with driver and HW with real/precise timestamps support > or only dummy implementation to make some tools happy. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature
