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
