netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
@ 2010-04-27  9:13 Richard Cochran
  2010-04-27 10:20 ` Richard Cochran
  2010-04-29 12:02 ` Wolfgang Grandegger
  0 siblings, 2 replies; 17+ messages in thread
From: Richard Cochran @ 2010-04-27  9:13 UTC (permalink / raw)
  To: netdev

Now and again there has been some talk on this list of adding PTP
support into Linux. One part of the picture is already in place, the
SO_TIMESTAMPING API for hardware time stamping. It has been pointed
out that this API is not perfect, however, it is good enough for many
real world uses of IEEE 1588. The second needed part has not, AFAICT,
ever been addressed.

Here I offer an early draft of an idea how to bring the missing
functionality into Linux. I don't yet have all of the features
implemented, as described below. Still I would like to get your
feedback concerning this idea before getting too far into it. I do
have all of the hardware mentioned at hand, so I have a good idea that
the proposed API covers the features of those clocks.

Thanks in advance for your comments,

Richard

* PTP infrastructure for Linux

  This patch set introduces support for IEEE 1588 PTP clocks in
  Linux. Together with the SO_TIMESTAMPING socket options, this
  presents standardized method for developing PTP user space programs,
  synchronizing Linux with external clocks, and using the ancillary
  features of PTP hardware clocks.

  A new class driver exports a kernel interface for specific clock
  drivers and a user space interface. The infrastructure supports a
  complete set of PTP functionality.

  + Basic clock operations
    - Set time
    - Get time
    - Shift the clock by a given offset atomically
    - Adjust clock frequency

  + Ancillary clock features
    - One short or periodic alarms, with signal delivery to user program
    - Time stamp external events
    - Period output signals configurable from user space
    - Synchronization of the Linux system time via the PPS subsystem

** PTP kernel API

   A PTP clock driver registers itself with the class driver. The
   class driver handles all of the dealings with user space. The
   author of a clock driver need only implement the details of
   programming the clock hardware. The clock driver notifies the class
   driver of asynchronous events (alarms and external time stamps) via
   a simple message passing interface.

   The class driver supports multiple PTP clock drivers. In normal use
   cases, only one PTP clock is needed. However, for testing and
   development, it can be useful to have more than one clock in a
   single system, in order to allow performance comparisons.

** PTP user space API

   The class driver creates a character device for each registered PTP
   clock. User space programs may control the clock via standardized
   ioctls. A program may query, enable, configure, and disable the
   ancillary clock features. User space can receive time stamped
   events via blocking read() and poll(). One shot and periodic
   signals may be configured via an ioctl API with similar semantics
   to the POSIX timer_settime() system call.

** Supported hardware

   + Standard Linux system timer
     - No special PTP features
     - For use with software time stamping

   + Freescale eTSEC gianfar
     - 2 Time stamp external triggers, programmable polarity (opt. interrupt)
     - 2 Alarm registers (optional interrupt)
     - 3 Periodic signals (optional interrupt)

   + National DP83640
     - 6 GPIOs programmable as inputs or outputs
     - 6 GPIOs with dedicated functions (LED/JTAG/clock) can also be
       used as general inputs or outputs
     - GPIO inputs can time stamp external triggers
     - GPIO outputs can produce periodic signals
     - 1 interrupt pin

   + Intel IXP465
     - Auxiliary Slave/Master Mode Snapshot (optional interrupt)
     - Target Time (optional interrupt)


Richard Cochran (3):
  ptp: Added a brand new class driver for ptp clocks.
  ptp: Added a clock that uses the Linux system time.
  ptp: Added a clock that uses the eTSEC found on the MPC85xx.

 Documentation/ptp/testptp.c      |  130 +++++++++++++++++
 Documentation/ptp/testptp.mk     |   33 +++++
 drivers/Kconfig                  |    2 +
 drivers/Makefile                 |    1 +
 drivers/net/Makefile             |    1 +
 drivers/net/gianfar_ptp.c        |  269 +++++++++++++++++++++++++++++++++++
 drivers/net/gianfar_ptp_reg.h    |  107 ++++++++++++++
 drivers/ptp/Kconfig              |   51 +++++++
 drivers/ptp/Makefile             |    6 +
 drivers/ptp/ptp_clock.c          |  287 ++++++++++++++++++++++++++++++++++++++
 drivers/ptp/ptp_linux.c          |  119 ++++++++++++++++
 include/linux/Kbuild             |    1 +
 include/linux/ptp_clock.h        |   37 +++++
 include/linux/ptp_clock_kernel.h |  132 +++++++++++++++++
 kernel/time/ntp.c                |    2 +
 15 files changed, 1178 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/ptp/testptp.c
 create mode 100644 Documentation/ptp/testptp.mk
 create mode 100644 drivers/net/gianfar_ptp.c
 create mode 100644 drivers/net/gianfar_ptp_reg.h
 create mode 100644 drivers/ptp/Kconfig
 create mode 100644 drivers/ptp/Makefile
 create mode 100644 drivers/ptp/ptp_clock.c
 create mode 100644 drivers/ptp/ptp_linux.c
 create mode 100644 include/linux/ptp_clock.h
 create mode 100644 include/linux/ptp_clock_kernel.h


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-27  9:13 [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support Richard Cochran
@ 2010-04-27 10:20 ` Richard Cochran
  2010-04-27 13:35   ` Wolfgang Grandegger
  2010-04-29 12:02 ` Wolfgang Grandegger
  1 sibling, 1 reply; 17+ messages in thread
From: Richard Cochran @ 2010-04-27 10:20 UTC (permalink / raw)
  To: netdev

BTW,

To show how the API works from the user space, I also patches For the
popular ptpd program to that project.

   https://sourceforge.net/tracker/?func=detail&aid=2992845&group_id=139814&atid=744634

Richard

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-27 10:20 ` Richard Cochran
@ 2010-04-27 13:35   ` Wolfgang Grandegger
  2010-04-27 16:20     ` Wolfgang Grandegger
  0 siblings, 1 reply; 17+ messages in thread
From: Wolfgang Grandegger @ 2010-04-27 13:35 UTC (permalink / raw)
  To: Richard Cochran; +Cc: netdev

Hi Richard,

Richard Cochran wrote:
> BTW,
> 
> To show how the API works from the user space, I also patches For the
> popular ptpd program to that project.
> 
>    https://sourceforge.net/tracker/?func=detail&aid=2992845&group_id=139814&atid=744634

Cool stuff, I'm giving it a try on my MPC8313 PTP setup.

Thanks.

Wolfgang.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-27 13:35   ` Wolfgang Grandegger
@ 2010-04-27 16:20     ` Wolfgang Grandegger
  2010-04-28  5:47       ` Richard Cochran
  0 siblings, 1 reply; 17+ messages in thread
From: Wolfgang Grandegger @ 2010-04-27 16:20 UTC (permalink / raw)
  To: Richard Cochran; +Cc: netdev

Wolfgang Grandegger wrote:
> Hi Richard,
> 
> Richard Cochran wrote:
>> BTW,
>>
>> To show how the API works from the user space, I also patches For the
>> popular ptpd program to that project.
>>
>>    https://sourceforge.net/tracker/?func=detail&aid=2992845&group_id=139814&atid=744634
> 
> Cool stuff, I'm giving it a try on my MPC8313 PTP setup.

Do you have also a patch adding support for hardware timestamping to ptpd?

Thanks,

Wolfgang.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-27 16:20     ` Wolfgang Grandegger
@ 2010-04-28  5:47       ` Richard Cochran
  2010-04-28 13:50         ` Wolfgang Grandegger
  0 siblings, 1 reply; 17+ messages in thread
From: Richard Cochran @ 2010-04-28  5:47 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: netdev

On Tue, Apr 27, 2010 at 06:20:25PM +0200, Wolfgang Grandegger wrote:
> Do you have also a patch adding support for hardware timestamping to ptpd?

Yes, I do:

   https://sourceforge.net/tracker/index.php?func=detail&aid=2992847&group_id=139814&atid=744634

I should have mentioned, you also need the gianfar HW time stamping
patches, recently posted to netdev by Manfred Rudigier.

Enjoy,

Richard

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-28  5:47       ` Richard Cochran
@ 2010-04-28 13:50         ` Wolfgang Grandegger
  2010-04-28 14:31           ` Wolfgang Grandegger
  0 siblings, 1 reply; 17+ messages in thread
From: Wolfgang Grandegger @ 2010-04-28 13:50 UTC (permalink / raw)
  To: Richard Cochran; +Cc: netdev

Richard Cochran wrote:
> On Tue, Apr 27, 2010 at 06:20:25PM +0200, Wolfgang Grandegger wrote:
>> Do you have also a patch adding support for hardware timestamping to ptpd?
> 
> Yes, I do:
> 
>    https://sourceforge.net/tracker/index.php?func=detail&aid=2992847&group_id=139814&atid=744634

Thanks.

> I should have mentioned, you also need the gianfar HW time stamping
> patches, recently posted to netdev by Manfred Rudigier.

I'm aware of these patches. I'm actually using the net-next-2.6 git tree.

I got ptpd working but I do not yet see the PPS-Signals on my scope. At
a first glance, the PPS-Signal seems to be configured by the gianfar_ptp
driver (setting the fiper1 and timer1 registers) but I might have missed
something.

Wolfgang.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-28 13:50         ` Wolfgang Grandegger
@ 2010-04-28 14:31           ` Wolfgang Grandegger
  2010-04-29  6:54             ` Richard Cochran
  2010-04-29  8:38             ` Richard Cochran
  0 siblings, 2 replies; 17+ messages in thread
From: Wolfgang Grandegger @ 2010-04-28 14:31 UTC (permalink / raw)
  To: Richard Cochran; +Cc: netdev

Wolfgang Grandegger wrote:
> Richard Cochran wrote:
>> On Tue, Apr 27, 2010 at 06:20:25PM +0200, Wolfgang Grandegger wrote:
>>> Do you have also a patch adding support for hardware timestamping to ptpd?
>> Yes, I do:
>>
>>    https://sourceforge.net/tracker/index.php?func=detail&aid=2992847&group_id=139814&atid=744634
> 
> Thanks.
> 
>> I should have mentioned, you also need the gianfar HW time stamping
>> patches, recently posted to netdev by Manfred Rudigier.
> 
> I'm aware of these patches. I'm actually using the net-next-2.6 git tree.
> 
> I got ptpd working but I do not yet see the PPS-Signals on my scope. At
> a first glance, the PPS-Signal seems to be configured by the gianfar_ptp
> driver (setting the fiper1 and timer1 registers) but I might have missed
> something.

That's because some 1588_PPS related bits are not yet setup in the
platform code of mainline kernel.

Wolfgang.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-28 14:31           ` Wolfgang Grandegger
@ 2010-04-29  6:54             ` Richard Cochran
       [not found]               ` <20100429065422.GA5803-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
  2010-04-29  8:38             ` Richard Cochran
  1 sibling, 1 reply; 17+ messages in thread
From: Richard Cochran @ 2010-04-29  6:54 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: netdev

On Wed, Apr 28, 2010 at 04:31:35PM +0200, Wolfgang Grandegger wrote:
> That's because some 1588_PPS related bits are not yet setup in the
> platform code of mainline kernel.

So did you get it working?

I am reworking this patch set to post again, but perhaps you might
take a look at the patch below. It configures the gianfar PTP clock
parameters via the device tree.

Richard

[PATCH] ptp: gianfar clock uses device tree parameters
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
 arch/powerpc/boot/dts/mpc8313erdb.dts |   14 +++++
 arch/powerpc/boot/dts/p2020ds.dts     |   13 ++++
 arch/powerpc/boot/dts/p2020rdb.dts    |   14 +++++
 drivers/net/gianfar_ptp.c             |  102 ++++++++++++++++++++++----------
 4 files changed, 111 insertions(+), 32 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts b/arch/powerpc/boot/dts/mpc8313erdb.dts
index 183f2aa..b760aee 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -208,6 +208,20 @@
 			sleep = <&pmc 0x00300000>;
 		};
 
+		ptp_clock@24E00 {
+			device_type = "ptp_clock";
+			model = "eTSEC";
+			reg = <0x24E00 0xB0>;
+			interrupts = <0x0C 2 0x0D 2>;
+			interrupt-parent = < &ipic >;
+			tclk_period = <10>;
+			tmr_prsc    = <100>;
+			tmr_add     = <0x999999A4>;
+			cksel       = <0x1>;
+			tmr_fiper1  = <0x3B9AC9F6>;
+			tmr_fiper2  = <0x00018696>;
+		};
+
 		enet0: ethernet@24000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
diff --git a/arch/powerpc/boot/dts/p2020ds.dts b/arch/powerpc/boot/dts/p2020ds.dts
index 1101914..1dcf790 100644
--- a/arch/powerpc/boot/dts/p2020ds.dts
+++ b/arch/powerpc/boot/dts/p2020ds.dts
@@ -336,6 +336,19 @@
 			phy_type = "ulpi";
 		};
 
+		ptp_clock@24E00 {
+			device_type = "ptp_clock";
+			model = "eTSEC";
+			reg = <0x24E00 0xB0>;
+			interrupts = <0x0C 2 0x0D 2>;
+			interrupt-parent = < &mpic >;
+			tclk_period = <5>;
+			tmr_prsc = <200>;
+			tmr_add = <0xCCCCCCCD>;
+			tmr_fiper1 = <0x3B9AC9FB>;
+			tmr_fiper2 = <0x0001869B>;
+		};
+
 		enet0: ethernet@24000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts b/arch/powerpc/boot/dts/p2020rdb.dts
index da4cb0d..ba61e8e 100644
--- a/arch/powerpc/boot/dts/p2020rdb.dts
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -396,6 +396,20 @@
 			phy_type = "ulpi";
 		};
 
+		ptp_clock@24E00 {
+			device_type = "ptp_clock";
+			model = "eTSEC";
+			reg = <0x24E00 0xB0>;
+			interrupts = <0x0C 2 0x0D 2>;
+			interrupt-parent = < &mpic >;
+			tclk_period = <5>;
+			tmr_prsc = <200>;
+			tmr_add = <0xCCCCCCCD>;
+			cksel = <1>;
+			tmr_fiper1 = <0x3B9AC9FB>;
+			tmr_fiper2 = <0x0001869B>;
+		};
+
 		enet0: ethernet@24000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
diff --git a/drivers/net/gianfar_ptp.c b/drivers/net/gianfar_ptp.c
index eed3246..ed6234c 100644
--- a/drivers/net/gianfar_ptp.c
+++ b/drivers/net/gianfar_ptp.c
@@ -22,6 +22,8 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
 #include <linux/timex.h>
 #include <asm/io.h>
 
@@ -29,29 +31,16 @@
 
 #include "gianfar_ptp_reg.h"
 
-/*
- *
- * TODO - get the following from device tree
- *
- */
-#define TMR_BASE_KERNEL	0xe0024e00 // CONFIG_PPC_85xx 0xffe24e00
-#define TIMER_OSC	166666666
-#define TCLK_PERIOD	10
-#define NOMINAL_FREQ	100000000
-#define DEF_TMR_PRSC	100
-#define DEF_TMR_ADD	0x999999A4
-#define DEFAULT_CKSEL   1
-
 #define REG_SIZE	(4 + TMR_ETTS2_L)
 
 struct etsects {
 	void *regs;
-	u32 timer_osc;    /* Hz */
 	u32 tclk_period;  /* nanoseconds */
-	s64 nominal_freq; /* Hz */
 	u32 tmr_prsc;
 	u32 tmr_add;
 	u32 cksel;
+	u32 tmr_fiper1;
+	u32 tmr_fiper2;
 };
 
 /* Private globals */
@@ -111,8 +100,8 @@ static void set_fipers(struct etsects *etsects)
 
 	reg_write(etsects, TMR_CTRL,   tmr_ctrl & (~TE));
 	reg_write(etsects, TMR_PRSC,   etsects->tmr_prsc);
-	reg_write(etsects, TMR_FIPER1, 0x3B9AC9F6);
-	reg_write(etsects, TMR_FIPER2, 0x00018696);
+	reg_write(etsects, TMR_FIPER1, etsects->tmr_fiper1);
+	reg_write(etsects, TMR_FIPER2, etsects->tmr_fiper2);
 	set_alarm(etsects);
 	reg_write(etsects, TMR_CTRL,   tmr_ctrl|TE);
 }
@@ -213,34 +202,51 @@ struct ptp_clock_info ptp_gianfar_caps = {
 	.enable		= ptp_gianfar_enable,
 };
 
-/* module operations */
+/* OF device tree */
 
-static void __exit ptp_gianfar_exit(void)
+static int get_of_u32(struct device_node *node, char *str, u32 *val)
 {
-	ptp_clock_unregister(&ptp_gianfar_caps);
-	iounmap(the_clock.regs);
+	int plen;
+	const u32 *prop = of_get_property(node, str, &plen);
+
+	if (!prop || plen != sizeof(*prop))
+		return -1;
+	*val = *prop;
+	return 0;
 }
 
-static int __init ptp_gianfar_init(void)
+static int gianfar_ptp_probe(struct of_device* dev,
+			     const struct of_device_id *match)
 {
+	u64 addr, size;
+	struct device_node *node = dev->node;
 	struct etsects *etsects = &the_clock;
 	struct timespec now;
-	phys_addr_t reg_addr = TMR_BASE_KERNEL;
-	unsigned long reg_size = REG_SIZE;
+	phys_addr_t reg_addr;
+	unsigned long reg_size;
 	u32 tmr_ctrl;
 	int err;
 
+	if (get_of_u32(node, "tclk_period", &etsects->tclk_period) ||
+	    get_of_u32(node, "tmr_prsc", &etsects->tmr_prsc) ||
+	    get_of_u32(node, "tmr_add", &etsects->tmr_add) ||
+	    get_of_u32(node, "cksel", &etsects->cksel) ||
+	    get_of_u32(node, "tmr_fiper1", &etsects->tmr_fiper1) ||
+	    get_of_u32(node, "tmr_fiper2", &etsects->tmr_fiper2))
+		return -ENODEV;
+
+	addr = of_translate_address(node, of_get_address(node, 0, &size, NULL));
+	reg_addr = addr;
+	reg_size = size;
+	if (reg_size < REG_SIZE) {
+		pr_warning("device tree reg range %lu too small\n", reg_size);
+		reg_size = REG_SIZE;
+	}
 	etsects->regs = ioremap(reg_addr, reg_size);
 	if (!etsects->regs) {
 		pr_err("ioremap ptp registers failed\n");
 		return -EINVAL;
 	}
-	etsects->timer_osc = TIMER_OSC;
-	etsects->tclk_period = TCLK_PERIOD;
-	etsects->nominal_freq = NOMINAL_FREQ;
-	etsects->tmr_prsc = DEF_TMR_PRSC;
-	etsects->tmr_add = DEF_TMR_ADD;
-	etsects->cksel = DEFAULT_CKSEL;
 
 	tmr_ctrl =
 	  (etsects->tclk_period & TCLK_PERIOD_MASK) << TCLK_PERIOD_SHIFT |
@@ -252,8 +258,8 @@ static int __init ptp_gianfar_init(void)
 	reg_write(etsects, TMR_CTRL,   tmr_ctrl);
 	reg_write(etsects, TMR_ADD,    etsects->tmr_add);
 	reg_write(etsects, TMR_PRSC,   etsects->tmr_prsc);
-	reg_write(etsects, TMR_FIPER1, 0x3B9AC9F6);
-	reg_write(etsects, TMR_FIPER2, 0x00018696);
+	reg_write(etsects, TMR_FIPER1, etsects->tmr_fiper1);
+	reg_write(etsects, TMR_FIPER2, etsects->tmr_fiper2);
 	set_alarm(etsects);
 	reg_write(etsects, TMR_CTRL,   tmr_ctrl|FS|RTPE|TE);
 
@@ -261,6 +267,38 @@ static int __init ptp_gianfar_init(void)
 	return err;
 }
 
+static int gianfar_ptp_remove(struct of_device* dev)
+{
+	ptp_clock_unregister(&ptp_gianfar_caps);
+	iounmap(the_clock.regs);
+	return 0;
+}
+
+static struct of_device_id match_table[] = {
+	{ .type = "ptp_clock" },
+	{},
+};
+
+static struct of_platform_driver gianfar_ptp_driver = {
+	.name        = "gianfar_ptp",
+	.match_table = match_table,
+	.owner       = THIS_MODULE,
+	.probe       = gianfar_ptp_probe,
+	.remove      = gianfar_ptp_remove,
+};
+
+/* module operations */
+
+static void __exit ptp_gianfar_exit(void)
+{
+	of_unregister_platform_driver(&gianfar_ptp_driver);
+}
+
+static int __init ptp_gianfar_init(void)
+{
+	return of_register_platform_driver(&gianfar_ptp_driver);
+}
+
 subsys_initcall(ptp_gianfar_init);
 module_exit(ptp_gianfar_exit);
 
-- 
1.6.0.4


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
       [not found]               ` <20100429065422.GA5803-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
@ 2010-04-29  8:08                 ` Wolfgang Grandegger
  0 siblings, 0 replies; 17+ messages in thread
From: Wolfgang Grandegger @ 2010-04-29  8:08 UTC (permalink / raw)
  To: Richard Cochran; +Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-discuss

Richard Cochran wrote:
> On Wed, Apr 28, 2010 at 04:31:35PM +0200, Wolfgang Grandegger wrote:
>> That's because some 1588_PPS related bits are not yet setup in the
>> platform code of mainline kernel.
> 
> So did you get it working?

Yes, it works now :-). With

  master: ptpd -b eth1 -y 0 -a 3,12 -p
  slave : ptpd -b eth1 -y 0 -a 3,12

I see a PPS jitter of approximately +-100ns on the oscilloscopes. That's
the same value I get with the Freescale's old PTP 1588 implementation.

> I am reworking this patch set to post again, but perhaps you might
> take a look at the patch below. It configures the gianfar PTP clock

I will comment on your previous patches later today.

> parameters via the device tree.
> 
> Richard
> 
> [PATCH] ptp: gianfar clock uses device tree parameters
> Signed-off-by: Richard Cochran <richard.cochran-3mrvs1K0uXizZXS1Dc/lvw@public.gmane.org>
> ---
>  arch/powerpc/boot/dts/mpc8313erdb.dts |   14 +++++
>  arch/powerpc/boot/dts/p2020ds.dts     |   13 ++++
>  arch/powerpc/boot/dts/p2020rdb.dts    |   14 +++++
>  drivers/net/gianfar_ptp.c             |  102 ++++++++++++++++++++++----------
>  4 files changed, 111 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts b/arch/powerpc/boot/dts/mpc8313erdb.dts
> index 183f2aa..b760aee 100644
> --- a/arch/powerpc/boot/dts/mpc8313erdb.dts
> +++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
> @@ -208,6 +208,20 @@
>  			sleep = <&pmc 0x00300000>;
>  		};
>  
> +		ptp_clock@24E00 {
> +			device_type = "ptp_clock";
> +			model = "eTSEC";
> +			reg = <0x24E00 0xB0>;
> +			interrupts = <0x0C 2 0x0D 2>;

The interrupt number is usually specified in decimal notation.

> +			interrupt-parent = < &ipic >;
> +			tclk_period = <10>;
> +			tmr_prsc    = <100>;
> +			tmr_add     = <0x999999A4>;
> +			cksel       = <0x1>;
> +			tmr_fiper1  = <0x3B9AC9F6>;
> +			tmr_fiper2  = <0x00018696>;
> +		};

You should use the prefix "fsl," for the MPC-specific properties, at
least. A few of the values could be calculated from the clock frequency.
OF people usually prefer human readable values, if feasible, e.g.

        ptp-clock-source = "sys";
        ptp-clock-source = "ext";
	ptp-clock-frequency = "100000000";

Not sure it that works for other PTP hardware but it would be nice to
have a generic set of properties. I have added a CC to the device-tree
discuss mailing for further feedback.

> +
>  		enet0: ethernet@24000 {
>  			#address-cells = <1>;
>  			#size-cells = <1>;
> diff --git a/arch/powerpc/boot/dts/p2020ds.dts b/arch/powerpc/boot/dts/p2020ds.dts
> index 1101914..1dcf790 100644
> --- a/arch/powerpc/boot/dts/p2020ds.dts
> +++ b/arch/powerpc/boot/dts/p2020ds.dts
> @@ -336,6 +336,19 @@
>  			phy_type = "ulpi";
>  		};
>  
> +		ptp_clock@24E00 {
> +			device_type = "ptp_clock";
> +			model = "eTSEC";
> +			reg = <0x24E00 0xB0>;
> +			interrupts = <0x0C 2 0x0D 2>;
> +			interrupt-parent = < &mpic >;
> +			tclk_period = <5>;
> +			tmr_prsc = <200>;
> +			tmr_add = <0xCCCCCCCD>;
> +			tmr_fiper1 = <0x3B9AC9FB>;
> +			tmr_fiper2 = <0x0001869B>;
> +		};
> +
>  		enet0: ethernet@24000 {
>  			#address-cells = <1>;
>  			#size-cells = <1>;
> diff --git a/arch/powerpc/boot/dts/p2020rdb.dts b/arch/powerpc/boot/dts/p2020rdb.dts
> index da4cb0d..ba61e8e 100644
> --- a/arch/powerpc/boot/dts/p2020rdb.dts
> +++ b/arch/powerpc/boot/dts/p2020rdb.dts
> @@ -396,6 +396,20 @@
>  			phy_type = "ulpi";
>  		};
>  
> +		ptp_clock@24E00 {
> +			device_type = "ptp_clock";
> +			model = "eTSEC";
> +			reg = <0x24E00 0xB0>;
> +			interrupts = <0x0C 2 0x0D 2>;
> +			interrupt-parent = < &mpic >;
> +			tclk_period = <5>;
> +			tmr_prsc = <200>;
> +			tmr_add = <0xCCCCCCCD>;
> +			cksel = <1>;
> +			tmr_fiper1 = <0x3B9AC9FB>;
> +			tmr_fiper2 = <0x0001869B>;
> +		};
> +
>  		enet0: ethernet@24000 {
>  			#address-cells = <1>;
>  			#size-cells = <1>;
> diff --git a/drivers/net/gianfar_ptp.c b/drivers/net/gianfar_ptp.c
> index eed3246..ed6234c 100644
> --- a/drivers/net/gianfar_ptp.c
> +++ b/drivers/net/gianfar_ptp.c
> @@ -22,6 +22,8 @@
>  #include <linux/init.h>
>  #include <linux/kernel.h>
>  #include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
>  #include <linux/timex.h>
>  #include <asm/io.h>
>  
> @@ -29,29 +31,16 @@
>  
>  #include "gianfar_ptp_reg.h"
>  
> -/*
> - *
> - * TODO - get the following from device tree
> - *
> - */
> -#define TMR_BASE_KERNEL	0xe0024e00 // CONFIG_PPC_85xx 0xffe24e00
> -#define TIMER_OSC	166666666
> -#define TCLK_PERIOD	10
> -#define NOMINAL_FREQ	100000000
> -#define DEF_TMR_PRSC	100
> -#define DEF_TMR_ADD	0x999999A4
> -#define DEFAULT_CKSEL   1
> -
>  #define REG_SIZE	(4 + TMR_ETTS2_L)
>  
>  struct etsects {
>  	void *regs;
> -	u32 timer_osc;    /* Hz */
>  	u32 tclk_period;  /* nanoseconds */
> -	s64 nominal_freq; /* Hz */
>  	u32 tmr_prsc;
>  	u32 tmr_add;
>  	u32 cksel;
> +	u32 tmr_fiper1;
> +	u32 tmr_fiper2;
>  };
>  
>  /* Private globals */
> @@ -111,8 +100,8 @@ static void set_fipers(struct etsects *etsects)
>  
>  	reg_write(etsects, TMR_CTRL,   tmr_ctrl & (~TE));
>  	reg_write(etsects, TMR_PRSC,   etsects->tmr_prsc);
> -	reg_write(etsects, TMR_FIPER1, 0x3B9AC9F6);
> -	reg_write(etsects, TMR_FIPER2, 0x00018696);
> +	reg_write(etsects, TMR_FIPER1, etsects->tmr_fiper1);
> +	reg_write(etsects, TMR_FIPER2, etsects->tmr_fiper2);
>  	set_alarm(etsects);
>  	reg_write(etsects, TMR_CTRL,   tmr_ctrl|TE);
>  }
> @@ -213,34 +202,51 @@ struct ptp_clock_info ptp_gianfar_caps = {
>  	.enable		= ptp_gianfar_enable,
>  };
>  
> -/* module operations */
> +/* OF device tree */
>  
> -static void __exit ptp_gianfar_exit(void)
> +static int get_of_u32(struct device_node *node, char *str, u32 *val)
>  {
> -	ptp_clock_unregister(&ptp_gianfar_caps);
> -	iounmap(the_clock.regs);
> +	int plen;
> +	const u32 *prop = of_get_property(node, str, &plen);
> +
> +	if (!prop || plen != sizeof(*prop))
> +		return -1;
> +	*val = *prop;
> +	return 0;
>  }
>  
> -static int __init ptp_gianfar_init(void)
> +static int gianfar_ptp_probe(struct of_device* dev,
> +			     const struct of_device_id *match)
>  {
> +	u64 addr, size;
> +	struct device_node *node = dev->node;
>  	struct etsects *etsects = &the_clock;
>  	struct timespec now;
> -	phys_addr_t reg_addr = TMR_BASE_KERNEL;
> -	unsigned long reg_size = REG_SIZE;
> +	phys_addr_t reg_addr;
> +	unsigned long reg_size;
>  	u32 tmr_ctrl;
>  	int err;
>  
> +	if (get_of_u32(node, "tclk_period", &etsects->tclk_period) ||
> +	    get_of_u32(node, "tmr_prsc", &etsects->tmr_prsc) ||
> +	    get_of_u32(node, "tmr_add", &etsects->tmr_add) ||
> +	    get_of_u32(node, "cksel", &etsects->cksel) ||
> +	    get_of_u32(node, "tmr_fiper1", &etsects->tmr_fiper1) ||
> +	    get_of_u32(node, "tmr_fiper2", &etsects->tmr_fiper2))
> +		return -ENODEV;
> +
> +	addr = of_translate_address(node, of_get_address(node, 0, &size, NULL));
> +	reg_addr = addr;
> +	reg_size = size;
> +	if (reg_size < REG_SIZE) {
> +		pr_warning("device tree reg range %lu too small\n", reg_size);
> +		reg_size = REG_SIZE;
> +	}
>  	etsects->regs = ioremap(reg_addr, reg_size);
>  	if (!etsects->regs) {
>  		pr_err("ioremap ptp registers failed\n");
>  		return -EINVAL;
>  	}
> -	etsects->timer_osc = TIMER_OSC;
> -	etsects->tclk_period = TCLK_PERIOD;
> -	etsects->nominal_freq = NOMINAL_FREQ;
> -	etsects->tmr_prsc = DEF_TMR_PRSC;
> -	etsects->tmr_add = DEF_TMR_ADD;
> -	etsects->cksel = DEFAULT_CKSEL;
>  
>  	tmr_ctrl =
>  	  (etsects->tclk_period & TCLK_PERIOD_MASK) << TCLK_PERIOD_SHIFT |
> @@ -252,8 +258,8 @@ static int __init ptp_gianfar_init(void)
>  	reg_write(etsects, TMR_CTRL,   tmr_ctrl);
>  	reg_write(etsects, TMR_ADD,    etsects->tmr_add);
>  	reg_write(etsects, TMR_PRSC,   etsects->tmr_prsc);
> -	reg_write(etsects, TMR_FIPER1, 0x3B9AC9F6);
> -	reg_write(etsects, TMR_FIPER2, 0x00018696);
> +	reg_write(etsects, TMR_FIPER1, etsects->tmr_fiper1);
> +	reg_write(etsects, TMR_FIPER2, etsects->tmr_fiper2);
>  	set_alarm(etsects);
>  	reg_write(etsects, TMR_CTRL,   tmr_ctrl|FS|RTPE|TE);
>  
> @@ -261,6 +267,38 @@ static int __init ptp_gianfar_init(void)
>  	return err;
>  }
>  
> +static int gianfar_ptp_remove(struct of_device* dev)
> +{
> +	ptp_clock_unregister(&ptp_gianfar_caps);
> +	iounmap(the_clock.regs);
> +	return 0;
> +}
> +
> +static struct of_device_id match_table[] = {
> +	{ .type = "ptp_clock" },
> +	{},
> +};
> +
> +static struct of_platform_driver gianfar_ptp_driver = {
> +	.name        = "gianfar_ptp",
> +	.match_table = match_table,
> +	.owner       = THIS_MODULE,
> +	.probe       = gianfar_ptp_probe,
> +	.remove      = gianfar_ptp_remove,
> +};
> +
> +/* module operations */
> +
> +static void __exit ptp_gianfar_exit(void)
> +{
> +	of_unregister_platform_driver(&gianfar_ptp_driver);
> +}
> +
> +static int __init ptp_gianfar_init(void)
> +{
> +	return of_register_platform_driver(&gianfar_ptp_driver);
> +}
> +
>  subsys_initcall(ptp_gianfar_init);
>  module_exit(ptp_gianfar_exit);

Wolfgang.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-28 14:31           ` Wolfgang Grandegger
  2010-04-29  6:54             ` Richard Cochran
@ 2010-04-29  8:38             ` Richard Cochran
  2010-04-29  9:24               ` Wolfgang Grandegger
  1 sibling, 1 reply; 17+ messages in thread
From: Richard Cochran @ 2010-04-29  8:38 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: netdev

On Wed, Apr 28, 2010 at 04:31:35PM +0200, Wolfgang Grandegger wrote:
> That's because some 1588_PPS related bits are not yet setup in the
> platform code of mainline kernel.

Just remembered, I am carrying along the following patch to fix the
wrong mainline code for the mpc8313. Really annoying.

Richard

>From 4306b6f89e5565928b4462fd8cff19a3e484f1c4 Mon Sep 17 00:00:00 2001
From: Richard Cochran <richard.cochran@omicron.at>
Date: Tue, 6 Apr 2010 13:36:32 +0200
Subject: [PATCH] mpc8313: fixed the board support for REV C

---
 arch/powerpc/boot/dts/mpc8313erdb.dts     |   56 ++++++++++++++++++++++------
 arch/powerpc/platforms/83xx/mpc831x_rdb.c |   15 ++++++++
 2 files changed, 59 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts b/arch/powerpc/boot/dts/mpc8313erdb.dts
index 761faa7..183f2aa 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -70,6 +70,26 @@
 			reg = <0x0 0x0 0x800000>;
 			bank-width = <2>;
 			device-width = <1>;
+			partition@0 {
+				label = "U-Boot";
+				reg = <0x00000000 0x00100000>;
+			};
+			partition@100000 {
+				label = "kernel";
+				reg = <0x00100000 0x00200000>;
+			};
+			partition@300000 {
+				label = "rootfs";
+				reg = <0x00300000 0x00400000>;
+			};
+			partition@700000 {
+				label = "DTB";
+				reg = <0x00700000 0x00010000>;
+			};
+			partition@710000 {
+				label = "vsc-util";
+				reg = <0x00710000 0x000F0000>;
+			};
 		};
 
 		nand@1,0 {
@@ -78,19 +98,31 @@
 			compatible = "fsl,mpc8313-fcm-nand",
 			             "fsl,elbc-fcm-nand";
 			reg = <0x1 0x0 0x2000>;
-
-			u-boot@0 {
-				reg = <0x0 0x100000>;
-				read-only;
+			partition@0 {
+				label = "U-Boot-NAND";
+				reg = <0x00000000 0x00100000>;
 			};
-
-			kernel@100000 {
-				reg = <0x100000 0x300000>;
+			partition@100000 {
+				label = "JFFS2-NAND";
+				reg = <0x00100000 0x00800000>;
 			};
-
-			fs@400000 {
-				reg = <0x400000 0x1c00000>;
+			partition@900000 {
+				label = "Ramdisk-NAND";
+				reg = <0x00900000 0x00400000>;
+			};
+			partition@d00000 {
+				label = "Reserve-NAND";
+				reg = <0x00d00000 0x01000000>;
 			};
+			partition@1d00000 {
+				label = "Kernel-NAND";
+				reg = <0x01d00000 0x00200000>;
+			};
+			partition@1f00000 {
+				label = "DTB-NAND";
+				reg = <0x01f00000 0x00100000>;
+			};
+
 		};
 	};
 
@@ -188,7 +220,7 @@
 			compatible = "gianfar";
 			reg = <0x24000 0x1000>;
 			local-mac-address = [ 00 00 00 00 00 00 ];
-			interrupts = <37 0x8 36 0x8 35 0x8>;
+			interrupts = <32 0x8 33 0x8 34 0x8>;
 			interrupt-parent = <&ipic>;
 			tbi-handle = < &tbi0 >;
 			/* Vitesse 7385 isn't on the MDIO bus */
@@ -223,7 +255,7 @@
 			reg = <0x25000 0x1000>;
 			ranges = <0x0 0x25000 0x1000>;
 			local-mac-address = [ 00 00 00 00 00 00 ];
-			interrupts = <34 0x8 33 0x8 32 0x8>;
+			interrupts = <35 0x8 36 0x8 37 0x8>;
 			interrupt-parent = <&ipic>;
 			tbi-handle = < &tbi1 >;
 			phy-handle = < &phy4 >;
diff --git a/arch/powerpc/platforms/83xx/mpc831x_rdb.c b/arch/powerpc/platforms/83xx/mpc831x_rdb.c
index 0b4f883..7f80269 100644
--- a/arch/powerpc/platforms/83xx/mpc831x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc831x_rdb.c
@@ -20,6 +20,7 @@
 #include <asm/ipic.h>
 #include <asm/udbg.h>
 #include <sysdev/fsl_pci.h>
+#include <sysdev/fsl_soc.h>
 
 #include "mpc83xx.h"
 
@@ -31,6 +32,8 @@ static void __init mpc831x_rdb_setup_arch(void)
 #ifdef CONFIG_PCI
 	struct device_node *np;
 #endif
+	void __iomem *immap;
+	unsigned long spcr, sicrh;
 
 	if (ppc_md.progress)
 		ppc_md.progress("mpc831x_rdb_setup_arch()", 0);
@@ -42,6 +45,18 @@ static void __init mpc831x_rdb_setup_arch(void)
 		mpc83xx_add_bridge(np);
 #endif
 	mpc831x_usb_cfg();
+
+#define MPC83XX_SPCR_OFFS         0x110
+#define MPC8313_SPCR_1588_PPS 0x00004000
+#define MPC8313_SICRH_1588_PPS 0x01000000
+
+	immap = ioremap(get_immrbase(), 0x1000);
+	spcr = in_be32(immap + MPC83XX_SPCR_OFFS);
+	sicrh = in_be32(immap + MPC83XX_SICRH_OFFS);
+	sicrh |= MPC8313_SICRH_1588_PPS;
+	out_be32(immap + MPC83XX_SICRH_OFFS, sicrh);
+	spcr |= MPC8313_SPCR_1588_PPS;
+	out_be32(immap + MPC83XX_SPCR_OFFS, spcr);
 }
 
 static void __init mpc831x_rdb_init_IRQ(void)
-- 
1.6.0.4


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-29  8:38             ` Richard Cochran
@ 2010-04-29  9:24               ` Wolfgang Grandegger
  2010-04-29  9:42                 ` Richard Cochran
  0 siblings, 1 reply; 17+ messages in thread
From: Wolfgang Grandegger @ 2010-04-29  9:24 UTC (permalink / raw)
  To: Richard Cochran; +Cc: netdev

Richard Cochran wrote:
> On Wed, Apr 28, 2010 at 04:31:35PM +0200, Wolfgang Grandegger wrote:
>> That's because some 1588_PPS related bits are not yet setup in the
>> platform code of mainline kernel.
> 
> Just remembered, I am carrying along the following patch to fix the
> wrong mainline code for the mpc8313. Really annoying.

OK.

> Richard
> 
>>From 4306b6f89e5565928b4462fd8cff19a3e484f1c4 Mon Sep 17 00:00:00 2001
> From: Richard Cochran <richard.cochran@omicron.at>
> Date: Tue, 6 Apr 2010 13:36:32 +0200
> Subject: [PATCH] mpc8313: fixed the board support for REV C
> 
> ---
>  arch/powerpc/boot/dts/mpc8313erdb.dts     |   56 ++++++++++++++++++++++------
>  arch/powerpc/platforms/83xx/mpc831x_rdb.c |   15 ++++++++
>  2 files changed, 59 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts b/arch/powerpc/boot/dts/mpc8313erdb.dts
> index 761faa7..183f2aa 100644
> --- a/arch/powerpc/boot/dts/mpc8313erdb.dts
> +++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
> @@ -70,6 +70,26 @@
>  			reg = <0x0 0x0 0x800000>;
>  			bank-width = <2>;
>  			device-width = <1>;
> +			partition@0 {
> +				label = "U-Boot";
> +				reg = <0x00000000 0x00100000>;
> +			};
> +			partition@100000 {
> +				label = "kernel";
> +				reg = <0x00100000 0x00200000>;
> +			};
> +			partition@300000 {
> +				label = "rootfs";
> +				reg = <0x00300000 0x00400000>;
> +			};
> +			partition@700000 {
> +				label = "DTB";
> +				reg = <0x00700000 0x00010000>;
> +			};
> +			partition@710000 {
> +				label = "vsc-util";
> +				reg = <0x00710000 0x000F0000>;
> +			};
>  		};
>  
>  		nand@1,0 {
> @@ -78,19 +98,31 @@
>  			compatible = "fsl,mpc8313-fcm-nand",
>  			             "fsl,elbc-fcm-nand";
>  			reg = <0x1 0x0 0x2000>;
> -
> -			u-boot@0 {
> -				reg = <0x0 0x100000>;
> -				read-only;
> +			partition@0 {
> +				label = "U-Boot-NAND";
> +				reg = <0x00000000 0x00100000>;
>  			};
> -
> -			kernel@100000 {
> -				reg = <0x100000 0x300000>;
> +			partition@100000 {
> +				label = "JFFS2-NAND";
> +				reg = <0x00100000 0x00800000>;
>  			};
> -
> -			fs@400000 {
> -				reg = <0x400000 0x1c00000>;
> +			partition@900000 {
> +				label = "Ramdisk-NAND";
> +				reg = <0x00900000 0x00400000>;
> +			};
> +			partition@d00000 {
> +				label = "Reserve-NAND";
> +				reg = <0x00d00000 0x01000000>;
>  			};
> +			partition@1d00000 {
> +				label = "Kernel-NAND";
> +				reg = <0x01d00000 0x00200000>;
> +			};
> +			partition@1f00000 {
> +				label = "DTB-NAND";
> +				reg = <0x01f00000 0x00100000>;
> +			};
> +
>  		};
>  	};
>  
> @@ -188,7 +220,7 @@
>  			compatible = "gianfar";
>  			reg = <0x24000 0x1000>;
>  			local-mac-address = [ 00 00 00 00 00 00 ];
> -			interrupts = <37 0x8 36 0x8 35 0x8>;
> +			interrupts = <32 0x8 33 0x8 34 0x8>;
>  			interrupt-parent = <&ipic>;
>  			tbi-handle = < &tbi0 >;
>  			/* Vitesse 7385 isn't on the MDIO bus */
> @@ -223,7 +255,7 @@
>  			reg = <0x25000 0x1000>;
>  			ranges = <0x0 0x25000 0x1000>;
>  			local-mac-address = [ 00 00 00 00 00 00 ];
> -			interrupts = <34 0x8 33 0x8 32 0x8>;
> +			interrupts = <35 0x8 36 0x8 37 0x8>;

I used these interrupt number fixes as well but it was not necessary for
the actual net-next-2.6 tree. Need to check why? I remember some version
dependent re-mapping code.

>  			interrupt-parent = <&ipic>;
>  			tbi-handle = < &tbi1 >;
>  			phy-handle = < &phy4 >;
> diff --git a/arch/powerpc/platforms/83xx/mpc831x_rdb.c b/arch/powerpc/platforms/83xx/mpc831x_rdb.c
> index 0b4f883..7f80269 100644
> --- a/arch/powerpc/platforms/83xx/mpc831x_rdb.c
> +++ b/arch/powerpc/platforms/83xx/mpc831x_rdb.c
> @@ -20,6 +20,7 @@
>  #include <asm/ipic.h>
>  #include <asm/udbg.h>
>  #include <sysdev/fsl_pci.h>
> +#include <sysdev/fsl_soc.h>
>  
>  #include "mpc83xx.h"
>  
> @@ -31,6 +32,8 @@ static void __init mpc831x_rdb_setup_arch(void)
>  #ifdef CONFIG_PCI
>  	struct device_node *np;
>  #endif
> +	void __iomem *immap;
> +	unsigned long spcr, sicrh;
>  
>  	if (ppc_md.progress)
>  		ppc_md.progress("mpc831x_rdb_setup_arch()", 0);
> @@ -42,6 +45,18 @@ static void __init mpc831x_rdb_setup_arch(void)
>  		mpc83xx_add_bridge(np);
>  #endif
>  	mpc831x_usb_cfg();
> +
> +#define MPC83XX_SPCR_OFFS         0x110
> +#define MPC8313_SPCR_1588_PPS 0x00004000
> +#define MPC8313_SICRH_1588_PPS 0x01000000
> +
> +	immap = ioremap(get_immrbase(), 0x1000);
> +	spcr = in_be32(immap + MPC83XX_SPCR_OFFS);
> +	sicrh = in_be32(immap + MPC83XX_SICRH_OFFS);
> +	sicrh |= MPC8313_SICRH_1588_PPS;
> +	out_be32(immap + MPC83XX_SICRH_OFFS, sicrh);
> +	spcr |= MPC8313_SPCR_1588_PPS;
> +	out_be32(immap + MPC83XX_SPCR_OFFS, spcr);
>  }

That's missing to get the PPS signal output. But it should probably go
to gianfar_ptp.c.

Wolfgang.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-29  9:24               ` Wolfgang Grandegger
@ 2010-04-29  9:42                 ` Richard Cochran
  2010-04-29 11:31                   ` Wolfgang Grandegger
  0 siblings, 1 reply; 17+ messages in thread
From: Richard Cochran @ 2010-04-29  9:42 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: netdev

On Thu, Apr 29, 2010 at 11:24:24AM +0200, Wolfgang Grandegger wrote:
> I used these interrupt number fixes as well but it was not necessary for
> the actual net-next-2.6 tree. Need to check why? I remember some version
> dependent re-mapping code.

I argued on the ppc list with Scott Wood about adding dts files, one
for each of mpc8313 rev A, B, and C, but he advocated fixing this
problem in uboot instead. Is the fix in uboot, or in the kernel?

> That's missing to get the PPS signal output. But it should probably go
> to gianfar_ptp.c.

Well, this fix is specific to the mpc8313, but the gianfar_ptp driver
is for all eTECs. For example, I have the ptp code running on the
p2020rdb and p2020ds, too.

I don't think board fixups really belong in the PTP clock driver.

Just my 2 cents,
Richard

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-29  9:42                 ` Richard Cochran
@ 2010-04-29 11:31                   ` Wolfgang Grandegger
  0 siblings, 0 replies; 17+ messages in thread
From: Wolfgang Grandegger @ 2010-04-29 11:31 UTC (permalink / raw)
  To: Richard Cochran; +Cc: netdev

Richard Cochran wrote:
> On Thu, Apr 29, 2010 at 11:24:24AM +0200, Wolfgang Grandegger wrote:
>> I used these interrupt number fixes as well but it was not necessary for
>> the actual net-next-2.6 tree. Need to check why? I remember some version
>> dependent re-mapping code.
> 
> I argued on the ppc list with Scott Wood about adding dts files, one
> for each of mpc8313 rev A, B, and C, but he advocated fixing this
> problem in uboot instead. Is the fix in uboot, or in the kernel?

It seems to be fixed in u-boot:

  commit 7120c888101952b7e61b9e54bb42370904aa0e68
  Author: Kim Phillips <kim.phillips@freescale.com>
  Date:   Mon Oct 12 11:06:19 2009 -0500

    mpc83xx: mpc8313 - handle erratum IPIC1 (TSEC IRQ number swappage)
    
    mpc8313e erratum IPIC1 swapped TSEC interrupt ID numbers on rev. 1
    h/w (see AN3545).  The base device tree in use has rev. 1 ID numbers,
    so if on Rev. 2 (and higher) h/w, we fix them up here.
    
    Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
    Reviewed-by: Roland Lezuo <roland.lezuo@chello.at>

>> That's missing to get the PPS signal output. But it should probably go
>> to gianfar_ptp.c.
> 
> Well, this fix is specific to the mpc8313, but the gianfar_ptp driver
> is for all eTECs. For example, I have the ptp code running on the
> p2020rdb and p2020ds, too.
> 
> I don't think board fixups really belong in the PTP clock driver.
> 
> Just my 2 cents,

I see, fine for me if setting those bits does not harm.

Wolfgang. 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-27  9:13 [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support Richard Cochran
  2010-04-27 10:20 ` Richard Cochran
@ 2010-04-29 12:02 ` Wolfgang Grandegger
  2010-04-29 15:34   ` Richard Cochran
  1 sibling, 1 reply; 17+ messages in thread
From: Wolfgang Grandegger @ 2010-04-29 12:02 UTC (permalink / raw)
  To: Richard Cochran; +Cc: netdev

Richard Cochran wrote:
> Now and again there has been some talk on this list of adding PTP
> support into Linux. One part of the picture is already in place, the
> SO_TIMESTAMPING API for hardware time stamping. It has been pointed
> out that this API is not perfect, however, it is good enough for many
> real world uses of IEEE 1588. The second needed part has not, AFAICT,
> ever been addressed.
> 
> Here I offer an early draft of an idea how to bring the missing
> functionality into Linux. I don't yet have all of the features
> implemented, as described below. Still I would like to get your
> feedback concerning this idea before getting too far into it. I do
> have all of the hardware mentioned at hand, so I have a good idea that
> the proposed API covers the features of those clocks.
> 
> Thanks in advance for your comments,
> 
> Richard
> 
> * PTP infrastructure for Linux
> 
>   This patch set introduces support for IEEE 1588 PTP clocks in
>   Linux. Together with the SO_TIMESTAMPING socket options, this
>   presents standardized method for developing PTP user space programs,
>   synchronizing Linux with external clocks, and using the ancillary
>   features of PTP hardware clocks.
> 
>   A new class driver exports a kernel interface for specific clock
>   drivers and a user space interface. The infrastructure supports a
>   complete set of PTP functionality.
> 
>   + Basic clock operations
>     - Set time
>     - Get time
>     - Shift the clock by a given offset atomically
>     - Adjust clock frequency
> 
>   + Ancillary clock features
>     - One short or periodic alarms, with signal delivery to user program
>     - Time stamp external events
>     - Period output signals configurable from user space
>     - Synchronization of the Linux system time via the PPS subsystem
> 
> ** PTP kernel API
> 
>    A PTP clock driver registers itself with the class driver. The
>    class driver handles all of the dealings with user space. The
>    author of a clock driver need only implement the details of
>    programming the clock hardware. The clock driver notifies the class
>    driver of asynchronous events (alarms and external time stamps) via
>    a simple message passing interface.
> 
>    The class driver supports multiple PTP clock drivers. In normal use
>    cases, only one PTP clock is needed. However, for testing and
>    development, it can be useful to have more than one clock in a
>    single system, in order to allow performance comparisons.
> 
> ** PTP user space API
> 
>    The class driver creates a character device for each registered PTP
>    clock. User space programs may control the clock via standardized
>    ioctls. A program may query, enable, configure, and disable the
>    ancillary clock features. User space can receive time stamped
>    events via blocking read() and poll(). One shot and periodic
>    signals may be configured via an ioctl API with similar semantics
>    to the POSIX timer_settime() system call.
> 
> ** Supported hardware
> 
>    + Standard Linux system timer
>      - No special PTP features
>      - For use with software time stamping
> 
>    + Freescale eTSEC gianfar
>      - 2 Time stamp external triggers, programmable polarity (opt. interrupt)
>      - 2 Alarm registers (optional interrupt)
>      - 3 Periodic signals (optional interrupt)
> 
>    + National DP83640
>      - 6 GPIOs programmable as inputs or outputs
>      - 6 GPIOs with dedicated functions (LED/JTAG/clock) can also be
>        used as general inputs or outputs
>      - GPIO inputs can time stamp external triggers
>      - GPIO outputs can produce periodic signals
>      - 1 interrupt pin
> 
>    + Intel IXP465
>      - Auxiliary Slave/Master Mode Snapshot (optional interrupt)
>      - Target Time (optional interrupt)

I realized two other netdev drivers already supporting PTP timestamping:
igb and bfin_mac. From the PTP developer point of view, the interface
looks rather complete to me and it works fine on my MPC8313 setup. The
only thing I stumbled over was that PTP clock registration failed when
PTP support is statically linked into the kernel.

Thanks,

Wolfgang.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-29 12:02 ` Wolfgang Grandegger
@ 2010-04-29 15:34   ` Richard Cochran
  2010-04-29 20:30     ` Wolfgang Grandegger
  2010-05-02 11:51     ` Wolfgang Grandegger
  0 siblings, 2 replies; 17+ messages in thread
From: Richard Cochran @ 2010-04-29 15:34 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: netdev

On Thu, Apr 29, 2010 at 02:02:59PM +0200, Wolfgang Grandegger wrote:
> 
> I realized two other netdev drivers already supporting PTP timestamping:
> igb and bfin_mac. From the PTP developer point of view, the interface
> looks rather complete to me and it works fine on my MPC8313 setup.

Do you know whether these two also have PTP clocks? If so, is the API
that I suggested going to work for controlling those clocks, too?

> The only thing I stumbled over was that PTP clock registration
> failed when PTP support is statically linked into the kernel.

Okay, will look into that...

Thanks,
Richard


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-29 15:34   ` Richard Cochran
@ 2010-04-29 20:30     ` Wolfgang Grandegger
  2010-05-02 11:51     ` Wolfgang Grandegger
  1 sibling, 0 replies; 17+ messages in thread
From: Wolfgang Grandegger @ 2010-04-29 20:30 UTC (permalink / raw)
  To: Richard Cochran; +Cc: netdev

Richard Cochran wrote:
> On Thu, Apr 29, 2010 at 02:02:59PM +0200, Wolfgang Grandegger wrote:
>> I realized two other netdev drivers already supporting PTP timestamping:
>> igb and bfin_mac. From the PTP developer point of view, the interface
>> looks rather complete to me and it works fine on my MPC8313 setup.
> 
> Do you know whether these two also have PTP clocks? If so, is the API
> that I suggested going to work for controlling those clocks, too?

Well, I don't really know that hardware in detail. I just browsed the
code, e.g:

http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commit;h=38c845c76
http://marc.info/?l=linux-netdev&m=126389931509102&w=2

But I believe that your interface is generic enough to support that
hardware as well. Would make sense to put the relevant people on CC and
also "ptpd@lists.infradead.org."

Wolfgang.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support
  2010-04-29 15:34   ` Richard Cochran
  2010-04-29 20:30     ` Wolfgang Grandegger
@ 2010-05-02 11:51     ` Wolfgang Grandegger
  1 sibling, 0 replies; 17+ messages in thread
From: Wolfgang Grandegger @ 2010-05-02 11:51 UTC (permalink / raw)
  To: Richard Cochran; +Cc: netdev

Richard Cochran wrote:
> On Thu, Apr 29, 2010 at 02:02:59PM +0200, Wolfgang Grandegger wrote:
>> I realized two other netdev drivers already supporting PTP timestamping:
>> igb and bfin_mac. From the PTP developer point of view, the interface
>> looks rather complete to me and it works fine on my MPC8313 setup.
> 
> Do you know whether these two also have PTP clocks? If so, is the API
> that I suggested going to work for controlling those clocks, too?
> 
>> The only thing I stumbled over was that PTP clock registration
>> failed when PTP support is statically linked into the kernel.
> 
> Okay, will look into that...

With subsys_initcall(), ptp_gianfar_init() is called very early and
*before* ptp_init(). It works fine with module_init(). The
ptp_gianfar_init() is then called after gianfar_init().

There is another minor issue with module init/probe ordering.
gianfar_ptp_probe() does overtake the time from the system clock, which
may happen before the RTC is probed and initialized. But syncing with
the system time is a separate issue anyway.

Wolfgang.

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2010-05-02 11:53 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-27  9:13 [PATCH 0/3] [RFC] ptp: IEEE 1588 clock support Richard Cochran
2010-04-27 10:20 ` Richard Cochran
2010-04-27 13:35   ` Wolfgang Grandegger
2010-04-27 16:20     ` Wolfgang Grandegger
2010-04-28  5:47       ` Richard Cochran
2010-04-28 13:50         ` Wolfgang Grandegger
2010-04-28 14:31           ` Wolfgang Grandegger
2010-04-29  6:54             ` Richard Cochran
     [not found]               ` <20100429065422.GA5803-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
2010-04-29  8:08                 ` Wolfgang Grandegger
2010-04-29  8:38             ` Richard Cochran
2010-04-29  9:24               ` Wolfgang Grandegger
2010-04-29  9:42                 ` Richard Cochran
2010-04-29 11:31                   ` Wolfgang Grandegger
2010-04-29 12:02 ` Wolfgang Grandegger
2010-04-29 15:34   ` Richard Cochran
2010-04-29 20:30     ` Wolfgang Grandegger
2010-05-02 11:51     ` Wolfgang Grandegger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).