Hi Richard, Thanks for pointing me towards the timerqueue implementation. That certainly made the job easier.
I have modified the PTP module to support the POSIX timer interface, supporting an arbitrary number of timers chained off a single hardware timer as discussed. I have implemented this feature in the igb driver (for starters), and plan to add this to the Freescale FEC driver next. I will submit a patch to this mailing list, my first linux patch so please let me know if it’s not in the correct format etc. I have been working against 4.8-rc4, would you prefer I submit a patch against a different branch? Thanks, Kieran. > On 31 Aug 2016, at 20:32, Richard Cochran <[email protected]> wrote: > > On Wed, Aug 31, 2016 at 11:01:59AM +0100, Kieran Tyrrell wrote: >> I started to hack in alarm/timer functionality via an ioctl, but >> while getting familiar with the code I decided it wouldn’t be too >> much extra work to ‘do it properly’ and implement the alarms using >> the posix timer interface (which is how I assume you imagined it >> working). > > Yes, and I agree that the proper way won't be that much extra. > >> - the number of posix timers that can be created is limited to the >> number of hardware timers available on the device. For example on >> the i210 this would be two (assuming that no periodic output >> signal is running simultaneously). > > No, not like this. Think about the normal timers using the Linux > system clock. They all share one timer interrupt source (or actually > there can be one timer per CPU.) > >> - the number of posix timers that can be created is unlimited, with >> the driver using only one hardware timer. The driver sets the >> ‘earliest to fire’ time in hardware, and when it fires it sets up >> the next earliest. > > Yes. > >> If the latter, do you see the timer ‘queuing’ functionality best >> implemented in the PTP module, or left to the ethernet driver? (in >> which case each driver could implement timers either way). > > Almost everything can and should be done in the PHC subsystem. For > the queue, there is a ready to use red-black tree implementation in > lib/timerqueue.c. The driver should only handle the HW specific > details of arming and disabling the interrupt. You'll have to invent > the functional interface between the drivers and the subsystem. You > can look at the clock_event_device (include/linux/clockchips.h) for > inspiration. I expect the PHC interface can be much simpler. > > The hard part is considering the corner case such as cancellation and > what happens when a new deadline cannot be programmed reliably in > time. > >> I’d be keen to hear your opinion as I’d like to submit the patches >> if it all works as planned. > > I think this feature would be nice to have, and I am willing to test > and review it. The patches will have to go eventually through the > netdev tree and undergo review on netdev and lkml. > > BTW, the i210 is ok for testing, but you may be disappointed with the > real time latency. Just reading out a register over PCIe can take > around 6 microseconds, and that is in addition to other overhead such > as signal delivery and process wake up. PHC devices with direct > register access (like gianfar PPC or the imx6) are more attractive for > this use case. For the i210, I would expect that using phc2sys and > the normal timers will provide better real time performance. > > Thanks, > Richard ------------------------------------------------------------------------------ _______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
