Thread: [Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp har
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
From: Takahiro S. <tsh...@gm...> - 2012-03-13 07:28:03
|
Hello, I am using ptp4l with hardware clock. The ieee1588 hardware is Intel EG20T. EG20T ieee1588 hardware needs destination MAC address to capture the ptp message. I implement it in ptp_pch_probe function now. The usage is like below: insmod ptp_pch.ko station="01:00:5e:00:01:81" This is good if the MAC address is unicast. Because it is known already. However it is NG if the MAC address is multicast. Because it is decided when the linuxptp is started. So, I want to add the new command between ptp driver and linuxptp. One possibility is to define the new ioctl of socket interface. However it needs to change gbe, ptp driver and linuxptp. Another possibility is to use the interface between ptp driver and linuxptp. It seems simple. However I can not see any direct interface between ptp driver and linuxptp. Question: 1. Which is better to add the new command for ptp driver? 2. Is it possible to add new interface between ptp driver and linuxptp (e.g. ioctl)? 3. Does anyone have other better idea? Thanks and Best regards, Takahiro Shimizu |
From: Richard C. <ric...@gm...> - 2012-03-13 12:15:24
|
On Tue, Mar 13, 2012 at 04:27:54PM +0900, Takahiro Shimizu wrote: > EG20T ieee1588 hardware needs destination MAC address to capture the ptp > message. > I implement it in ptp_pch_probe function now. > The usage is like below: > insmod ptp_pch.ko station="01:00:5e:00:01:81" > This is good if the MAC address is unicast. Because it is known already. > However it is NG if the MAC address is multicast. Because it is decided > when the linuxptp is started. Why do you need to set the station address? According to the EG20T Datasheet (Intel 3242111-006US), the station address fields are not used. In Table 617, page 523, "PTP Frame Identification", the MAC addresses are not used at all. Just leave the station address registers as zero. > So, I want to add the new command between ptp driver and linuxptp. > One possibility is to define the new ioctl of socket interface. > However it needs to change gbe, ptp driver and linuxptp. > Another possibility is to use the interface between ptp driver and linuxptp. > It seems simple. > However I can not see any direct interface between ptp driver and linuxptp. > > Question: > 1. Which is better to add the new command for ptp driver? > 2. Is it possible to add new interface between ptp driver and linuxptp > (e.g. ioctl)? > 3. Does anyone have other better idea? I don't see any need for such an interface. Richard |
From: Takahiro S. <tsh...@gm...> - 2012-03-13 23:47:40
|
Hello, Thank you for the response. However, if I set the station address as 0, I can not get the timestamp... I will ask it to the EG20T hardware engineer. Thanks and Best regards, Takahiro Shimizu 2012/3/13 Richard Cochran <ric...@gm...> > On Tue, Mar 13, 2012 at 04:27:54PM +0900, Takahiro Shimizu wrote: > > EG20T ieee1588 hardware needs destination MAC address to capture the ptp > > message. > > I implement it in ptp_pch_probe function now. > > The usage is like below: > > insmod ptp_pch.ko station="01:00:5e:00:01:81" > > This is good if the MAC address is unicast. Because it is known already. > > However it is NG if the MAC address is multicast. Because it is decided > > when the linuxptp is started. > > Why do you need to set the station address? > > According to the EG20T Datasheet (Intel 3242111-006US), the station > address fields are not used. In Table 617, page 523, "PTP Frame > Identification", the MAC addresses are not used at all. > > Just leave the station address registers as zero. > > > So, I want to add the new command between ptp driver and linuxptp. > > One possibility is to define the new ioctl of socket interface. > > However it needs to change gbe, ptp driver and linuxptp. > > Another possibility is to use the interface between ptp driver and > linuxptp. > > It seems simple. > > However I can not see any direct interface between ptp driver and > linuxptp. > > > > Question: > > 1. Which is better to add the new command for ptp driver? > > 2. Is it possible to add new interface between ptp driver and linuxptp > > (e.g. ioctl)? > > 3. Does anyone have other better idea? > > I don't see any need for such an interface. > > Richard > |
From: Takahiro S. <tsh...@gm...> - 2012-03-14 04:51:42
|
Hello I confirmed it to the engineer. It seems the mistake of EG20T datasheet. Destination MAC address is compared with station address registers. However there are no interface between linuxptp and ptp driver. I will use another solution. I will use the same station address as linuxptp in EG20T ptp driver like below. #define DEFAULT_MULTICAST_MAC_ADDR "01:00:5e:00:01:81" // This is the same as "224.0.1.129". pch_probe(struct pci_dev *pdev, const struct pci_device_id *id) : pch_set_station_address(DEFAULT_MULTICAST_MAC_ADDR, pdev); I think this is simple and good way now. Thanks and Best regards, Takahiro Shimizu 2012/3/14 Takahiro Shimizu <tsh...@gm...> > Hello, > > Thank you for the response. > > However, if I set the station address as 0, I can not get the timestamp... > I will ask it to the EG20T hardware engineer. > > Thanks and Best regards, > Takahiro Shimizu > > 2012/3/13 Richard Cochran <ric...@gm...> > >> On Tue, Mar 13, 2012 at 04:27:54PM +0900, Takahiro Shimizu wrote: >> > EG20T ieee1588 hardware needs destination MAC address to capture the ptp >> > message. >> > I implement it in ptp_pch_probe function now. >> > The usage is like below: >> > insmod ptp_pch.ko station="01:00:5e:00:01:81" >> > This is good if the MAC address is unicast. Because it is known already. >> > However it is NG if the MAC address is multicast. Because it is decided >> > when the linuxptp is started. >> >> Why do you need to set the station address? >> >> According to the EG20T Datasheet (Intel 3242111-006US), the station >> address fields are not used. In Table 617, page 523, "PTP Frame >> Identification", the MAC addresses are not used at all. >> >> Just leave the station address registers as zero. >> >> > So, I want to add the new command between ptp driver and linuxptp. >> > One possibility is to define the new ioctl of socket interface. >> > However it needs to change gbe, ptp driver and linuxptp. >> > Another possibility is to use the interface between ptp driver and >> linuxptp. >> > It seems simple. >> > However I can not see any direct interface between ptp driver and >> linuxptp. >> > >> > Question: >> > 1. Which is better to add the new command for ptp driver? >> > 2. Is it possible to add new interface between ptp driver and linuxptp >> > (e.g. ioctl)? >> > 3. Does anyone have other better idea? >> >> I don't see any need for such an interface. >> >> Richard >> > > |
From: Richard C. <ric...@gm...> - 2012-03-14 06:55:54
|
On Wed, Mar 14, 2012 at 01:51:35PM +0900, Takahiro Shimizu wrote: > Hello > > I confirmed it to the engineer. > It seems the mistake of EG20T datasheet. > Destination MAC address is compared with station address registers. Wow, your hardware really, really stinks. How then can you support IPv4 on one port and L2 on another? How can you support the peer delay mechanism? > I will use the same station address as linuxptp in EG20T ptp driver like > below. > > #define DEFAULT_MULTICAST_MAC_ADDR "01:00:5e:00:01:81" // This is the same > as "224.0.1.129". > > pch_probe(struct pci_dev *pdev, const struct pci_device_id *id) > : > pch_set_station_address(DEFAULT_MULTICAST_MAC_ADDR, pdev); > > I think this is simple and good way now. Yes, I agree. You will have to live with a work around. Your hardware really cannot support IEEE Std 1588-2008. For peer delay mechanism via L2, you must accept two *different* MAC addresses. Your driver will have to program the correct multicast MAC address based on the SIOCSHWTSTAMP ioctl. Your driver can only support certain values for rx_filter: HWTSTAMP_FILTER_PTP_V2_L4_EVENT SA = 01:00:5e:00:01:81 (E2E mechanism only) HWTSTAMP_FILTER_PTP_V2_L2_EVENT SA = 01:1b:19:00:00:00 (E2E mechanism only) HWTSTAMP_FILTER_PTP_V2_EVENT not supported! Sorry, Richard |
From: Takahiro S. <tsh...@gm...> - 2012-03-14 08:26:27
|
Hello, Thank you very much for the response. Yes, I agree. You will have to live with a work around. Your hardware > really cannot support IEEE Std 1588-2008. For peer delay mechanism via > L2, you must accept two *different* MAC addresses. > > Your driver will have to program the correct multicast MAC address > based on the SIOCSHWTSTAMP ioctl. Your driver can only support certain > values for rx_filter: > > HWTSTAMP_FILTER_PTP_V2_L4_EVENT SA = 01:00:5e:00:01:81 (E2E mechanism > only) > HWTSTAMP_FILTER_PTP_V2_L2_EVENT SA = 01:1b:19:00:00:00 (E2E mechanism > only) > HWTSTAMP_FILTER_PTP_V2_EVENT not supported! > > I have some question. 1. If SA means Distination MAC address (Station Address register 1-6), could you tell me the usage of the above ioctl? Now linuxptp uses HWTSTAMP_FILTER_PTP_V2_EVENT. If I implement the driver like the above, I modify the linuxptp using HWTSTAMP_FILTER_PTP_V2_L4_EVENT or HWTSTAMP_FILTER_PTP_V2_L2_EVENT and test them? 2. Or you mean that SA is source address? If so, my hardware does not filter about source address. It filter only Destination address using Station Address registers1-6. I can accept two *different * Source MAC address for Rx message. I can not accept two *different* Destination MAC address for RX message. Thanks and Best regards, Takahiro Shimizu |
From: Takahiro S. <tsh...@gm...> - 2012-03-14 10:26:49
|
Hello, I get IEEE1588-2008 specification. My understanding about your saying is; 1. "HWTSTAMP_FILTER_PTP_V2_L4_EVENT SA = 01:00:5e:00:01:81" means "PTP-primary All except peer delay mechanism messages 224.0.1.129" in Table D.1 IPv4 multicast addresses in the standard. 2. "HWTSTAMP_FILTER_PTP_V2_L2_EVENT SA = 01:1b:19:00:00:00" means "All except peer delay mechanism messages 01-1B-19-00-00-00" in Table F.1 Multicast MAC addresses in the standard. 3. HWTSTAMP_FILTER_PTP_V2_EVENT means supports L2 event and L4 event at the same time. This means we should support both addresses in Table D.1 or F.1 at the same time. 4. "How can you support the peer delay mechanism?" means we should support "PTP-primary All except peer delay mechanism messages 224.0.1.129" and "PTP-pdelay Peer delay mechanism messages 224.0.0.107" or "All except peer delay mechanism messages 01-1B-19-00-00-00" and "Peer delay mechanism messages 01-80-C2-00-00-0E". Is my understanding correct? Thanks, Takahiro Shimizu 2012/3/14 Takahiro Shimizu <tsh...@gm...> > Hello, > > Thank you very much for the response. > > Yes, I agree. You will have to live with a work around. Your hardware >> really cannot support IEEE Std 1588-2008. For peer delay mechanism via >> L2, you must accept two *different* MAC addresses. >> >> Your driver will have to program the correct multicast MAC address >> based on the SIOCSHWTSTAMP ioctl. Your driver can only support certain >> values for rx_filter: >> >> HWTSTAMP_FILTER_PTP_V2_L4_EVENT SA = 01:00:5e:00:01:81 (E2E mechanism >> only) >> HWTSTAMP_FILTER_PTP_V2_L2_EVENT SA = 01:1b:19:00:00:00 (E2E mechanism >> only) >> HWTSTAMP_FILTER_PTP_V2_EVENT not supported! >> >> > I have some question. > 1. If SA means Distination MAC address (Station Address register 1-6), > could you tell me the usage of the above ioctl? > Now linuxptp uses HWTSTAMP_FILTER_PTP_V2_EVENT. If I implement the driver > like the above, I modify the linuxptp using HWTSTAMP_FILTER_PTP_V2_L4_EVENT > or HWTSTAMP_FILTER_PTP_V2_L2_EVENT and test them? > 2. Or you mean that SA is source address? > If so, my hardware does not filter about source address. > It filter only Destination address using Station Address registers1-6. > I can accept two *different * Source MAC address for Rx message. I can not > accept two *different* Destination MAC address for RX message. > > Thanks and Best regards, > Takahiro Shimizu > |
From: Richard C. <ric...@gm...> - 2012-03-14 18:56:08
|
On Wed, Mar 14, 2012 at 07:26:42PM +0900, Takahiro Shimizu wrote: > Hello, > > I get IEEE1588-2008 specification. > My understanding about your saying is; > 1. "HWTSTAMP_FILTER_PTP_V2_L4_EVENT SA = 01:00:5e:00:01:81" means > "PTP-primary All except peer delay mechanism messages 224.0.1.129" in Table > D.1 IPv4 multicast addresses in the standard. Yes. > 2. "HWTSTAMP_FILTER_PTP_V2_L2_EVENT SA = 01:1b:19:00:00:00" means "All > except peer delay mechanism messages 01-1B-19-00-00-00" in Table F.1 > Multicast MAC addresses in the standard. Yes. > 3. HWTSTAMP_FILTER_PTP_V2_EVENT means supports L2 event and L4 event at the > same time. This means we should support both addresses in Table D.1 or F.1 > at the same time. Yes. > 4. "How can you support the peer delay mechanism?" means we should support > "PTP-primary All except peer delay mechanism messages 224.0.1.129" and > "PTP-pdelay Peer delay mechanism messages 224.0.0.107" or "All except peer > delay mechanism messages 01-1B-19-00-00-00" and "Peer delay mechanism > messages 01-80-C2-00-00-0E". > Is my understanding correct? Yes, that is correct. In order to support the peer-to-peer (P2P) mechanism, you need to accept Ethernet packets with two different destination MAC addresses. The ptp4l does not yet implement P2P, but I will add this eventually. Richard |
From: Richard C. <ric...@gm...> - 2012-03-14 18:47:56
|
On Wed, Mar 14, 2012 at 05:26:18PM +0900, Takahiro Shimizu wrote: > Yes, I agree. You will have to live with a work around. Your hardware > > really cannot support IEEE Std 1588-2008. For peer delay mechanism via > > L2, you must accept two *different* MAC addresses. > > > > Your driver will have to program the correct multicast MAC address > > based on the SIOCSHWTSTAMP ioctl. Your driver can only support certain > > values for rx_filter: > > > > HWTSTAMP_FILTER_PTP_V2_L4_EVENT SA = 01:00:5e:00:01:81 (E2E mechanism > > only) > > HWTSTAMP_FILTER_PTP_V2_L2_EVENT SA = 01:1b:19:00:00:00 (E2E mechanism > > only) > > HWTSTAMP_FILTER_PTP_V2_EVENT not supported! > > > > > I have some question. > 1. If SA means Distination MAC address (Station Address register 1-6), > could you tell me the usage of the above ioctl? Sorry for the confusion. I meant SA = Station Address. > Now linuxptp uses HWTSTAMP_FILTER_PTP_V2_EVENT. If I implement the driver > like the above, I modify the linuxptp using HWTSTAMP_FILTER_PTP_V2_L4_EVENT > or HWTSTAMP_FILTER_PTP_V2_L2_EVENT and test them? Yes that is right. > I can accept two *different * Source MAC address for Rx message. I can not > accept two *different* Destination MAC address for RX message. Yes, and that is why the hardware will not fully support PTPv2. Richard |
From: Takahiro S. <tsh...@gm...> - 2012-03-14 23:48:17
|
Hello, > Yes, I agree. You will have to live with a work around. Your hardware > > > really cannot support IEEE Std 1588-2008. For peer delay mechanism via > > > L2, you must accept two *different* MAC addresses. > > > > > > Your driver will have to program the correct multicast MAC address > > > based on the SIOCSHWTSTAMP ioctl. Your driver can only support certain > > > values for rx_filter: > > > > > > HWTSTAMP_FILTER_PTP_V2_L4_EVENT SA = 01:00:5e:00:01:81 (E2E mechanism > > > only) > > > HWTSTAMP_FILTER_PTP_V2_L2_EVENT SA = 01:1b:19:00:00:00 (E2E mechanism > > > only) > > > HWTSTAMP_FILTER_PTP_V2_EVENT not supported! > > > > > > > > I have some question. > > 1. If SA means Distination MAC address (Station Address register 1-6), > > could you tell me the usage of the above ioctl? > > Sorry for the confusion. I meant SA = Station Address. > > > Now linuxptp uses HWTSTAMP_FILTER_PTP_V2_EVENT. If I implement the driver > > like the above, I modify the linuxptp using > HWTSTAMP_FILTER_PTP_V2_L4_EVENT > > or HWTSTAMP_FILTER_PTP_V2_L2_EVENT and test them? > > Yes that is right. > > > I can accept two *different * Source MAC address for Rx message. I can > not > > accept two *different* Destination MAC address for RX message. > > Yes, and that is why the hardware will not fully support PTPv2. > > How about the following implementation? HWTSTAMP_FILTER_PTP_V2_L4_EVENT SA = 01:00:5e:00:01:81 (E2E mechanism only) HWTSTAMP_FILTER_PTP_V2_L2_EVENT SA = 01:1b:19:00:00:00 (E2E mechanism only) HWTSTAMP_FILTER_PTP_V2_EVENT The same as HWTSTAMP_FILTER_PTP_V2_L4_EVENT I want that the user uses linuptp and EG20T driver by default. It seems that the current linuxptp does not use SA = 01:1b:19:00:00:00 by default. If so, I want to implement like the above. It is the limitation of the EG20T ptp driver. Thanks and Best regards, Takahiro Shimizu |
From: Richard C. <ric...@gm...> - 2012-03-15 06:42:38
|
On Thu, Mar 15, 2012 at 08:48:10AM +0900, Takahiro Shimizu wrote: > HWTSTAMP_FILTER_PTP_V2_L4_EVENT SA = 01:00:5e:00:01:81 (E2E mechanism only) > HWTSTAMP_FILTER_PTP_V2_L2_EVENT SA = 01:1b:19:00:00:00 (E2E mechanism only) > HWTSTAMP_FILTER_PTP_V2_EVENT The same as HWTSTAMP_FILTER_PTP_V2_L4_EVENT > > I want that the user uses linuptp and EG20T driver by default. > It seems that the current linuxptp does not use SA = 01:1b:19:00:00:00 by > default. > If so, I want to implement like the above. > It is the limitation of the EG20T ptp driver. Yes, I agree. This makes sense as a workaround for testing. But I think we should do the following to be correct. driver: switch (rx_filter) { case HWTSTAMP_FILTER_PTP_V2_EVENT: return ERANGE; case HWTSTAMP_FILTER_PTP_V2_L4_EVENT: SA = 01:00:5e:00:01:81; case HWTSTAMP_FILTER_PTP_V2_L2_EVENT: SA = 01:1b:19:00:00:00; } Also, the driver's Kconfig needs a statment that the hardware only supports the end-to-end mechanism and that the peer-to-peer mechanism is not supported. ptp4l: try (HWTSTAMP_FILTER_PTP_V2_EVENT); if (errno == ERANGE) { if (transport_is_L2) try (HWTSTAMP_FILTER_PTP_V2_L2_EVENT); else try (HWTSTAMP_FILTER_PTP_V2_L4_EVENT); } I will work on the ptp4l code. Can you please fix the driver? BTW David Miller already applied your first driver patches. So, you should submit any changes as patches on top of that. Thanks, Richard |
From: Takahiro S. <tsh...@gm...> - 2012-03-15 07:00:20
|
Hello, Yes, I agree. This makes sense as a workaround for testing. > But I think we should do the following to be correct. > > driver: > > switch (rx_filter) { > case HWTSTAMP_FILTER_PTP_V2_EVENT: > return ERANGE; > case HWTSTAMP_FILTER_PTP_V2_L4_EVENT: > SA = 01:00:5e:00:01:81; > case HWTSTAMP_FILTER_PTP_V2_L2_EVENT: > SA = 01:1b:19:00:00:00; > } > > I see. I will do like the above in the next patch. > Also, the driver's Kconfig needs a statment that the hardware only > supports the end-to-end mechanism and that the peer-to-peer > mechanism is not supported. > > OK. > ptp4l: > > try (HWTSTAMP_FILTER_PTP_V2_EVENT); > if (errno == ERANGE) { > if (transport_is_L2) > try (HWTSTAMP_FILTER_PTP_V2_L2_EVENT); > else > try (HWTSTAMP_FILTER_PTP_V2_L4_EVENT); > } > > Thank you very much. > I will work on the ptp4l code. Can you please fix the driver? > > BTW David Miller already applied your first driver patches. So, you > should submit any changes as patches on top of that. > > I see. I will send the new patch in V.3.4-rc? window. Thanks and Best regards, Takahiro Shimizu |
From: Richard C. <ric...@gm...> - 2012-03-15 10:33:40
|
On Thu, Mar 15, 2012 at 04:00:09PM +0900, Takahiro Shimizu wrote: > > BTW David Miller already applied your first driver patches. So, you > > should submit any changes as patches on top of that. > > > > > I see. I will send the new patch in V.3.4-rc? window. I would send them ASAP. Since the patches will be bug fixes, I think David Miller will apply them any time from now until the last v3.4-rc. Thanks, Richard |
From: Takahiro S. <tsh...@gm...> - 2012-03-15 10:56:01
|
> > > > BTW David Miller already applied your first driver patches. So, you > > > should submit any changes as patches on top of that. > > > > > > > > I see. I will send the new patch in V.3.4-rc? window. > > I would send them ASAP. > > Since the patches will be bug fixes, I think David Miller will apply > them any time from now until the last v3.4-rc. > > OK. I got the next-linux (next-20120314) from git. It includes ptp_pch and modified pch_gbe. I will make the patch using it and send it soon. Thanks, Takahiro Shimizu |