From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Cochran Subject: Re: Improving accuracy of PHC readings Date: Mon, 22 Oct 2018 15:48:02 -0700 Message-ID: <20181022224802.5injr523fgw2c4qz@localhost> References: <20181019095137.GG4407@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org, "Keller, Jacob E" To: Miroslav Lichvar Return-path: Received: from mail-ed1-f51.google.com ([209.85.208.51]:44132 "EHLO mail-ed1-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726457AbeJWHIg (ORCPT ); Tue, 23 Oct 2018 03:08:36 -0400 Received: by mail-ed1-f51.google.com with SMTP id z21-v6so39491260edb.11 for ; Mon, 22 Oct 2018 15:48:05 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20181019095137.GG4407@localhost> Sender: netdev-owner@vger.kernel.org List-ID: On Fri, Oct 19, 2018 at 11:51:37AM +0200, Miroslav Lichvar wrote: > A solution to this would be a new driver function that wraps the > latching register read with readings of the system clock and return > three timestamps instead of one. For example: > > ktime_get_real_ts64(&sys_ts1); > IXGBE_READ_REG(hw, IXGBE_SYSTIMR); > ktime_get_real_ts64(&sys_ts2); > phc_ts.tv_nsec = IXGBE_READ_REG(hw, IXGBE_SYSTIML); > phc_ts.tv_sec = IXGBE_READ_REG(hw, IXGBE_SYSTIMH); Makes sense... > The extra timestamp doesn't fit the API of the PTP_SYS_OFFSET ioctl, > so it would need to shift the timestamp it returns by the missing > intervals (assuming the frequency offset between the PHC and system > clock is small), or a new ioctl could be introduced that would return > all timestamps in an array looking like this: > > [sys, phc, sys, sys, phc, sys, ...] How about a new ioctl with number of trials as input and single offset as output? Then it would be up to the driver to implement the device-specific loop. Thanks, Richard