lkml.org 
[lkml]   [2021]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH net-next] ptp: add vclock timestamp conversion IOCTL
From
Date
On Wed, 2021-10-13 at 10:54 -0700, Richard Cochran wrote:
> On Wed, Oct 13, 2021 at 03:28:12PM +0200, Sebastien Laveze wrote:
> > On Wed, 2021-10-13 at 06:10 -0700, Richard Cochran wrote:
> > > That means no control over the phase of the output signals. Super.
> >
> > You have. There's just a small conversion to go from and to the low-
> > level hardware counter. (Which also needs to be done for rx/tx
> > timestamps btw)
> > When programming an output signal you use this offset to have the right
> > phase.
>
> I have an i210 with 2 periodic output channels. How am I supposed to
> generate signals from two different virtual PTP clocks?

Is it something currently supported to generate output signals from
virtual clocks ? (I would say no)

It seems to me that any periodic signal handled in hardware (scheduled
traffic for instance or periodic PPS) the hardware PHC frequency needs
to be adjusted.

For the offset, adjusting the PHC counter is not mandatory but requires
to re-configure any active hardware periodic logic. And here I'm not
saying it comes free. (especially if it would have to be supported by
all devices with PHC)

In this regard, we think that the capability to allow PHC adjustements
with virtual clocks may be on a per driver basis:
-driver exposes if it can make atomic offset adjustment or not
-if yes, allow PHC freq adjustments with a limited range. This range
can be known by userspace using PTP_CLOCK_GETCAPS. This limitation
doesn't have to be drastic but just here to prevent 10^6 ppm.

A limited adjustment remains an improvement vs no adjustment at all.

Thanks,
Sebastien

\
 
 \ /
  Last update: 2021-10-14 15:28    [W:0.859 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site