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
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
