IEEE1588 driver of Topcliff PCH

Topcliff PCH is the platform controller hub that is going to be used in
Intel's upcoming general embedded platform. All IO peripherals in
Topcliff PCH are actually devices sitting on AMBA bus. 
Topcliff PCH has IEEE1588 I/F. This driver enables IEEE1588 function on CAN or
Ethernet communications.

Signed-off-by: Masayuki Ohtake <masa-korg@dsn.okisemi.com>
---
 drivers/char/Kconfig                     |    9 +
 drivers/char/Makefile                    |    2 +
 drivers/char/pch_ieee1588/Makefile       |    1 +
 drivers/char/pch_ieee1588/pch_ieee1588.c | 3947 ++++++++++++++++++++++++++++++
 drivers/char/pch_ieee1588/pch_ieee1588.h |  528 ++++
 5 files changed, 4487 insertions(+), 0 deletions(-)
 create mode 100755 drivers/char/pch_ieee1588/Makefile
 create mode 100644 drivers/char/pch_ieee1588/pch_ieee1588.c
 create mode 100644 drivers/char/pch_ieee1588/pch_ieee1588.h

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 7cfcc62..4784971 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -4,6 +4,15 @@
 
 menu "Character devices"
 
+config PCH_IEEE1588
+	tristate "PCH IEEE1588 of Intel Topcliff"
+	depends on PCI
+	help
+	  This driver is for PCH IEEE1588 of Topcliff which is an IOH for x86
+	  embedded processor.
+	  This driver enables IEEE1588 function on CAN or Ethernet
+	  communications.
+
 config VT
 	bool "Virtual terminal" if EMBEDDED
 	depends on !S390
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index 88d6eac..81fb2d0 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -113,6 +113,8 @@ obj-$(CONFIG_RAMOOPS)		+= ramoops.o
 obj-$(CONFIG_JS_RTC)		+= js-rtc.o
 js-rtc-y = rtc.o
 
+obj-$(CONFIG_PCH_IEEE1588)		+= pch_ieee1588/
+
 # Files generated that shall be removed upon make clean
 clean-files := consolemap_deftbl.c defkeymap.c
 
diff --git a/drivers/char/pch_ieee1588/Makefile b/drivers/char/pch_ieee1588/Makefile
new file mode 100755
index 0000000..e5199ac
--- ...
[ message continues ]

So it's a CAN or Ethernet driver?  If so, why isn't this a network


Do you have documentation for these new ioctls you are creating?  It's a

Do they all have to be ioctls?  What exactly are they doing?

And are they 32/64bit safe?

thanks,

greg k-h
--

[ message continues ]

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--

[ message continues ]

Best Regards,
Qi
[ message continues ]

Is the above definition is necessary?
I can't find appropriate header file defines 'TRUE' and 'FALSE'.
In addition, some drivers have these definitions.
For example, drivers/char/mwave/smapi.h has the above definitions.

Thanks, Ohtake
----- Original Message ----- 
From: "Wang, Qi" <qi.wang@intel.com>
To: "Greg KH" <gregkh@suse.de>; "Masayuki Ohtak" <masa-korg@dsn.okisemi.com>
Cc: <meego-dev@meego.com>; "LKML" <linux-kernel@vger.kernel.org>; "Wang, Yong Y" <yong.y.wang@intel.com>; "Khor, Andrew
Chih Howe" <andrew.chih.howe.khor@intel.com>; <arjan@linux.intel.com>
Sent: Wednesday, August 11, 2010 10:20 AM


--

[ message continues ]

if (a == TRUE).... isn't necessary. Just if (a)... so you needn't 'TRUE'.
If (a == FALSE)... isn't necessary also. Just if (!a)..

Best Regards,

[ message continues ]

I understand.
I will delete TRUE/FALSE definition.

Thanks, Ohtake.

----- Original Message ----- 
From: "Wang, Qi" <qi.wang@intel.com>
To: "Masayuki Ohtake" <masa-korg@dsn.okisemi.com>; "Greg KH" <gregkh@suse.de>
Cc: <arjan@linux.intel.com>; "Khor, Andrew Chih Howe" <andrew.chih.howe.khor@intel.com>; "Wang, Yong Y"
<yong.y.wang@intel.com>; "LKML" <linux-kernel@vger.kernel.org>; <meego-dev@meego.com>
Sent: Wednesday, August 11, 2010 11:18 AM


--

[ message continues ]

it's true and false. Lowercase. UNUSED is __unused.

-- 
balbi

DefectiveByDesign.org
--

[ message continues ]

Hi Balbi

I can do well.

Thanks! Ohtake.

----- Original Message ----- 
From: "Felipe Balbi" <felipe.balbi@nokia.com>
To: "ext Masayuki Ohtake" <masa-korg@dsn.okisemi.com>
Cc: "Greg KH" <gregkh@suse.de>; "Wang, Qi" <qi.wang@intel.com>; <arjan@linux.intel.com>; "Khor, Andrew Chih Howe"
<andrew.chih.howe.khor@intel.com>; "Wang, Yong Y" <yong.y.wang@intel.com>; "LKML" <linux-kernel@vger.kernel.org>;
<meego-dev@meego.com>
Sent: Wednesday, August 11, 2010 2:49 PM


--

[ message continues ]

I think using ioctl is common for this patch.
Do you think that using ioctl is NOT appropriate for this patch?
Only 32bit support.

Thanks, Ohtake
----- Original Message ----- 
From: "Greg KH" <gregkh@suse.de>
To: "Masayuki Ohtak" <masa-korg@dsn.okisemi.com>
Cc: <meego-dev@meego.com>; "LKML" <linux-kernel@vger.kernel.org>; <qi.wang@intel.com>; <yong.y.wang@intel.com>;
<andrew.chih.howe.khor@intel.com>; <arjan@linux.intel.com>
Sent: Wednesday, August 11, 2010 2:13 AM


--

[ message continues ]

Please express yours.  Why do you feel you need these to be ioctls?

That's an obvious problem that needs to be resolved, right?

thanks,

greg k-h
--

[ message continues ]

The Tunnelcreak processor (A kind of Atom-based processor) only supports 32b, so PCH drivers only support 32b.
They can make it 32/64 compatible, but it's difficult to test them, because there're no 64b Atom-based platform have those PCH devices.

Best Regards,
[ message continues ]

But that does not mean you should not be using the proper types and
other things necessary for proper ioctl usage.

As you failed to describe what any of these ioctls do, I can't recommend
that you have any of them in the driver.

sorry,

greg k-h
--

[ message continues ]

Sorry, for late response.
Please see out inline comments.

Thanks, Ohtake

----- Original Message ----- 
From: "Wang, Qi" <qi.wang@intel.com>
To: "Masayuki Ohtake" <masa-korg@dsn.okisemi.com>
Cc: <meego-dev@meego.com>; "LKML" <linux-kernel@vger.kernel.org>; "Wang, Yong Y" <yong.y.wang@intel.com>; "Khor, Andrew
Chih Howe" <andrew.chih.howe.khor@intel.com>; <arjan@linux.intel.com>; "Greg KH" <gregkh@suse.de>
Sent: Thursday, August 12, 2010 11:15 AM

Intel Topcliff IEEE1588 device driver API is developed according to Intel
Tolapai 1588 device driver.


--

[ message continues ]

But what is the "Intel Tolapai 1588 device driver?"

Is that a Linux driver?

If so, where can I find it?

Richard
--

[ message continues ]

I found it under
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17182

That driver was never submitted for inclusion anywhere, so it is not
really relevant here. The APIs are similar, but not identical, most
importantly they use a different ioctl command base number, but also
some of the structures are laid out slightly differently.

Ohtake-san, Richard's code already contains an abstraction for multiple
ieee1588 sources, which looks like it should perfectly fit your purposes.
I don't see room for another user interface, so please try to integrate
into version 5 of his ptp code.

	Arnd
--

[ message continues ]

We want to implement IEEE1588 driver for Intel EG20T PCH (Topcliff) using 
PTP core
according to you saying.
However, it seems PTP core module is not accepted by upstream.
How about your PTP status ?

Thanks,
---
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.

----- Original Message ----- 
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Richard Cochran" <richardcochran@gmail.com>
Cc: "Masayuki Ohtake" <masa-korg@dsn.okisemi.com>; <meego-dev@meego.com>; 
"LKML" <linux-kernel@vger.kernel.org>
Sent: Tuesday, August 17, 2010 8:25 PM
Subject: Re: [MeeGo-dev] [MeeGo-Dev][PATCH] Topcliff: Update PCH_IEEE1588 

--

[ message continues ]

I posted v6 back on September 23. Based on the comments, I think the
patch set is almost good enough for mainline inclusion (at least, I
hope so).

I am just getting ready to post v7, and the kernel interface will
change a bit. I will post it before Christmas, so perhaps you can wait
a bit. You can take look at the v6 code, since the general ideas will
not change very much.

Thanks,
Richard
--

[ message continues ]

Hi Richard,

Thank you for your PTP core's status information.
Accepted by upstream, we will start our development.

Thanks,
---
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.

----- Original Message ----- 
From: "Richard Cochran" <richardcochran@gmail.com>
To: "Tomoya MORINAGA" <tomoya-linux@dsn.okisemi.com>
Cc: "Arnd Bergmann" <arnd@arndb.de>; "LKML" <linux-kernel@vger.kernel.org>
Sent: Wednesday, December 15, 2010 1:21 AM
Subject: Re: [MeeGo-dev][PATCH] Topcliff: Update PCH_IEEE1588 driver to 

--

[ message continues ]

That _still_ did not answer the questions.  Please answer them.

greg k-h
--

[ message continues ]

I recently introduced a PTP clock infrastructure on the netdev
list. While the patch set is still under review, some necessary
background patches have already been accepted, and the response to the
API has been positive.

One major goal of the framework is to reduce the amount of driver code
need to support a new PTP clock. Another goal is remove the need for
MAC drivers to add a bunch of new, private ioctls just for PTP.

Please take a look at that patch set (latest was v4) and also submit
any PTP code on the netdev list for review.

In any case, a MAC driver that offers time stamping on network packets
must implement the SO_TIMESTAMPING API, which has been a part of Linux
since 2.6.30.

Richard
--

[ message continues ]

Are you aware of Richard Cochran's 1588 support patches? I'm not sure
about the integration status, but Richard (set on Cc:) can surely say
more.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--

[ message continues ]

Hi Robert

My specified CC of IEEE1588 patch e-mail is not enough.
I will re-submit the patch again.

Thanks, Ohtake.
----- Original Message ----- 
From: "Robert Schwebel" <r.schwebel@pengutronix.de>
To: "Masayuki Ohtak" <masa-korg@dsn.okisemi.com>
Cc: <meego-dev@meego.com>; "LKML" <linux-kernel@vger.kernel.org>; <qi.wang@intel.com>; <yong.y.wang@intel.com>;
<andrew.chih.howe.khor@intel.com>; <arjan@linux.intel.com>; <gregkh@suse.de>; "Richard Cochran"
<richard.cochran@omicron.at>
Sent: Wednesday, August 11, 2010 6:08 PM


--

[ message continues ]

The background work need for PHY time stamping has been accepted.

For the rest, I am preparing to post another patch set soon...

Thanks,
Richard
--

[ message continues ]