> > > How expensive is ptp_read_system_prets()? My original suggestion was > > > to unconditionally call it here, and then let the driver overwrite it > > > if it supports finer grained time stamping. MDIO is slow, so as long > > > as ptp_read_system_prets() is not too expensive, i prefer KISS. > > > > > > Andrew > > > > While that works for the pre_ts, it doesn't work for the post_ts (the > > MDIO bus core will unconditionally overwrite the system timestamp from > > the driver). > > Unless you're suggesting to keep the pre_ts unconditional and the > > post_ts under the "if" condition, which is a bit odd. > > According to my tests with a scope (measuring the width between SPI > > transfers with and without the ptp_read_system_*ts calls), two calls > > to ktime_get_real_ts64 amount to around 750 ns on a 1200 MHz Cortex A7 > > core, or around 90 clock cycles. > > 900 clock cycles, my bad.
That is quite a lot. I was just expecting it to read a free running clock and maybe do some unit conversions. 900 cycles suggests it is doing a lot more. So please keep with the idea of the bus driver indicating if it supports the time stamping. But please make it a generic bus->flags, and bit 0 indicating time stamping. At some point in the future, it would be useful to indicate if the bus supports c45, which would be another use of flags. Thanks Andrew