Re: Stmmac: fix for hw timestamp of GMAC 3 unit

2017-06-07 Thread Mario Molitor 

Hi Pepe,
thanks for the response.
I have to thanking for the development of stmmac driver.
Today I have sending the two patches as patches for net.git kernel. I was 
the last day to busy.

Thanks and best regards,
Marrio

-Ursprüngliche Nachricht- 
From: Giuseppe CAVALLARO

Sent: Tuesday, June 6, 2017 7:43 AM
To: Mario Molitor ; alexandre.tor...@st.com
Cc: net...@vger.kernel.org ; linux-kernel@vger.kernel.org
Subject: Re: Stmmac: fix for hw timestamp of GMAC 3 unit

Hi Mario

thanks for your tests, and, at first glance, your patches seem to be
sensible so,
please, send the changes as patches for net.git kernel.

Regards
Peppe


On 6/6/2017 12:11 AM, Mario Molitor wrote:

Dear stmmac maintainer group,

I have found an problem in stmmac driver of linux kernel and I hope for a 
fix in the mainline kernel.

At the moment I have two patch files which fix this problem for me.
The problem seems created with the commit 
d2042052a0aa6a54f01a0c9e14243ec040b100e2 and 
ba1ffd74df74a9efa5290f87632a0ed55f1aa387 has breakage the functionality of 
GMAC3 unit.

I assume that these commits were only tested with a GMAC4 unit.
I have got seen this problem with execution of ptp4l daemon on system with 
linux 4.11 Kernel.


===
root@QuantumXsoc:~ ptp4l -f /etc/ptp.cfg -i eth0 -m
ptp4l[47.928]: selected /dev/ptp0 as PTP clock
ptp4l[47.937]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[47.938]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[47.938]: port 1: link up
[   48.282709] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw 
timestamp 0
[   48.316316] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw 
timestamp 0
[   48.340260] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw 
timestamp 0
[   48.456738] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw 
timestamp 0

ptp4l[48.457]: port 1: received DELAY_REQ without timestamp
[   48.488442] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw 
timestamp 0
[   48.495599] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw 
timestamp 0

ptp4l[48.489]: port 1: received SYNC without timestamp



I have found two kind of problems and for this two patches (based on the 
4.11 kernel) which fix this problem.


1.) PTP_TCR_SNAPTYPSEL_1

The first problem was for my point of view the change of definition 
PTP_TCR_SNAPTYPSEL_1.  I think according the
CYCLON V documention only the bit 16 of snaptypesel should be set. (more 
information see Table 17-20 (cv_5v4.pdf) : Timestamp Snapshot Dependency 
on Register Bits)

I believe that the GMAC4 have another necessary definition.

( patch 0001-stmmac-fix-ptp-header-for-GMAC3-hw-timestamp.patch )

>From 2d54d58dc8548d98572eb5fbfe488ec59b4c0ef5 Mon Sep 17 00:00:00 2001
From: Mario Molitor <mario_moli...@web.de>
Date: Mon, 5 Jun 2017 18:58:49 +0200
Subject: [PATCH 1/2] stmmac: fix ptp header for GMAC3 hw timestamp

According the CYCLON V documention only the bit 16 of snaptypesel should 
set.
(more information see Table 17-20 (cv_5v4.pdf) : Timestamp Snapshot 
Dependency on Register Bits)


fixed: d2042052a0aa6a54f01a0c9e14243ec040b100e2
---
  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 ---
  drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h  |  3 ++-
  2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c

index 4498a38..13a1ac9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -471,7 +471,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device 
*dev, struct ifreq *ifr)

  /* PTP v1, UDP, any kind of event packet */
  config.rx_filter = HWTSTAMP_FILTER_PTP_V1_L4_EVENT;
  /* take time stamp for all event messages */
- snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+ if (priv->plat->has_gmac4)
+ snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
+ else
+ snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
  ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
  ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
@@ -503,7 +506,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device 
*dev, struct ifreq *ifr)

  config.rx_filter = HWTSTAMP_FILTER_PTP_V2_L4_EVENT;
  ptp_v2 = PTP_TCR_TSVER2ENA;
  /* take time stamp for all event messages */
- snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+ if (priv->plat->has_gmac4)
+ snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
+ else
+ snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
  ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
  ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
@@ -537,7 +543,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device 
*dev, struct ifreq *ifr)

  config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
  ptp_v2 = PTP_TCR_TSVER2ENA;
  /* take time stamp f

Re: Stmmac: fix for hw timestamp of GMAC 3 unit

2017-06-07 Thread Mario Molitor 

Hi Pepe,
thanks for the response.
I have to thanking for the development of stmmac driver.
Today I have sending the two patches as patches for net.git kernel. I was 
the last day to busy.

Thanks and best regards,
Marrio

-Ursprüngliche Nachricht- 
From: Giuseppe CAVALLARO

Sent: Tuesday, June 6, 2017 7:43 AM
To: Mario Molitor ; alexandre.tor...@st.com
Cc: net...@vger.kernel.org ; linux-kernel@vger.kernel.org
Subject: Re: Stmmac: fix for hw timestamp of GMAC 3 unit

Hi Mario

thanks for your tests, and, at first glance, your patches seem to be
sensible so,
please, send the changes as patches for net.git kernel.

Regards
Peppe


On 6/6/2017 12:11 AM, Mario Molitor wrote:

Dear stmmac maintainer group,

I have found an problem in stmmac driver of linux kernel and I hope for a 
fix in the mainline kernel.

At the moment I have two patch files which fix this problem for me.
The problem seems created with the commit 
d2042052a0aa6a54f01a0c9e14243ec040b100e2 and 
ba1ffd74df74a9efa5290f87632a0ed55f1aa387 has breakage the functionality of 
GMAC3 unit.

I assume that these commits were only tested with a GMAC4 unit.
I have got seen this problem with execution of ptp4l daemon on system with 
linux 4.11 Kernel.


===
root@QuantumXsoc:~ ptp4l -f /etc/ptp.cfg -i eth0 -m
ptp4l[47.928]: selected /dev/ptp0 as PTP clock
ptp4l[47.937]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[47.938]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[47.938]: port 1: link up
[   48.282709] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw 
timestamp 0
[   48.316316] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw 
timestamp 0
[   48.340260] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw 
timestamp 0
[   48.456738] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw 
timestamp 0

ptp4l[48.457]: port 1: received DELAY_REQ without timestamp
[   48.488442] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw 
timestamp 0
[   48.495599] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw 
timestamp 0

ptp4l[48.489]: port 1: received SYNC without timestamp



I have found two kind of problems and for this two patches (based on the 
4.11 kernel) which fix this problem.


1.) PTP_TCR_SNAPTYPSEL_1

The first problem was for my point of view the change of definition 
PTP_TCR_SNAPTYPSEL_1.  I think according the
CYCLON V documention only the bit 16 of snaptypesel should be set. (more 
information see Table 17-20 (cv_5v4.pdf) : Timestamp Snapshot Dependency 
on Register Bits)

I believe that the GMAC4 have another necessary definition.

( patch 0001-stmmac-fix-ptp-header-for-GMAC3-hw-timestamp.patch )

>From 2d54d58dc8548d98572eb5fbfe488ec59b4c0ef5 Mon Sep 17 00:00:00 2001
From: Mario Molitor 
Date: Mon, 5 Jun 2017 18:58:49 +0200
Subject: [PATCH 1/2] stmmac: fix ptp header for GMAC3 hw timestamp

According the CYCLON V documention only the bit 16 of snaptypesel should 
set.
(more information see Table 17-20 (cv_5v4.pdf) : Timestamp Snapshot 
Dependency on Register Bits)


fixed: d2042052a0aa6a54f01a0c9e14243ec040b100e2
---
  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 ---
  drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h  |  3 ++-
  2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c

index 4498a38..13a1ac9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -471,7 +471,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device 
*dev, struct ifreq *ifr)

  /* PTP v1, UDP, any kind of event packet */
  config.rx_filter = HWTSTAMP_FILTER_PTP_V1_L4_EVENT;
  /* take time stamp for all event messages */
- snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+ if (priv->plat->has_gmac4)
+ snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
+ else
+ snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
  ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
  ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
@@ -503,7 +506,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device 
*dev, struct ifreq *ifr)

  config.rx_filter = HWTSTAMP_FILTER_PTP_V2_L4_EVENT;
  ptp_v2 = PTP_TCR_TSVER2ENA;
  /* take time stamp for all event messages */
- snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+ if (priv->plat->has_gmac4)
+ snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
+ else
+ snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
  ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
  ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
@@ -537,7 +543,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device 
*dev, struct ifreq *ifr)

  config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
  ptp_v2 = PTP_TCR_TSVER2ENA;
  /* take time stamp for all event messages */

Re: Stmmac: fix for hw timestamp of GMAC 3 unit

2017-06-05 Thread Giuseppe CAVALLARO 

Hi Mario

thanks for your tests, and, at first glance, your patches seem to be 
sensible so,

please, send the changes as patches for net.git kernel.

Regards
Peppe


On 6/6/2017 12:11 AM, Mario Molitor wrote:

Dear stmmac maintainer group,

I have found an problem in stmmac driver of linux kernel and I hope for a fix 
in the mainline kernel.
At the moment I have two patch files which fix this problem for me.
The problem seems created with the commit 
d2042052a0aa6a54f01a0c9e14243ec040b100e2 and 
ba1ffd74df74a9efa5290f87632a0ed55f1aa387 has breakage the functionality of 
GMAC3 unit.
I assume that these commits were only tested with a GMAC4 unit.
I have got seen this problem with execution of ptp4l daemon on system with 
linux 4.11 Kernel.

===
root@QuantumXsoc:~ ptp4l -f /etc/ptp.cfg -i eth0 -m
ptp4l[47.928]: selected /dev/ptp0 as PTP clock
ptp4l[47.937]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[47.938]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[47.938]: port 1: link up
[   48.282709] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
[   48.316316] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
[   48.340260] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
[   48.456738] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
ptp4l[48.457]: port 1: received DELAY_REQ without timestamp
[   48.488442] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
[   48.495599] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
ptp4l[48.489]: port 1: received SYNC without timestamp



I have found two kind of problems and for this two patches (based on the 4.11 
kernel) which fix this problem.

1.) PTP_TCR_SNAPTYPSEL_1

The first problem was for my point of view the change of definition 
PTP_TCR_SNAPTYPSEL_1.  I think according the
CYCLON V documention only the bit 16 of snaptypesel should be set. (more 
information see Table 17-20 (cv_5v4.pdf) : Timestamp Snapshot Dependency on 
Register Bits)
I believe that the GMAC4 have another necessary definition.

( patch 0001-stmmac-fix-ptp-header-for-GMAC3-hw-timestamp.patch )

>From 2d54d58dc8548d98572eb5fbfe488ec59b4c0ef5 Mon Sep 17 00:00:00 2001
From: Mario Molitor 
Date: Mon, 5 Jun 2017 18:58:49 +0200
Subject: [PATCH 1/2] stmmac: fix ptp header for GMAC3 hw timestamp

According the CYCLON V documention only the bit 16 of snaptypesel should set.
(more information see Table 17-20 (cv_5v4.pdf) : Timestamp Snapshot Dependency 
on Register Bits)

fixed: d2042052a0aa6a54f01a0c9e14243ec040b100e2
---
  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 ---
  drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h  |  3 ++-
  2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4498a38..13a1ac9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -471,7 +471,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, 
struct ifreq *ifr)
/* PTP v1, UDP, any kind of event packet */
config.rx_filter = HWTSTAMP_FILTER_PTP_V1_L4_EVENT;
/* take time stamp for all event messages */
-   snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+   if (priv->plat->has_gmac4)
+   snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
+   else
+   snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
  
  			ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;

ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
@@ -503,7 +506,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, 
struct ifreq *ifr)
config.rx_filter = HWTSTAMP_FILTER_PTP_V2_L4_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
/* take time stamp for all event messages */
-   snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+   if (priv->plat->has_gmac4)
+   snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
+   else
+   snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
  
  			ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;

ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
@@ -537,7 +543,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, 
struct ifreq *ifr)
config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
/* take time stamp for all event

Re: Stmmac: fix for hw timestamp of GMAC 3 unit

2017-06-05 Thread Giuseppe CAVALLARO 

Hi Mario

thanks for your tests, and, at first glance, your patches seem to be 
sensible so,

please, send the changes as patches for net.git kernel.

Regards
Peppe


On 6/6/2017 12:11 AM, Mario Molitor wrote:

Dear stmmac maintainer group,

I have found an problem in stmmac driver of linux kernel and I hope for a fix 
in the mainline kernel.
At the moment I have two patch files which fix this problem for me.
The problem seems created with the commit 
d2042052a0aa6a54f01a0c9e14243ec040b100e2 and 
ba1ffd74df74a9efa5290f87632a0ed55f1aa387 has breakage the functionality of 
GMAC3 unit.
I assume that these commits were only tested with a GMAC4 unit.
I have got seen this problem with execution of ptp4l daemon on system with 
linux 4.11 Kernel.

===
root@QuantumXsoc:~ ptp4l -f /etc/ptp.cfg -i eth0 -m
ptp4l[47.928]: selected /dev/ptp0 as PTP clock
ptp4l[47.937]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[47.938]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[47.938]: port 1: link up
[   48.282709] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
[   48.316316] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
[   48.340260] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
[   48.456738] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
ptp4l[48.457]: port 1: received DELAY_REQ without timestamp
[   48.488442] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
[   48.495599] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
ptp4l[48.489]: port 1: received SYNC without timestamp



I have found two kind of problems and for this two patches (based on the 4.11 
kernel) which fix this problem.

1.) PTP_TCR_SNAPTYPSEL_1

The first problem was for my point of view the change of definition 
PTP_TCR_SNAPTYPSEL_1.  I think according the
CYCLON V documention only the bit 16 of snaptypesel should be set. (more 
information see Table 17-20 (cv_5v4.pdf) : Timestamp Snapshot Dependency on 
Register Bits)
I believe that the GMAC4 have another necessary definition.

( patch 0001-stmmac-fix-ptp-header-for-GMAC3-hw-timestamp.patch )

>From 2d54d58dc8548d98572eb5fbfe488ec59b4c0ef5 Mon Sep 17 00:00:00 2001
From: Mario Molitor 
Date: Mon, 5 Jun 2017 18:58:49 +0200
Subject: [PATCH 1/2] stmmac: fix ptp header for GMAC3 hw timestamp

According the CYCLON V documention only the bit 16 of snaptypesel should set.
(more information see Table 17-20 (cv_5v4.pdf) : Timestamp Snapshot Dependency 
on Register Bits)

fixed: d2042052a0aa6a54f01a0c9e14243ec040b100e2
---
  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 ---
  drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h  |  3 ++-
  2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4498a38..13a1ac9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -471,7 +471,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, 
struct ifreq *ifr)
/* PTP v1, UDP, any kind of event packet */
config.rx_filter = HWTSTAMP_FILTER_PTP_V1_L4_EVENT;
/* take time stamp for all event messages */
-   snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+   if (priv->plat->has_gmac4)
+   snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
+   else
+   snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
  
  			ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;

ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
@@ -503,7 +506,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, 
struct ifreq *ifr)
config.rx_filter = HWTSTAMP_FILTER_PTP_V2_L4_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
/* take time stamp for all event messages */
-   snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+   if (priv->plat->has_gmac4)
+   snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
+   else
+   snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
  
  			ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;

ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
@@ -537,7 +543,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, 
struct ifreq *ifr)
config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
/* take time stamp for all event messages */
-