Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp693182pxb; Wed, 11 Nov 2020 13:56:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJxAwJIMe4VbRAgCz0vey+AzYnCDqLnM7MtcMXPQKYyGpOxNR9o6gS6BuOp7dIGUHkJkGcod X-Received: by 2002:a17:906:3a86:: with SMTP id y6mr5653504ejd.289.1605131799297; Wed, 11 Nov 2020 13:56:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605131799; cv=none; d=google.com; s=arc-20160816; b=mVMQhkfYTD8Pu1qgCT2IxSLJxwz7lJ1XNi6i5zfr/UhJ/VD67vyFkRi08tcW7o3UIL ZL68TB6GuxGxB0jCRG1VIZBkZ3hu0XRo+ex0kEF+pbJxa8sZuQjL6rU7Jc1Xq1RAOx0o zShls71kQ4wMTZfyxhiBkHR3DHGoa99bo4GWT+x8YxDjOaUBCcnPwl3ChJn7eiSXcX/e aXBpsFpkRYe30KUNAnEI6QElJ7ZYBYtGShvN//v+mUK1Oz502KNLzFMftO/TEl2TQL81 u1b0TgS6w9jB382gFVIuj/hJvAziaEKTs4XgpcxEYC3dkJ6ClgHJn2kheIb9WoCXe55F kaig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:organization:message-id:date:subject:cc:to :from; bh=aUTdpATExumO7M3S+WEKV4piamFOdM02Cwc/s296Qjs=; b=rzAjx3w3lmVsO+1UMIdm+MUdFaIEdfWWgOn9aSka1fzkAdgoiPMD4PPkAWj4GJQyg4 4r8i6NIO8Ygbd0hLBJAp+tCoeu61qEOQea3UDDS78uUc6haJzV8Rp3PiT8pGCaJI9s72 lVOB0JKZTquZ9TcGq4iYhoTf+30opDL1tr0+Rr8XaRrdo3pJA7ELrjLtWNJgPSCOjHE8 4uMHj5aIp5H/0AvSkc0dgEJio80ylVOII6t7GvQ9Ix0N73MnCi6L+dd/OxOPW5aeef85 mX4ty0PO4H/VPy3/0sUbUKWXBI0qvaaF/dwtJtSYcgmriIYDGgJff60FsGcOr+c44l5M 14yw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x9si2598473ejc.540.2020.11.11.13.56.15; Wed, 11 Nov 2020 13:56:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727035AbgKKVxM (ORCPT + 99 others); Wed, 11 Nov 2020 16:53:12 -0500 Received: from mailout11.rmx.de ([94.199.88.76]:35456 "EHLO mailout11.rmx.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726188AbgKKVxM (ORCPT ); Wed, 11 Nov 2020 16:53:12 -0500 Received: from kdin01.retarus.com (kdin01.dmz1.retloc [172.19.17.48]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout11.rmx.de (Postfix) with ESMTPS id 4CWdl71NHJz40np; Wed, 11 Nov 2020 22:53:07 +0100 (CET) Received: from mta.arri.de (unknown [217.111.95.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by kdin01.retarus.com (Postfix) with ESMTPS id 4CWdkr3cwHz2xDP; Wed, 11 Nov 2020 22:52:52 +0100 (CET) Received: from n95hx1g2.localnet (192.168.54.13) by mta.arri.de (192.168.100.104) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 11 Nov 2020 22:50:23 +0100 From: Christian Eggers To: Vladimir Oltean CC: Richard Cochran , Florian Fainelli , Andrew Lunn , Vivien Didelot , Jakub Kicinski , Rob Herring , Helmut Grohne , Paul Barker , Codrin Ciubotariu , George McCollister , Marek Vasut , Tristram Ha , "David S . Miller" , Woojung Huh , "Microchip Linux Driver Support" , , , Subject: Re: [RFC PATCH net-next 7/9] net: dsa: microchip: ksz9477: add hardware time stamping support Date: Wed, 11 Nov 2020 22:50:22 +0100 Message-ID: <2269731.xUjYGUPlbM@n95hx1g2> Organization: Arnold & Richter Cine Technik GmbH & Co. Betriebs KG In-Reply-To: <20201110193245.uwsmrqzio5hco7fb@skbuf> References: <20201019172435.4416-1-ceggers@arri.de> <20201110164045.jqdwvmz5lq4hg54l@skbuf> <20201110193245.uwsmrqzio5hco7fb@skbuf> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [192.168.54.13] X-RMX-ID: 20201111-225300-4CWdkr3cwHz2xDP-0@kdin01 X-RMX-SOURCE: 217.111.95.66 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vladimir, On Tuesday, 10 November 2020, 20:32:45 CET, Vladimir Oltean wrote: > On Tue, Nov 10, 2020 at 06:40:45PM +0200, Vladimir Oltean wrote: > > I am fairly confident that this is how your hardware works, because > > that's also how peer delay wants to be timestamped, it seems. > > So I was confident and also wrong, it appears. My KSZ9477 datasheet > says: > > In the host-to-switch direction, the 4-byte timestamp field is always > present when PTP is enabled, as shown in Figure 4-6. This is true for > all packets sent by the host, including IBA packets. The host uses this > field to insert the receive timestamp from PTP Pdelay_Req messages into > the Pdelay_Resp messages. For all other traffic and PTP message types, > the host should populate the timestamp field with zeros. > > Hm. Does that mean that the switch updates the originTimestamp field of > the Sync frames by itself? IMHO this is the best solution. User space / driver do not know the exact time (would require slow I2C transfer). So inserting the time in hardware seems to be the better solution. Maybe this is what the data sheet meant with "egress timestamp insertion". > Ok... Very interesting that they decided to > introduce a field in the tail tag for a single type of PTP message. > But something is still wrong if you need to special-case the negative > correctionField, it looks like the arithmetic is not done on the correct > number of bits, either by the driver or by the hardware. > Maybe I found the formula which is (should) applied to the correction field for PDelayResp: correction = correction_old + now + residental_delay + tx_latency - tail_tag : current value from the PTP header : Time of the PTP clock when entering the switch : Switching delay : Delay between time stamping unit and wire (configurable via register) : Time stamp in the tail tag The new correction value has been captured with Wireshark. For the measurement I simply halted the internal PTP clock and set it to zero (so it's value is exactly known). In the port's TX time stamp unit I got a non-zero time stamp anyway (between, 10 to 40 ns), so this must be the residential delay. I tested with different values for the correction field and the tail_tag. Negative values are no problem, but the calculation seems no to consider all bits. Measurements: - PTP clock: 0 (frozen) - Residential delay: variable - TX delay: 45 ns (default) - correction = 0xffff ffff ffff.ffff (-1.xxx ns) correction = correction + now + residental_delay + tx_latency - tail_tag = -1 + 0 40 + 45 0 = 84 (0000 0000 0054) wireshark: (0000 0000 0054) --> correct correction = correction + now + residental_delay + tx_latency - tail_tag = -1 + 0 32 + 45 1.000 = -924 (FFFF FFFF FC64) wireshark: (0000 FFFF FC64) --> wrong correction = correction + now + residental_delay + tx_latency - tail_tag = -1 + 0 24 + 45 2.000.000.000 = -1.926.258.108 (FFFF 8D2F A244) wireshark: (0000 7B9A CA44) --> wrong - correction = 0xffff ffff 0000.0000 (-65536.0 ns) correction = correction + now + residental_delay + tx_latency - tail_tag = -65536 0 24 + 45 0 = -65467 (FFFF FFFF 0045) wireshark: (FFFF FFFF 0045) --> correct correction = correction + now + residental_delay + tx_latency - tail_tag = -65536 + 0 32 + 45 1.000 = -66459 (FFFF FFFE FC65) wireshark: (0000 FFFE FC65) --> wrong Please note that the tail tag consist of 2 bits for seconds and 30 bit nanoseconds. So the value of 2.000.000.000 means 1s + 926.258.176 ns. As you are better in 2's complement as me, you can give me some more combinations for testing if you need. But in the end it looks like I should keep T2 in the tail tag. > And zeroing out the correctionField of the Pdelay_Resp on transmission, > to put that value into t_Tail_Tag? How can you squeeze a 48-bit value > into a 32-bit value without truncation? Only the lower bits are used. As long as PDelayResp doesn't take more than 4 seconds, this should be enough. regards Christian