Hello Maxime, On Fri, Mar 24, 2023 at 11:25:41AM +0100, Maxime Chevallier wrote: > I'd like to point out a series sent a while ago : > > https://lore.kernel.org/netdev/3a14f417-1ae1-9434-5532-4b3387f25d18@xxxxxxxxxx/ > > Here, the MAC's timestamping unit can be configured in 2 ways, which > boils down to either more accurate timestamps, or better accuracy in > frequency adjustments for the clock. > > The need is to be able to change this mode at runtime, as we can change > the clock source for the timestamping unit to a very precise-one, > therefore using the "accurate timestamps mode" working as a > grand-master, or switching to slave mode, where we would sacrifice a > little bit the timestamping precision to get better frequency > precision. > > So, we can consider here that not only the MAC's timestamping unit has > a non-fixed precision, but if we go through the route a a new API, > maybe we can also take this case into account, allowing for a bit of > configuration of the timestamping unit from userspace? How would you suggest that this API looks like, what would be there to configure on the timestamping unit? You're not looking for something specific like "fine vs coarse" to be accepted, I hope? Perhaps the stmmac is patched to expose 2 PHCs, one for fine mode and one for coarse mode, and the timestamping PHC selection enables one more or the other? In other words, if we expressed this stmmac specific thing in vendor-agnostic terminology that we already understand, would that work? The ability of a single MAC to register 2 PHCs might be useful for TSN switches as well. Long story short, sometimes those expose a free running clock (uncorrectable in offset and frequency), as well as a correctable one, and they give the option for PTP hardware timestamps to sample one clock or the other. TSN offloads (tc-taprio, tc-gate etc) always use the correctable clock, and 802.1AS / gPTP has the option to use the free running clock. I'm not interested in this personally, but there were some talks about the value of doing this some time ago, and I thought it would be worth mentioning it in this context, as something else that could benefit from a more generic UAPI. > > Is it plausible that over time, when PTP timestamping matures and, > > for example, MDIO devices get support for PTP_SYS_OFFSET_EXTENDED > > (an attempt was here: https://lkml.org/lkml/2019/8/16/638), the > > relationship between PTP clock qualities changes, and so does the > > preference change? > > I'm not exactly familiar with PTP_SYS_OFFSET_EXTENDED, but it looks a > bit similar in purpose to the above-mentionned use-case. Nope, not similar at all.
