From: Arnd Bergmann <arnd@arndb.de>
To: Richard Cochran <richardcochran@gmail.com>,
john stultz <johnstul@us.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org,
Rodolfo Giometti <giometti@linux.it>,
netdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Krzysztof Halasa <khc@pm.waw.pl>
Subject: Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
Date: Tue, 17 Aug 2010 13:36:29 +0200 [thread overview]
Message-ID: <201008171336.29375.arnd@arndb.de> (raw)
In-Reply-To: <20100817105232.GA9079@riccoc20.at.omicron.at>
On Tuesday 17 August 2010, Richard Cochran wrote:
> On Tue, Aug 17, 2010 at 09:25:55AM +0000, Arnd Bergmann wrote:
> > Another difference is that we generally use ioctl for devices that can
> > be enumerated, while syscalls are for system services that are not tied to
> > a specific device. This argument works both ways for PTP IMHO: On the one
> > hand you want to have a reliable clock that you can use without knowing
> > where it comes from, on the other you might have multiple PTP sources that
> > you need to differentiate.
>
> Yes, I agree. In normal use, there will be only one PTP clock in a
> system. However, for research purposes, it would be nice to have more
> than one.
>
> I've been looking at offering the PTP clock as a posix clock, and it
> is not as hard as I first thought. The PTP clock or clocks just have
> to be registered as one of the posix_clocks[MAX_CLOCKS] in
> posix-timers.c.
Ok sounds good.
> My suggestion would be to reserve three clock ids in time.h,
> CLOCK_PTP0, CLOCK_PTP1, and CLOCK_PTP2. The first one would be the
> same as CLOCK_REALTIME, for SW timestamping, and the other two would
> allow two different PTP clocks at the same time, for the research use
> case.
I don't think there is a point in making exactly two independent sources
available. The clockid_t space is not really limited, so we could define
an arbitrary range of ids for ptp sources that could be used simultaneously,
as long as we have space more more ids with a fixed number.
Would it be reasonable to assume that on a machine with a large number
of NICs, you'd want a separate ptp source for each of them for timestamping?
Or would you preferably define just one source in such a setup?
I think both could be done with the use of class device attributes in
sysfs for configuration. Maybe you can have one CLOCK_PTP value for one
global PTP source and use sysfs to configure which device that is.
If you also need simultaneous access to the specific clocks, you could
have run-time configured clockid numbers in a sysfs attribute for each
ptp class device.
> Using the clock id will bring another advantage, since it will then be
> possible for user space to specify the desired timestamp source for
> SO_TIMESTAMPING.
God point.
Arnd
next prev parent reply other threads:[~2010-08-17 11:36 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-16 11:17 [PATCH v5 0/5] ptp: IEEE 1588 clock support Richard Cochran
2010-08-16 11:17 ` [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks Richard Cochran
2010-08-16 14:26 ` Arnd Bergmann
2010-08-16 19:00 ` Richard Cochran
2010-08-16 19:59 ` Arnd Bergmann
2010-08-17 8:32 ` Richard Cochran
2010-08-17 9:25 ` Arnd Bergmann
2010-08-17 10:52 ` Richard Cochran
2010-08-17 11:36 ` Arnd Bergmann [this message]
2010-08-18 0:40 ` john stultz
2010-08-18 14:04 ` Richard Cochran
2010-08-18 15:02 ` Arnd Bergmann
2010-08-19 9:22 ` Richard Cochran
2010-08-19 12:29 ` Arnd Bergmann
2010-08-19 15:23 ` Ira W. Snyder
2010-08-19 15:48 ` Arnd Bergmann
2010-08-16 19:24 ` john stultz
2010-08-16 19:38 ` john stultz
2010-08-17 8:53 ` Richard Cochran
2010-08-18 0:22 ` john stultz
2010-08-18 7:19 ` Richard Cochran
2010-08-19 0:12 ` john stultz
2010-08-19 5:55 ` Richard Cochran
2010-08-19 12:28 ` Arnd Bergmann
2010-08-19 15:38 ` Richard Cochran
2010-08-23 20:21 ` john stultz
2010-08-27 11:08 ` Richard Cochran
2010-08-27 12:03 ` Arnd Bergmann
2010-08-27 20:56 ` John Stultz
2010-08-27 12:45 ` Alan Cox
2010-08-27 20:14 ` John Stultz
2010-08-23 20:08 ` john stultz
2010-08-24 18:30 ` Stephan Gatzka
2010-08-25 9:40 ` Christian Riesch
2010-08-27 1:57 ` john stultz
2010-08-27 7:57 ` Richard Cochran
2010-08-27 12:41 ` Alan Cox
2010-08-27 14:02 ` Richard Cochran
2010-08-27 14:50 ` Alan Cox
2010-08-27 15:35 ` M. Warner Losh
2010-08-29 13:32 ` Christian Riesch
2010-08-27 12:38 ` Richard Cochran
2010-08-27 13:38 ` Alan Cox
2010-08-27 14:34 ` Richard Cochran
2010-08-27 15:06 ` Alan Cox
2010-08-27 15:21 ` Patrick Loschmidt
2010-08-27 22:30 ` John Stultz
2010-09-06 6:33 ` Richard Cochran
2010-09-21 16:54 ` Stephan Gatzka
2010-09-21 20:47 ` Kyle Moffett
2010-09-22 10:14 ` Richard Cochran
2010-08-16 11:18 ` [PATCH 2/5] ptp: Added a clock that uses the Linux system time Richard Cochran
2010-08-16 11:18 ` [PATCH 3/5] ptp: Added a clock that uses the eTSEC found on the MPC85xx Richard Cochran
2010-08-16 11:18 ` [PATCH 4/5] ptp: Added a clock driver for the IXP46x Richard Cochran
2010-08-16 11:19 ` [PATCH 5/5] ptp: Added a clock driver for the National Semiconductor PHYTER Richard Cochran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201008171336.29375.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=giometti@linux.it \
--cc=johnstul@us.ibm.com \
--cc=khc@pm.waw.pl \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox