Discussion:
[Linuxptp-users] one-shot alarm
Kieran Tyrrell
2016-08-22 14:50:37 UTC
Permalink
Hi,

I would like to use the one-shot alarm feature of the PHC on an i.MX6. The i.MX6 hardware can support this, but I notice it’s not supported by the Freescale/NXP drivers.

testptp -c reports 0 programmable alarms, and the source code confirms this.

I have been looking through the Freescale fec driver sources and linux kernel sources with a view to implementing this, but came up against a block because at the kernel level struct ptp_clock_info (ptp_clock_kernel.h) doesn’t contain a function pointer for a ‘set one shot timer’ function, and drivers/ptp/ptp_clock.c doesn’t seem to do anything with the PTP_CLOCK_ALARM event anyway (the ptp_clock_event function just has a stubbed switch statement for PTP_CLOCK_ALARM).

So my questions:
- is the one-shot alarm functionality of the PHC actually implemented in any driver?
- 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)

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

Thanks,

Kieran.


------------------------------------------------------------------------------
Richard Cochran
2016-08-22 15:34:43 UTC
Permalink
Post by Kieran Tyrrell
- is the one-shot alarm functionality of the PHC actually implemented in any driver?
No.
Post by Kieran Tyrrell
- 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.
Post by Kieran Tyrrell
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
covered by:

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

------------------------------------------------------------------------------
Dale Smith
2016-08-22 16:39:10 UTC
Permalink
Post by Kieran Tyrrell
Post by Kieran Tyrrell
- is the one-shot alarm functionality of the PHC actually implemented in
any driver?
No.
Post by Kieran Tyrrell
- 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.
There are (currently) unused flag bits and the structures are padded out
with extra reserved fields. It's possible to abuse these fields to
implement whatever you need. You still need to modify the FEC (or
whatever) driver, but at least you don't need to plumb the changes all
throughout the whole kernel.

I'm not really recommending you do this, especially if this is for general
purpose use. But if you really need to have a HW alarm go off with ns
resolution, this is one way to make it happen. (Yes, I needed to to
exactly that)

Richard, thanks for having the forethought to add those extra fields!

-Dale
Kieran Tyrrell
2016-08-23 10:36:44 UTC
Permalink
Thanks Richard and Dale for the fast replies.

I see that it should be possible to use the ptp_feature_enable function to pass in an alarm time, and then when the alarm fires, use the EXTTS event mechanism to pass a notification/event back to the app. Hopefully this will suffice for our application.

Thanks, Kieran.
Post by Richard Cochran
Post by Kieran Tyrrell
- is the one-shot alarm functionality of the PHC actually implemented in any driver?
No.
Post by Kieran Tyrrell
- 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.
There are (currently) unused flag bits and the structures are padded out with extra reserved fields. It's possible to abuse these fields to implement whatever you need. You still need to modify the FEC (or whatever) driver, but at least you don't need to plumb the changes all throughout the whole kernel.
I'm not really recommending you do this, especially if this is for general purpose use. But if you really need to have a HW alarm go off with ns resolution, this is one way to make it happen. (Yes, I needed to to exactly that)
Richard, thanks for having the forethought to add those extra fields!
-Dale
Loading...