[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5412DBB0.9010008@emlix.com>
Date: Fri, 12 Sep 2014 13:40:32 +0200
From: Daniel Glöckner <dg@...ix.com>
To: Richard Cochran <richardcochran@...il.com>,
Christian Riesch <christian.riesch@...cron.at>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: PTP_PEROUT_REQUEST and clock stepping
On 09/12/14 08:33, Richard Cochran wrote:
> On Fri, Sep 12, 2014 at 08:24:49AM +0200, Christian Riesch wrote:
>> Ok, I got it now. So you are suggesting to change the behavior of
>> PTP_PEROUT_REQUEST, aren't you? And break existing applications?
>> Christian
I don't want to change the API. I would just have preferred a slightly
different one.
> I think he wants the periodic output to continue at the same phase and
> frequency, even when you reset the clock time.
>
> However, this is impossible to acheive because the hardware does not
> support it.
You mean the hardware that you know of that currently exists.
I just think it is wrong to place the burden of stopping and starting
the periodic output on the PTP demon. The kernel knows when clock_adjtime
and clock_settime are called and it also knows which periodic outputs
are enabled and how they are configured. We just have to decide on the
correct behavior (respect .start vs. ignore .start once running) to be
implemented.
Taking the Intel i210 as an example, the third option (doing nothing)
would lead to the following behavior:
- If the clock is stepped back, the periodic output stops until the
clock reaches the point when it was adjusted.
- If the clock is stepped forward, the periodic output oscillates at
62,5 MHz to catch up.
Best regards,
Daniel
--
Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11,
Bertha-von-Suttner-Straße 9, 37085 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055
emlix - your embedded linux partner
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists