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;
Date:   Thu, 22 Oct 2020 12:01:26 +0300
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Richard Cochran <richardcochran@gmail.com>
Cc:     Christian Eggers <ceggers@arri.de>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Helmut Grohne <helmut.grohne@intenta.de>,
        Paul Barker <pbarker@konsulko.com>,
        Codrin Ciubotariu <codrin.ciubotariu@microchip.com>,
        George McCollister <george.mccollister@gmail.com>,
        Marek Vasut <marex@denx.de>,
        Tristram Ha <Tristram.Ha@microchip.com>,
        "David S . Miller" <davem@davemloft.net>,
        Woojung Huh <woojung.huh@microchip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
        netdev@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH net-next 7/9] net: dsa: microchip: ksz9477: add
 hardware time stamping support
Message-ID: <20201022090126.h64hfnlajqelveku@skbuf>
References: <20201019172435.4416-1-ceggers@arri.de>
 <20201019172435.4416-8-ceggers@arri.de>
 <20201021233935.ocj5dnbdz7t7hleu@skbuf>
 <20201022030217.GA2105@hoboy.vegasvil.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201022030217.GA2105@hoboy.vegasvil.org>
Precedence: bulk

On Wed, Oct 21, 2020 at 08:02:17PM -0700, Richard Cochran wrote:
> On Thu, Oct 22, 2020 at 02:39:35AM +0300, Vladimir Oltean wrote:
> > So how _does_ that work for TI PHYTER?
> >
> > As far as we understand, the PHYTER appears to autonomously mangle PTP packets
> > in the following way:
> > - subtracting t2 on RX from the correctionField of the Pdelay_Req
> > - adding t3 on TX to the correctionField of the Pdelay_Resp
>
> The Phyter does not support peer-to-peer one step.

Ok, that's my mistake for not double-checking, sorry.

> The only driver that implements it is ptp_ines.c.
>
> And *that* driver/HW implements it correctly.

Is there documentation available for this timestamping block? I might be
missing some data, as the kernel driver is fairly pass-through for the
TX timestamping of the Pdelay_Resp, so the hardware might just 'do the
right thing'. I believe the answer lies within the timestamper's
per-port RX FIFO. Just guessing here, but I suspect that the RX FIFO
doesn't get cleared immediately after the host queries it, and the
hardware caches the last 100 events from the pool and uses the RX
timestamps of Pdelay_Req as t2 in the process of updating the
correctionField of Pdelay_Resp on TX. Would that be correct?