[Linuxptp-devel] [Linuxptp-users] one-shot alarm

[Kieran Tyrrell]

Hi Richard,

I’m moving this thread to linuxptp-devel, as it’s not really a user question any more…

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).

I am currently working with the igb driver, and already have some of the functionality in, but have a question about how you would prefer the timers to be implemented:
- 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).
- 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.

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).

I’d be keen to hear your opinion as I’d like to submit the patches if it all works as planned.

Thanks, Kieran.

- is the one-shot alarm functionality of the PHC actually implemented in any driver?

No.

- how can I implement this in the freescale FEC driver without
having to modify the kernel? (ptp_clock_kernel.h and
drivers/ptp/ptp_clock.c)

You can't implement this without changing the kernel.

Hopefully I’m missing something and there is a simple way to get the
alarm functionality working.

Unfortunately, you understood the kernel sources well enough. There
is a non-trivial amount of work to implement the timer in the PHC core
code. I decided some time ago that the possible benefit is not worth
the effort required. I would say most use cases can be adequately
1. using a PREEMPT_RT kernel
2. synchronizing the system time from the PHC using phc2sys
3. programming a normal high resolution timer using CLOCK_MONOTONIC or
CLOCK_REALTIME.
Sorry,
Richard

------------------------------------------------------------------------------

[Richard Cochran]

Post by Kieran Tyrrell
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.

Post by Kieran Tyrrell
- 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.)

Post by Kieran Tyrrell
- 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.

Post by Kieran Tyrrell
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.

Post by Kieran Tyrrell
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

------------------------------------------------------------------------------

[Dale Smith]

Greetings All,

I can understand why the Linux devs thought it was unneeded to add an extra
alarm interface to PHC, when the only end result is calling some handler code
some random amount of time later. I think (IMHO) that it's far more important
to be able to wiggle that alarm output line at the specified time. Depending
on the clock HW, that can be as low as single digit ns.

I would be glad to help with this effort in any way I can. I have access to
gianfar and dp83640 clocks.

Thanks,
-Dale

------------------------------------------------------------------------------

[Kieran Tyrrell]

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.

Post by Richard Cochran

Post by Kieran Tyrrell
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.

Post by Kieran Tyrrell
- 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.)

Post by Kieran Tyrrell
- 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.

Post by Kieran Tyrrell
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.

Post by Kieran Tyrrell
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

------------------------------------------------------------------------------