The latency from software responding to the timer and then firing an event
on a gpio would be eliminated.
No, the latency increases when using PHC. That is the whole point.
In the scenario I am describing, a hardware event is fired immediately
when the PHC timer expires in hardware. That hardware event is akin to
asserting the interrupt in hardware, in that it is an immediate response
to the timer expiration. The event would have already happened in
hardware by the time software responds to it. (To be clear, I am not
proposing using the phc timer and having software fire a gpio after
timer expiration.)
The latency in notifying the user of the timer expiration is
unavoidable. As already proven, that latency is worse using PHC.
However, being able to program a PHC timer would be useful in a custom
PTP clock on an FPGA where timer expiration would both assert the
interrupt and fire an event in hardware simultaneously.
To ask another way, would a kernel patch for PHC timers stand a chance
at approval even if the performance/latency benefits of using PHC timers
aren't convincing compared to system timers.
Thanks,
Alex
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel