[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <95DC1AA8EC908B48939B72CF375AA5E3011C94941E@alice.at.omicron.at>
Date: Tue, 1 Mar 2011 19:50:55 +0100
From: Richard Cochran <richard.cochran@...cron.at>
To: "'torbenh'" <torbenh@....de>,
"'Thomas Gleixner'" <tglx@...utronix.de>
CC: "'LKML'" <linux-kernel@...r.kernel.org>,
"'John Stultz'" <john.stultz@...aro.org>,
"'Ingo Molnar'" <mingo@...e.hu>,
"'Peter Zijlstra'" <peterz@...radead.org>
Subject: RE: [patch 00/28] Rework of the PTP support series core code
>> Richard, can you please run that through your testing ? The PTP
>> drivers apply on top of that.
>
>i am a bit puzzled how a software ptp clock would fit into this
>framework. for some avb use-cases we could get away with a ptp clock
>thats only accurate to a few 100us.
>
>from a few quick glances it seems, that if userspace is able to create a
>ptp clock driven by normal timers and the kernel allows for timestamping
>packets using that clock, a modified ptpd could do the trick.
>
>i am not sure, how much of this should be happening in userspace though.
The point of the PHC patch set is to support special hardware clocks.
After much discussion (see the links in the V12 patch set) we have come
up with an API that will work both with software only (ie normal system
time) as well as with hardware clocks.
The application just uses: clockid_t id = CLOCK_REALTIME
if it wants to use software time stamping with the normal system clock.
I have some patches for the ptpd that show how the API works, and I
will be reposting those to the ptpd.sf.net in the next few days.
HTH,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists