Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp10479570rwl; Wed, 11 Jan 2023 21:21:39 -0800 (PST) X-Google-Smtp-Source: AMrXdXuqK8CCz3UxgXACu54skBK7aX8xSwZ6//dTRuV4ekOKLcWpZogrp9cx2LdWni5QZpOOF9ak X-Received: by 2002:a17:90b:3ec4:b0:225:d605:6163 with SMTP id rm4-20020a17090b3ec400b00225d6056163mr65950937pjb.8.1673500898809; Wed, 11 Jan 2023 21:21:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673500898; cv=none; d=google.com; s=arc-20160816; b=yJbM6KdpZWEE4Kw4Amqo8o2kJWa67HbuGAQB0aJScSlritJQ3mM5Rv2y4PUDnYt7GU qC4gCpxYmtCdKDuvSWwed6Mu+4YJ25U/kP7gKvEweLKkGMSh1O/K7rF9hX2UK2RDOXHl Fde0+wkYMIKX/p1Y0a6IpDjEVzzyImhCJ5pQ3ova9902TzEiKc0QLSznvatILzdb62Vd q5T+IdT6due3ggifidS8XQGvVeTVhOc1oBiohCsrYjH3MvSo9w9d6GSe+eyEQuklyTc8 lXRQgGT/4kFrRopVyLGJhDN82d1T0FS796I3RWVhWYFDoNFaYQ8her94eFwpPe9cwWJ5 sYNw== 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:message-id:subject:cc:to:from:date :dkim-signature; bh=HVb/tdnNomwFrM4HjuWNHI+QvNwQ7cfjk7VY787Xz00=; b=Xz+u9880EGvQYWoOxAxdJ+7W8byh8Z1omB+R5ccqAl/OXJPNK+UFn4vBMoIXeKO845 /IheeLfXXn2uur9+MvtV39oXCwIuuilnhlV8VcaKktq/sfofxhUfbMtFU1oxvoU13moO XflUgAxH70GkQxNvDcif8K1UwCrrwlqM2mh472uTUOhmbd1XkJGe3H7Pj/MiBgf/hr9Y cPLPZ+8EOI1NIV8GC8h7CrjYsyWbdl8ITMXKt3usROVAKgPcSIYAJbbga2u9qSPMF/Au 5V5QJ7IjUZB3lPJVHoalJmmntoHMeF+b52VbsH0SrqAeN6xw9+EDQbTkJB0mUTDiEZ8d 45ww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=JWeirc7g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mu10-20020a17090b388a00b00219dbeefa87si18369138pjb.166.2023.01.11.21.21.32; Wed, 11 Jan 2023 21:21:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=JWeirc7g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236704AbjALFJS (ORCPT + 51 others); Thu, 12 Jan 2023 00:09:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239023AbjALFJB (ORCPT ); Thu, 12 Jan 2023 00:09:01 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E75B74F12C; Wed, 11 Jan 2023 21:09:00 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 9EA93B81C0B; Thu, 12 Jan 2023 05:08:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DFD2DC433D2; Thu, 12 Jan 2023 05:08:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673500138; bh=5TFiVEhUBziE7GBztNTOvIp+q6DvX5FSQA25pZQ7M1o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JWeirc7gi8NfIk/1a3GhDlVaClXc+AmJuHRPMQHJbMrU7nxbo8baIundGWPrg2tyd WPpb5J1pxLgsgVVf25gCLDxRgT1d7TVOzXnnw3A8e8EPVnX0/xGoj/x1wK56cc6PJ/ dqbdCgFAZFknTBk/Dgac/DnqBk7CrCX/QVMYRtaP+k5O7g3vzWkHGYO4jjnPnBzYMA 8hTB+vlNpx4yhrMJSRB4/cLZuAtR83LKmWkYNoQNixmPsbl6U5BwB2UoIHdS3HQ6p7 SpNNywL1Va72nWi+jVkmsQoWUdboYYqhQZtyrZR07CXC+cfOxSOKlz8Wtr2PvxuK4h Dtu8w973pgD9w== Date: Wed, 11 Jan 2023 21:08:56 -0800 From: Jakub Kicinski To: nikhil.gupta@nxp.com Cc: linux-arm-kernel@lists.infradead.org, Yangbo Lu , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, vakul.garg@nxp.com, rajan.gupta@nxp.com Subject: Re: [PATCH] ptp_qoriq: fix latency in ptp_qoriq_adjtime() operation. Message-ID: <20230111210856.745ef17c@kernel.org> In-Reply-To: <20230110113024.7558-1-nikhil.gupta@nxp.com> References: <20230110113024.7558-1-nikhil.gupta@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org please put [PATCH net-next] in the subject. On Tue, 10 Jan 2023 17:00:24 +0530 nikhil.gupta@nxp.com wrote: > From: Nikhil Gupta > > 1588 driver loses about 1us in adjtime operation at PTP slave. > This is because adjtime operation uses a slow non-atomic tmr_cnt_read() > followed by tmr_cnt_write() operation. So far so good.. > In the above sequence, since the timer counter operation loses about 1us. s/operation/keeps incrementing after the read/ ? but frankly I don't think this sentence adds much > Instead, tmr_offset register should be programmed with the delta > nanoseconds missing full stop at the end. You should describe what the tmr_offset register does. > This won't lead to timer counter stopping and losing time > while tmr_cnt_write() is being done. Stopping? The timer was actually stopping? > This Patch adds api for tmr_offset_read/write to program the Use imperative mood. > delta nanoseconds in the Timer offset Register. > > Signed-off-by: Nikhil Gupta > Reviewed-by: Yangbo Lu > --- > drivers/ptp/ptp_qoriq.c | 36 ++++++++++++++++++++++++++++++------ > 1 file changed, 30 insertions(+), 6 deletions(-) > > diff --git a/drivers/ptp/ptp_qoriq.c b/drivers/ptp/ptp_qoriq.c > index 08f4cf0ad9e3..5b6ea6d590be 100644 > --- a/drivers/ptp/ptp_qoriq.c > +++ b/drivers/ptp/ptp_qoriq.c > @@ -48,6 +48,29 @@ static void tmr_cnt_write(struct ptp_qoriq *ptp_qoriq, u64 ns) > ptp_qoriq->write(®s->ctrl_regs->tmr_cnt_h, hi); > } > > +static void tmr_offset_write(struct ptp_qoriq *ptp_qoriq, u64 delta_ns) > +{ > + struct ptp_qoriq_registers *regs = &ptp_qoriq->regs; > + u32 hi = delta_ns >> 32; > + u32 lo = delta_ns & 0xffffffff; > + > + ptp_qoriq->write(®s->ctrl_regs->tmroff_l, lo); > + ptp_qoriq->write(®s->ctrl_regs->tmroff_h, hi); > +} > + > +static u64 tmr_offset_read(struct ptp_qoriq *ptp_qoriq) > +{ > + struct ptp_qoriq_registers *regs = &ptp_qoriq->regs; > + u64 ns; > + u32 lo, hi; Order variable lines longest to shortest > + lo = ptp_qoriq->read(®s->ctrl_regs->tmroff_l); > + hi = ptp_qoriq->read(®s->ctrl_regs->tmroff_h); > + ns = ((u64) hi) << 32; > + ns |= lo; > + return ns; > +} > + > /* Caller must hold ptp_qoriq->lock. */ > static void set_alarm(struct ptp_qoriq *ptp_qoriq) > { > @@ -55,7 +78,9 @@ static void set_alarm(struct ptp_qoriq *ptp_qoriq) > u64 ns; > u32 lo, hi; > > - ns = tmr_cnt_read(ptp_qoriq) + 1500000000ULL; > + ns = tmr_cnt_read(ptp_qoriq) + tmr_offset_read(ptp_qoriq) > + + 1500000000ULL; > + > ns = div_u64(ns, 1000000000UL) * 1000000000ULL; > ns -= ptp_qoriq->tclk_period; > hi = ns >> 32; > @@ -207,15 +232,12 @@ EXPORT_SYMBOL_GPL(ptp_qoriq_adjfine); > > int ptp_qoriq_adjtime(struct ptp_clock_info *ptp, s64 delta) > { > - s64 now; > unsigned long flags; > struct ptp_qoriq *ptp_qoriq = container_of(ptp, struct ptp_qoriq, caps); > > spin_lock_irqsave(&ptp_qoriq->lock, flags); > > - now = tmr_cnt_read(ptp_qoriq); > - now += delta; > - tmr_cnt_write(ptp_qoriq, now); > + tmr_offset_write(ptp_qoriq, delta); Writes to the offset register result in an add operation? Or it's a pure write? What will the offset be after a sequence of following adjtime() calls: adjtime(+100); adjtime(+100); adjtime(+100); ? > set_fipers(ptp_qoriq); > > spin_unlock_irqrestore(&ptp_qoriq->lock, flags); > @@ -232,7 +254,7 @@ int ptp_qoriq_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts) > > spin_lock_irqsave(&ptp_qoriq->lock, flags); > > - ns = tmr_cnt_read(ptp_qoriq); > + ns = tmr_cnt_read(ptp_qoriq) + tmr_offset_read(ptp_qoriq); > > spin_unlock_irqrestore(&ptp_qoriq->lock, flags); > > @@ -251,6 +273,8 @@ int ptp_qoriq_settime(struct ptp_clock_info *ptp, > > ns = timespec64_to_ns(ts); > > + tmr_offset_write(ptp_qoriq, 0); Shouldn't this be under the lock? > spin_lock_irqsave(&ptp_qoriq->lock, flags); > > tmr_cnt_write(ptp_qoriq, ns);