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

Reply via email to