On Tue, Jul 07, 2020 at 08:09:07PM +0300, Sergey Organov wrote: > Vladimir Oltean <olte...@gmail.com> writes: > > > On Tue, Jul 07, 2020 at 07:07:08PM +0300, Sergey Organov wrote: > >> Vladimir Oltean <olte...@gmail.com> writes: > >> > > >> > What do you mean 'no ticking', and what do you mean by 'non-initialized > >> > clock' exactly? I don't know if the fec driver is special in any way, do > >> > you mean that multiple runs of $(phc_ctl /dev/ptp0 get) from user space > >> > all return 0? That is not at all what is to be expected, I think. The > >> > PHC is always ticking. Its time is increasing. > >> > >> That's how it is right now. My point is that it likely shouldn't. Why is > >> it ticking when nobody needs it? Does it draw more power due to that? > >> > >> > What would be that initialization procedure that makes it tick, and > >> > who is doing it (and when)? > >> > >> The user space code that cares, obviously. Most probably some PTP stack > >> daemon. I'd say that any set clock time ioctl() should start the clock, > >> or yet another ioctl() that enables/disables the clock, whatever. > >> > > > > That ioctl doesn't exist, at least not in PTP land. This also addresses > > your previous point. > > struct timespec ts; > ... > clock_settime(clkid, &ts) > > That's the starting point of my own code, and I bet it's there in PTP > for Linux, as well as in PTPD, as I fail to see how it could possibly > work without it. >
This won't stop it from ticking, which is what we were talking about, will it? Thanks, -Vladimir
