linuxptp-users

[Linuxptp-users] MPC8308rdb

[Chris L. <cl...@gm...>]

Hello

I am using buildroot 2013.02 and have a working system. I have been trying
to use the testptp application to verify operation of the 1588 pps, alarm,
and trigger interface. The code compiles and executes. I get the ptp
capabilities listing using "-c" and it is consistent with the data in
/sys/class/ptp/ptp0; alarm=1, external trigger=2, pps = 1, periodic=0.

However, I get an error when I try to set a oneshot or periodic alarm.
"timer_create: Operation not supported". Further, when I enable pps output,
"echo '0 1' > /sys/class/ptp/ptp0/pps_enable", none of the pps pins toggle
though no error is indicated.

Kernel 3.7.1
uclibc 0.9.33.2 with NPTL


As far as I can tell this should work. The one other piece of information I
can offer is that the DAC which drives the VCXO supplyingTSEC_TMR_CLK is
not populated so no external clock is supplied to the interface. This
shouldn't matter as TMRCK is available internally.



What am I missing?

Regards

Chris LaRocque
Virginia, USA

Re: [Linuxptp-users] MPC8308rdb

[Richard C. <ric...@gm...>]

On Mon, Apr 22, 2013 at 12:36:03PM -0400, Chris LaRocque wrote:
> 
> I am using buildroot 2013.02 and have a working system. I have been trying
> to use the testptp application to verify operation of the 1588 pps, alarm,
> and trigger interface. The code compiles and executes. I get the ptp
> capabilities listing using "-c" and it is consistent with the data in
> /sys/class/ptp/ptp0; alarm=1, external trigger=2, pps = 1, periodic=0.
> 
> However, I get an error when I try to set a oneshot or periodic alarm.
> "timer_create: Operation not supported".

The driver says it has one alarm, but that is a bug. An early version
of the patch series did implement one alarm, but that code was
dropped. So the error message is the expected response. Although the
API allows timers, none of the drivers have that implemented.

I will submit a patch to fix the wrong capability result.

> Further, when I enable pps output,
> "echo '0 1' > /sys/class/ptp/ptp0/pps_enable", none of the pps pins toggle
> though no error is indicated.

The 'PPS' here is an interrupt from the ETSEC to the CPU. This
provides a PPS event just like an external GPS would, for
synchronizing the Linux system time to the PTP time.

However, you should see a 1 PPS and a 10000 PPS on the fiper output
pins. Check your datasheet to see if those pins are multiplexed. You
can change the second fiper frequency (but not phase) using the
"fsl,tmr-fiper2" device tree property.

(I never worked with your board, but I did once try the similar
MPC8313, so there might be some gotchas.)

An alternative way to measure the synchronization is to feed an
external PPS (like from the master clock) into the external time stamp
inputs.
 
> As far as I can tell this should work. The one other piece of information I
> can offer is that the DAC which drives the VCXO supplyingTSEC_TMR_CLK is
> not populated so no external clock is supplied to the interface. This
> shouldn't matter as TMRCK is available internally.

Right.

Please check that the clock settings are correct in the device tree
file for your SoC.

> What am I missing?

Sorry about the confusion. Hope this is clear to you now.

Thanks,
Richard

Re: [Linuxptp-users] MPC8308rdb

[Richard C. <ric...@gm...>]

On Mon, Apr 22, 2013 at 07:35:40PM +0200, Richard Cochran wrote:
> On Mon, Apr 22, 2013 at 12:36:03PM -0400, Chris LaRocque wrote:
> > 
> > However, I get an error when I try to set a oneshot or periodic alarm.
> > "timer_create: Operation not supported".
> 
> The driver says it has one alarm, but that is a bug. An early version
> of the patch series did implement one alarm, but that code was
> dropped. So the error message is the expected response. Although the
> API allows timers, none of the drivers have that implemented.
> 
> I will submit a patch to fix the wrong capability result.

May I add your "Reported-by:" tag to the patch, to give you credit in
the Linux commit history?

Thanks,
Richard

Re: [Linuxptp-users] MPC8308rdb

[Chris L. <cl...@gm...>]

On Mon, Apr 22, 2013 at 1:47 PM, Richard Cochran
<ric...@gm...>wrote:

> On Mon, Apr 22, 2013 at 07:35:40PM +0200, Richard Cochran wrote:
> > On Mon, Apr 22, 2013 at 12:36:03PM -0400, Chris LaRocque wrote:
> > >
> > > However, I get an error when I try to set a oneshot or periodic alarm.
> > > "timer_create: Operation not supported".
> >
> > The driver says it has one alarm, but that is a bug. An early version
> > of the patch series did implement one alarm, but that code was
> > dropped. So the error message is the expected response. Although the
> > API allows timers, none of the drivers have that implemented.
> >
> > I will submit a patch to fix the wrong capability result.
>
> May I add your "Reported-by:" tag to the patch, to give you credit in
> the Linux commit history?
>
> Thanks,
> Richard
>

Hello

Could one of you kind folks point me toward the files where the gianfar
timer functionality could or would be implemented?

Was / is there an example or two which would show me the light?

I need to know the magnitude of the task before I take this info to
management.

Thank You

Chris

Re: [Linuxptp-users] MPC8308rdb

[Richard C. <ric...@gm...>]

On Mon, Apr 22, 2013 at 05:18:30PM -0400, Chris LaRocque wrote:
> 
> Could one of you kind folks point me toward the files where the gianfar
> timer functionality could or would be implemented?

- kernel/time/posix-clock.c
- drivers/net/ethernet/freescale/gianfar_ptp.c
 
> Was / is there an example or two which would show me the light?

You can see the original version at

 https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-May/082433.html

but this was before the posix clock idea came along.

> I need to know the magnitude of the task before I take this info to
> management.

Maybe you can just use normal timers using CLOCK_REALTIME or
CLOCK_MONOTONIC?

This what I recommend. PHC timer support has been designed into the
API, but it has not been implemented. There are two reasons why it is
still missing.

First, adding the logic would be a non-trivial exercise (see how the
hrtimer stuff works, to get an idea).

Second, it is doubtful whether having direct PHC timers would perform
much better than just synchronizing the system clock to the PHC, and
using normal timers.

I did a whole paper on that second point, and I am convinced that it
just isn't worth the effort to implement PHC timers. However, I would
support the addition of the code, if you or someone else wants to
develop it.

HTH,
Richard

Re: [Linuxptp-users] MPC8308rdb

[Chris L. <cl...@gm...>]

On Tue, Apr 23, 2013 at 2:00 AM, Richard Cochran
<ric...@gm...>wrote:

> On Mon, Apr 22, 2013 at 05:18:30PM -0400, Chris LaRocque wrote:
> >
> > Could one of you kind folks point me toward the files where the gianfar
> > timer functionality could or would be implemented?
>
> - kernel/time/posix-clock.c
> - drivers/net/ethernet/freescale/gianfar_ptp.c
>
> > Was / is there an example or two which would show me the light?
>
> You can see the original version at
>
>  https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-May/082433.html
>
> but this was before the posix clock idea came along.
>
> > I need to know the magnitude of the task before I take this info to
> > management.
>
> Maybe you can just use normal timers using CLOCK_REALTIME or
> CLOCK_MONOTONIC?
>
> This what I recommend. PHC timer support has been designed into the
> API, but it has not been implemented. There are two reasons why it is
> still missing.
>
> First, adding the logic would be a non-trivial exercise (see how the
> hrtimer stuff works, to get an idea).
>
> Second, it is doubtful whether having direct PHC timers would perform
> much better than just synchronizing the system clock to the PHC, and
> using normal timers.
>
> I did a whole paper on that second point, and I am convinced that it
> just isn't worth the effort to implement PHC timers. However, I would
> support the addition of the code, if you or someone else wants to
> develop it.
>
> HTH,
> Richard
>
Thank You

I have already looked into the hrtimer source and also found the
discussions you had back in 2010 about the API. Of course I have also read
your paper. If we were just syncing the clocks I'd be done.

Unfortunately, I had counted on the alarm output to drive data acquisition
within our distributed system. I am now investigating timers and gpio to
accomplish the same goal; as long as the triggers will generate and queue
the timestamps the project will succeed. I'm just not as far along as I had
believed.

Your comment about multiplexing of the pin function is apropos. I should
have recognized something was amiss when TSEC_TMR_GCLK was not present on
the 1588 header. I am looking into where the changes to the config register
should be accomplished.

What would really be convenient is if I can get the tigger input to start
one of the fiper which would then toggle an alarm pin in one of two modes:
oneshot or periodic at an arbitrary interval; without interupting the
processor. I need time stamping of events occuring at rates of 1 kHz or
greater.

Pointers appreciated.

Regards Chris

Re: [Linuxptp-users] MPC8308rdb

[Richard C. <ric...@gm...>]

On Tue, Apr 23, 2013 at 08:16:22AM -0400, Chris LaRocque wrote:
> 
> What would really be convenient is if I can get the tigger input to start
> one of the fiper which would then toggle an alarm pin in one of two modes:
> oneshot or periodic at an arbitrary interval; without interupting the
> processor. I need time stamping of events occuring at rates of 1 kHz or
> greater.

I am not too sure what you meant, but I think the external triggers
(time stamping external signals) should be working fine on your
board. The external time stamps are held in a buffer of size 128,
see drivers/ptp/ptp_private.h. If your application cannot read out all
of the 1+ kHz time stamps on time, then you can increase the hard
coded buffer size.

As far as the fipers go, I think you could fairly easily add an ioctl
to turn them on and off again (or abuse the existing ptp ioctls).
However, the fipers are always in phase with the clock, and the
interval must be an exactly divide 1 Hz (ie integer Hz values only).

It might in fact be possible to program the fipers for arbitrary
periods and phases, but I never figured out how to do it. It was hard
enough getting the 1 Hz and 10 kHz signals working. Freescale's
documents are a bit weak and their tech support is even worse, in my
experience.

HTH,
Richard