Hi Jacob,
On Mon, Jul 06, 2020 at 10:11:12AM -0700, Jacob Keller wrote:
>
>
> On 6/26/2020 5:55 AM, Richard Cochran wrote:
> > On Fri, Jun 26, 2020 at 01:15:11PM +0300, Vladimir Oltean wrote:
> >
> >> So, to your point: I didn't see any driver that _rejects_ time in the
> >> past. If it works, I don't know. If it doesn't work, I would do the
> >> time fixup at driver level, so in my opinion there's no need for an
> >> application-level flag. What do you think?
> >
> > I agree with your analysis. Ideally the drivers would handle this
> > perfectly.** But even if they could, still it will take months, maybe
> > years to fix all the kernel drivers. Moreover, the user space stack
> > would still need to work with the "legacy" kernels.
> >
> > So I think it will have to be a flag.
> >
> > Thanks,
> > Richard
> >
> >
> > ** Without hardware support, it is actually quite tricky to solve the
> > race condition in software in a way which is 100% reliable. You
> > are correct that setting the start time even a whole second in the
> > future might not be enough on a non-preempt_rt kernel.
> >
> > Regarding the start=0 for HW without start time control, this is
> > not an ideal interface. I would like to have a proper "frequency
> > output" or "clock output" ABI in the PHC world. If you have the
> > time, maybe this is something you like to work on?
> >
>
> This would be useful. I know some of the Intel hardware can do "start
> time" but not all of them can, and it usually takes up more resources
> because we have to tie both a periodic output function and a start
> trigger function to the setup.
>
> Thanks,
> Jake
What modification do you think should be done to the kernel ABI?
This is what is currently in place:
struct ptp_perout_request {
struct ptp_clock_time start; /* Absolute start time. */
struct ptp_clock_time period; /* Desired period, zero means disable. */
unsigned int index; /* Which channel to configure. */
unsigned int flags;
unsigned int rsv[4]; /* Reserved for future use. */
};
Most interesting to me would be the "flags" field. The v2 of the ioctl
can currently only have:
#define PTP_PEROUT_ONE_SHOT (1<<0)
Maybe something like this?
#define PTP_PEROUT_RELATIVE_START_TIME (1<<1)
with the meaning of 'just set up the clock generator to start ASAP (with
an unspecified definition of ASAP) with this phase offset in
nanoseconds, relative to 0 which corresponds to the closest integer
multiple of the period in the PHC time base'.
What would be the valid range of 'start' in the case where (flags &
PTP_PEROUT_RELATIVE_START_TIME) is set?
- Zero to $('period' - 1) nanoseconds, or
- Zero to infinity, with a modulo performed by somebody (probably the
PTP core)?
Also, there's the question of what to do about the sysfs ABI. Currently
you can't pass the flags through that:
cnt = sscanf(buf, "%u %lld %u %lld %u", &req.perout.index,
&req.perout.start.sec, &req.perout.start.nsec,
&req.perout.period.sec, &req.perout.period.nsec);
if (cnt != 5)
goto out;
Do we want to permit another sscanf for optional flags at the end? Would
the flags be textual or numbers (0, 1, 2, 3)?
Thanks,
-Vladimir
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
