On Tue, Jun 15, 2010 at 12:41:56PM -0600, Grant Likely wrote:
> Nitpick. We use all lower case names for structures in Linux.
Yes, I know, but in this case an exception makes sense.
I prefer to use the exact same register mnemonics as in the hardware
documentation, whenever possible. That way, a
On Tue, Jun 15, 2010 at 12:49:13PM -0600, Grant Likely wrote:
> Won't this break things for existing DP83640 users?
Nope, the driver was only added five patches ago, and it only offers
the timestamping stuff. The standard PHY functions just call the
generic functions, so the PHY works fine even wi
On Tue, Jun 15, 2010 at 11:00:10AM -0600, Grant Likely wrote:
>
> Question from an ignorant reviewer: Why a new interface instead of
> working with the existing high resolution timers infrastructure?
Short answer: Timers are only one part of the PTP API. If you offer
the PTP clock as a Linux clo
On Tue, Jun 29, 2010 at 02:54:17PM -0500, Timur Tabi wrote:
> I'm adding support for a new e500-based board (the P1022DS), and in
> the process I've discovered that enabling CONFIG_NO_HZ (Tickless
> System / Dynamic Ticks) causes significant responsiveness problems on
> the serial console. When I
On Tue, Jun 15, 2010 at 01:11:30PM -0600, Grant Likely wrote:
> On Tue, Jun 15, 2010 at 10:09 AM, Richard Cochran
> > +static DEFINE_SPINLOCK(clocks_lock); /* protects 'clocks' */
>
> Doesn't appear that clocks is manipulated at atomic context. Mutex instead?
...
&
ce deprecated unifdef-y with header-y for user space header file.
- Added links to both of the ptpd patches on sourceforge.
- Gianfar driver now gets parameters from device tree.
- Added API documentation to Documentation/ptp/ptp.txt
Richard Cochran (5):
ptp: Added a brand new class driver
clock.
Signed-off-by: Richard Cochran
---
Documentation/ptp/ptp.txt| 95 +++
Documentation/ptp/testptp.c | 306 ++
Documentation/ptp/testptp.mk | 33 +++
drivers/Kconfig |2 +
drivers/Makefile |1 +
drivers/ptp
This PTP clock simply uses the NTP time adjustment system calls. The
driver can be used in systems that lack a special hardware PTP clock.
Signed-off-by: Richard Cochran
---
drivers/ptp/Kconfig | 12
drivers/ptp/Makefile|1 +
drivers/ptp/ptp_linux.c | 136
The eTSEC includes a PTP clock with quite a few features. This patch adds
support for the basic clock adjustment functions, plus two external time
stamps and one alarm.
Signed-off-by: Richard Cochran
---
Documentation/powerpc/dts-bindings/fsl/tsec.txt | 57 +++
arch/powerpc/boot/dts
This patch adds a driver for the hardware time stamping unit found on the
IXP465. The basic clock operations and an external trigger are implemented.
Signed-off-by: Richard Cochran
---
arch/arm/mach-ixp4xx/include/mach/ixp46x_ts.h | 78 ++
drivers/net/arm/ixp4xx_eth.c
This patch adds support for the PTP clock found on the DP83640.
The basic clock operations and one external time stamp have
been implemented.
Signed-off-by: Richard Cochran
---
drivers/net/phy/Kconfig | 29 ++
drivers/net/phy/Makefile |1 +
drivers/net/phy/dp83640.c | 904
On Mon, Aug 16, 2010 at 04:26:23PM +0200, Arnd Bergmann wrote:
> Have you considered integrating the subsystem into the Posix clock/timer
> framework?
Yes, but see below.
> I can't really tell from reading the source if this is possible or
> not, but my feeling is that if it can be done, that wo
On Mon, Aug 16, 2010 at 09:59:39PM +0200, Arnd Bergmann wrote:
> Why does it matter how long it takes to read the clock? I wasn't thinking
> of replacing the system clock with this, just exposing the additional
> clock as a new clockid_t value that can be accessed using the existing
> syscalls.
Ok
On Mon, Aug 16, 2010 at 12:24:48PM -0700, john stultz wrote:
> 3) I'm not sure I see the benefit of being able to have multiple
> frequency corrected time domains. In other words, what benefit would
> you get from adjusting a PTP clock's frequency instead of just
> adjusting the system's time freq
On Tue, Aug 17, 2010 at 09:25:55AM +, 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
On Tue, Aug 17, 2010 at 05:22:43PM -0700, john stultz wrote:
> Why would system time not be adjusted to the PTP time?
>
> This is my main concern, that we're presenting a fractured API to
> userland. Suddenly there isn't just system time, but ptp time as well,
> and possibly multiple different ptp
On Tue, Aug 17, 2010 at 01:36:29PM +0200, Arnd Bergmann wrote:
> On Tuesday 17 August 2010, Richard Cochran wrote:
> > 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 b
On Wed, Aug 18, 2010 at 05:12:56PM -0700, john stultz wrote:
> On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote:
> > The timer/alarm stuff is "ancillary" and is not at all necessary. It
> > is just a "nice to have." I will happily remove it, if it is to
On Wed, Aug 18, 2010 at 05:02:03PM +0200, Arnd Bergmann wrote:
> You might want to use callbacks for these system calls that you
> can register to at module load time, like it is done for the
> existing syscalls.
Can you point me to a specific example?
> The simpler way (e.g. for testing) is usin
On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote:
> My point was that a syscall is better than an ioctl based interface here,
> which I definitely still think. Given that John knows much more about
> clocks than I do, we still need to get agreement on the question that
> he raised, whi
On Thu, Aug 26, 2010 at 06:57:49PM -0700, john stultz wrote:
> On Wed, 2010-08-25 at 11:40 +0200, Christian Riesch wrote:
> > 2) Master clock:
> > We have one or more network ports. Our system has a really good clock
> > (ovenized quartz crystal, an atomic clock, a GPS timing receiver...)
> > and i
On Mon, Aug 23, 2010 at 01:21:39PM -0700, john stultz wrote:
> On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote:
> > On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote:
> > > My point was that a syscall is better than an ioctl based interface here,
> > &g
On Mon, Aug 23, 2010 at 01:08:45PM -0700, john stultz wrote:
> On Thu, 2010-08-19 at 07:55 +0200, Richard Cochran wrote:
> > The clockid_t CLOCK_PTP will be arch-neutral.
>
> Sure, but are they conceptually neutral? There are other clock
> synchronization algorithms out the
On Fri, Aug 27, 2010 at 01:41:54PM +0100, Alan Cox wrote:
> > The master node in a PTP network probably takes its time from a
> > precise external time source, like GPS. The GPS provides a 1 PPS
> > directly to the PTP clock hardware, which latches the PTP hardware
> > clock time on the PPS edge. T
On Fri, Aug 27, 2010 at 02:38:44PM +0100, Alan Cox wrote:
> > 2007. If we can justify adding a clock id in this case, surely we can
> > add one for PTP as well!
>
> But PTP isn't really a clock - its a time sync protocol. You can (and may
> need to) have multiple clocks of this form on the same ho
On Fri, Aug 27, 2010 at 03:30:39PM -0700, John Stultz wrote:
> On Fri, 2010-08-27 at 14:38 +0200, Richard Cochran wrote:
> > We have not introduced new PPS interface. We use existing PPS subsystem.
>
> Doesn't the pps subsystem have its own way to control the pps signal
On Tue, Sep 21, 2010 at 04:47:45PM -0400, Kyle Moffett wrote:
> Well how about something much more straightforward:
I am about to post another patch set for discussion, so please comment
on it when it appears.
Thanks,
Richard
___
Linuxppc-dev mailing li
1
+/*
+ * PHYSICAL_ID(p->id) ?
+ * TODO - Figure out correct mapping.
+ */
Krzysztof, can you help?
Richard Cochran (8):
posix clocks: introduce a syscall for clock tuning.
posix clocks: dynamic clock ids.
posix clocks: introduce a sysfs presence.
ptp: Added a brand new clas
This patch augments the POSIX clock code to offer a dynamic clock
creation method. Instead of registering a hard coded clock ID, modules
may call create_posix_clock(), which returns a new clock ID.
Signed-off-by: Richard Cochran
---
include/linux/posix-timers.h |7 ++-
include/linux
expanded by one additional mode flag, which allows an
absolute offset correction. When specificied, the clock offset is
immediately corrected by adding the given time value to the current
time value.
Signed-off-by: Richard Cochran
---
arch/arm/include/asm/unistd.h |1 +
arch/arm/kernel
This patch adds a 'timesource' class into sysfs. Each registered POSIX
clock appears by name under /sys/class/timesource. The idea is to
expose to user space the dynamic mapping between clock devices and
clock IDs.
Signed-off-by: Richard Cochran
---
Documentation/ABI/testing/sysfs-
different ways, via
the sysfs and by a character device.
Signed-off-by: Richard Cochran
---
Documentation/ABI/testing/sysfs-ptp | 107 ++
Documentation/ptp/ptp.txt | 94 +
Documentation/ptp/testptp.c | 358
Documentation/ptp
.
Signed-off-by: Richard Cochran
---
drivers/ptp/Kconfig | 14
drivers/ptp/Makefile|1 +
drivers/ptp/ptp_linux.c | 165 +++
kernel/time/ntp.c |2 +
4 files changed, 182 insertions(+), 0 deletions(-)
create mode 100644 drivers
The eTSEC includes a PTP clock with quite a few features. This patch adds
support for the basic clock adjustment functions, plus two external time
stamps, one alarm, and the PPS callback.
Signed-off-by: Richard Cochran
---
Documentation/powerpc/dts-bindings/fsl/tsec.txt | 57 +++
arch/powerpc
This patch adds a driver for the hardware time stamping unit found on the
IXP465. The basic clock operations and an external trigger are implemented.
Signed-off-by: Richard Cochran
---
arch/arm/mach-ixp4xx/include/mach/ixp46x_ts.h | 78 ++
drivers/net/arm/ixp4xx_eth.c
This patch adds support for the PTP clock found on the DP83640.
The basic clock operations and one external time stamp have
been implemented.
Signed-off-by: Richard Cochran
---
drivers/net/phy/Kconfig | 29 ++
drivers/net/phy/Makefile |1 +
drivers/net/phy/dp83640.c | 887
On Wed, Oct 28, 2020 at 03:23:18PM +0100, Mauro Carvalho Chehab wrote:
> diff --git a/Documentation/ABI/testing/sysfs-uevent
> b/Documentation/ABI/testing/sysfs-uevent
> index aa39f8d7bcdf..d0893dad3f38 100644
> --- a/Documentation/ABI/testing/sysfs-uevent
> +++ b/Documentation/ABI/testing/sysfs-
On Sun, May 05, 2019 at 05:02:05AM +, Po Liu wrote:
> Current kernel code do not support the dynamic posix clock alarm set.
> This code would support it by the posix timer structure.
>
> 319 const struct k_clock clock_posix_dynamic = {
>
> 320 .clock_getres = pc_clock_getres,
> 321
On Wed, May 08, 2019 at 03:30:01AM +, Po Liu wrote:
> > Sorry, NAK, since we decided some time ago not to support timer_* operations
> > on dynamic clocks. You get much better application level timer performance
> > by synchronizing CLOCK_REALTIME to your PHC and using clock_nanosleep()
> > wi
On Wed, May 08, 2019 at 07:36:54AM -0700, Richard Cochran wrote:
> No the alarm functionality has been removed. It will not be coming
> back, unless there are really strong arguments to support it.
Here is some more background:
commit 3a06c7ac24f9f24ec059cd77c2dbdf7fbfd0aaaf
101 - 140 of 140 matches
Mail list logo
