Vadim Fedorenko wrote: > > +/** > > + * idpf_ptp_read_src_clk_reg_direct - Read directly the main timer value > > + * @adapter: Driver specific private structure > > + * @sts: Optional parameter for holding a pair of system timestamps from > > + * the system clock. Will be ignored when NULL is given. > > + * > > + * Return: the device clock time on success, -errno otherwise. > > + */ > > +static u64 idpf_ptp_read_src_clk_reg_direct(struct idpf_adapter *adapter, > > + struct ptp_system_timestamp *sts) > > +{ > > + struct idpf_ptp *ptp = adapter->ptp; > > + u32 hi, lo; > > + > > + /* Read the system timestamp pre PHC read */ > > + ptp_read_system_prets(sts); > > + > > + idpf_ptp_enable_shtime(adapter); > > + lo = readl(ptp->dev_clk_regs.dev_clk_ns_l); > > + > > + /* Read the system timestamp post PHC read */ > > + ptp_read_system_postts(sts); > > + > > + hi = readl(ptp->dev_clk_regs.dev_clk_ns_h); > > + > > + return ((u64)hi << 32) | lo; > > +} > > Am I right that idpf_ptp_enable_shtime() "freezes" the time in clk > registers and you can be sure that no changes will happen while you are > doing 2 transactions? If yes, then what does unfreeze it? Or does it > just copy new values to the registers and they will stay until the next > command?
Yep, these are shadow registers. I guess they remain until overwritten on the next latch.