From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A90F9C04AB5 for ; Thu, 6 Jun 2019 20:38:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7B65E2089E for ; Thu, 6 Jun 2019 20:38:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727572AbfFFUiB convert rfc822-to-8bit (ORCPT ); Thu, 6 Jun 2019 16:38:01 -0400 Received: from mga06.intel.com ([134.134.136.31]:40139 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726631AbfFFUiB (ORCPT ); Thu, 6 Jun 2019 16:38:01 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2019 13:38:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,560,1557212400"; d="scan'208";a="182441324" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga002.fm.intel.com with ESMTP; 06 Jun 2019 13:38:00 -0700 Received: from orsmsx151.amr.corp.intel.com (10.22.226.38) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 6 Jun 2019 13:37:59 -0700 Received: from orsmsx121.amr.corp.intel.com ([169.254.10.133]) by ORSMSX151.amr.corp.intel.com ([169.254.7.242]) with mapi id 14.03.0415.000; Thu, 6 Jun 2019 13:37:59 -0700 From: "Keller, Jacob E" To: Richard Cochran , "Kirsher, Jeffrey T" CC: "davem@davemloft.net" , "netdev@vger.kernel.org" , "nhorman@redhat.com" , "sassmann@redhat.com" , "Bowers, AndrewX" Subject: RE: [net-next 06/15] ixgbe: fix PTP SDP pin setup on X540 hardware Thread-Topic: [net-next 06/15] ixgbe: fix PTP SDP pin setup on X540 hardware Thread-Index: AQHVG9yW/TezwgfQ60mS3GcVgIS18KaOa00AgACrTtA= Date: Thu, 6 Jun 2019 20:37:59 +0000 Message-ID: <02874ECE860811409154E81DA85FBB5896745E05@ORSMSX121.amr.corp.intel.com> References: <20190605202358.2767-1-jeffrey.t.kirsher@intel.com> <20190605202358.2767-7-jeffrey.t.kirsher@intel.com> <20190606032050.4uwzcc7rdx3dkw5x@localhost> In-Reply-To: <20190606032050.4uwzcc7rdx3dkw5x@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTk5N2FmZDEtZGViOS00YmEzLThhYmQtYjE3OTYxMDE5ZDljIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNlJtUWM4WjZtMXdSYVMya3BpZXJpT0dMdXUwMFdJTzM1R1hGRHhUQU5HSmVhSHFGdW9QYkYrTFdmZkZzREVjdSJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > -----Original Message----- > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On > Behalf Of Richard Cochran > Sent: Wednesday, June 05, 2019 8:21 PM > To: Kirsher, Jeffrey T > Cc: davem@davemloft.net; Keller, Jacob E ; > netdev@vger.kernel.org; nhorman@redhat.com; sassmann@redhat.com; Bowers, > AndrewX > Subject: Re: [net-next 06/15] ixgbe: fix PTP SDP pin setup on X540 hardware > > On Wed, Jun 05, 2019 at 01:23:49PM -0700, Jeff Kirsher wrote: > > + * It calculates when the system time will be on an exact second, and then > > + * aligns the start of the PPS signal to that value. > > + * > > + * This works by using the cycle counter shift and mult values in reverse, and > > + * assumes that the values we're shifting will not overflow. > > So I guess that this device can't adjust the frequency in hardware, > and that is why the driver uses a timecounter. > No. We use the timecounter to track the time offset, not the frequency. That is, our hardware can't represent 64bits of time, but it can adjust frequency. The time counter is used to track the adjustments from adjtime and set time, but not adjfreq. The timecounter is used to provide two features: (a) storing a full 64bits of time for passing back to the PTP stack and (b) atomic adjustments in adjtime. When programming the SDP we need to reverse the calculations done so that they're in terms of the SYSTIME values. But the frequency changes are all done directly to the SYSTIME increment values, and should be reflected properly in the pin output. > BUT your PPS will not be correct. You use the 'mult' to calculate the > future counter time of the PPS, but as soon as the PTP stack adjusts > the frequency (and changes 'mult') the PPS will occur at the wrong > time. Every path which changes mult (which is only link speed changes as far as I remember offhand) re-programs the PPS. We also re-program the pin at adjtime and settime. There should be no caller outside of our driver who adjusts the multiplier. Thanks, Jake > > Sorry to say it, > Richard