Message ID | 20231213000249.2020835-1-justin.chen@broadcom.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp8078831vqy; Tue, 12 Dec 2023 16:02:59 -0800 (PST) X-Google-Smtp-Source: AGHT+IFK3ihqZZJZeGqNU5leVdxqb2WTijy2iyiCRJccKdTqfUQQcgjFp+THrXDgTscPAG8MltZc X-Received: by 2002:a05:6a20:d41d:b0:190:5e69:c9db with SMTP id il29-20020a056a20d41d00b001905e69c9dbmr2963499pzb.85.1702425778964; Tue, 12 Dec 2023 16:02:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702425778; cv=none; d=google.com; s=arc-20160816; b=p4G9+Yd6KS2LDuGE1DVhm8H/jFyveT2JBr/nEClLL80CGdQD3D0M9k1zyMCnO8/62P ndOEzkCJWO/BdF+3GDkyBGpuOKWIRmpW0nqu++A0JbJ4i1bQYS89qr35tpw17JPC0fPi U5X5eUd+ijPXQ5vqkSR3iv7np7ZBw+MSWHWBA8NyfXvLfJiJLIdemsl3d7iz0G1Oeglj gXjVWOU8KbcICK1s8RpR6ovTU064MNu0Nr7DtlkczmW9yuv74+Msy8lOyYV4ImzuPT1M QbebkI1ir9mtRjedOX8j9inZxkHVFSxUKDMcPYLVxADRTwoQBiR1ZlyS4d7XjNsI8m8z 0zww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from :dkim-signature; bh=1j8JaWPUr/J0udycqZlup2LSXZqOjnk8YhBqyAcNIjQ=; fh=FGPTW4l5wNnpfdNodB+lJYulkQBPQMt1F43VOLCfj38=; b=FYwihTttxjs72Cvv3keSbQG92h8+JdzlW4gq7iVAbhvX5gpLwckFqDgqMAjcKf/Bde yAhagNFRWEG8Jdia2WFTk8J3k5EQNquDBvRCWZA9Y3GBfqtCJLMQTS66wNsGGwAYK9gZ h1uPRVrQkeCUafldu+i6Q6hfRwwAiPo+2uvUTqgRu6CObPePmr/6Wl0H1UK/PQ7oPMau 6lWAcLHLCdQ+ATHDu6nlELNUahrlPBPHxz2+upORITbNjV6CnyMdAo7vXomLlnMRwtxY IXNeGFQ/6PjMXTz/j1kSJjUygIttFzvhrhK2piWE8wXHfezaxWV1DboE7xJUmbZlvOfW Cjhg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@broadcom.com header.s=google header.b="TQQtTIA/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id v19-20020a17090ac91300b00286c365df4bsi8691204pjt.30.2023.12.12.16.02.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Dec 2023 16:02:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@broadcom.com header.s=google header.b="TQQtTIA/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id BA8CE80B81D3; Tue, 12 Dec 2023 16:02:57 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377492AbjLMACt (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Tue, 12 Dec 2023 19:02:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47906 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232536AbjLMACs (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 12 Dec 2023 19:02:48 -0500 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A28A1B3 for <linux-kernel@vger.kernel.org>; Tue, 12 Dec 2023 16:02:54 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-28ad2f0b278so740927a91.0 for <linux-kernel@vger.kernel.org>; Tue, 12 Dec 2023 16:02:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1702425774; x=1703030574; darn=vger.kernel.org; h=mime-version:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=1j8JaWPUr/J0udycqZlup2LSXZqOjnk8YhBqyAcNIjQ=; b=TQQtTIA//BNtbbKq0alMNc+d1gLIC6F4V6/a3aHooU6chM8PLZw3sYEBcSbC+qV7mf HPWsGzGbRq4nza+5bKfBmtXS+pDeijMI8yceCQ4rx+pLqSdazX3INS3oKHkLvaVJySQ0 67L932DUOCYWv1EKH8B8GdKxV5/M77wz8TyFU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702425774; x=1703030574; h=mime-version:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1j8JaWPUr/J0udycqZlup2LSXZqOjnk8YhBqyAcNIjQ=; b=dXMtIqzZlvaOWOFJA/q7tXqQiNXhofUX9IhtDoh62toh3ik2xaU1ArjQRtP4VaCj1X OGhLXM0Xr/orbL3+VQ+2cIfTEBtmoFm9sipO7LpA7VFq8QVMvYfI5Gc+gr8wPQ0cin14 eGjxOanmAmTofd5EHmcSe10wxgkmxNnU4L+bSOCJCIeJy4cyRsYA4FHhOJVrl9RlXN6p Aw20JCB7bk2kFBmwOf+mymlDJ6tDet0n/QZZikieHpTjfl3grUfrPzsmD1lUWvSX01lL 4uZUop1yS7yKQmiYhzanq500VyaYKgGWAmhYyp/ETqEArGIDl549CoFux0KNyt6+LIFe ykYQ== X-Gm-Message-State: AOJu0Yzqvm/Zj4VpYlyYuTaVJFrT838C9jay6cs2VnnGFRhZmplaEOPd Mq0jCWoacngb4g3rdHb1JyaVNA== X-Received: by 2002:a17:903:64e:b0:1d0:cd9e:424c with SMTP id kh14-20020a170903064e00b001d0cd9e424cmr3464483plb.78.1702425774049; Tue, 12 Dec 2023 16:02:54 -0800 (PST) Received: from stbirv-lnx-1.igp.broadcom.net ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id n16-20020a170903111000b001d3320f6143sm2336460plh.269.2023.12.12.16.02.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Dec 2023 16:02:53 -0800 (PST) From: Justin Chen <justin.chen@broadcom.com> To: netdev@vger.kernel.org Cc: Justin Chen <justin.chen@broadcom.com>, Doug Berger <opendmb@gmail.com>, Florian Fainelli <florian.fainelli@broadcom.com>, Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, Andrew Lunn <andrew@lunn.ch>, Heiner Kallweit <hkallweit1@gmail.com>, Russell King <linux@armlinux.org.uk>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, linux-kernel@vger.kernel.org (open list) Subject: [PATCH] net: mdio: mdio-bcm-unimac: Delay before first poll Date: Tue, 12 Dec 2023 16:02:49 -0800 Message-Id: <20231213000249.2020835-1-justin.chen@broadcom.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000008a7a05060c58e3ff" X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MIME_NO_TEXT, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 12 Dec 2023 16:02:57 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785122813564127244 X-GMAIL-MSGID: 1785122813564127244 |
Series |
net: mdio: mdio-bcm-unimac: Delay before first poll
|
|
Commit Message
Justin Chen
Dec. 13, 2023, 12:02 a.m. UTC
With a clock interval of 400 nsec and a 64 bit transactions (32 bit
preamble & 16 bit control & 16 bit data), it is reasonable to assume
the mdio transaction will take 25.6 usec. Add a 30 usec delay before
the first poll to reduce the chance of a 1000-2000 usec sleep.
Reduce the timeout from 1000ms to 100ms as it is unlikely for the bus
to take this long.
Signed-off-by: Justin Chen <justin.chen@broadcom.com>
---
drivers/net/mdio/mdio-bcm-unimac.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Comments
On 12/12/23 16:02, Justin Chen wrote: > With a clock interval of 400 nsec and a 64 bit transactions (32 bit > preamble & 16 bit control & 16 bit data), it is reasonable to assume > the mdio transaction will take 25.6 usec. Add a 30 usec delay before > the first poll to reduce the chance of a 1000-2000 usec sleep. > > Reduce the timeout from 1000ms to 100ms as it is unlikely for the bus > to take this long. > > Signed-off-by: Justin Chen <justin.chen@broadcom.com> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> Thanks!
On Tue, Dec 12, 2023 at 04:02:49PM -0800, Justin Chen wrote: > With a clock interval of 400 nsec and a 64 bit transactions (32 bit > preamble & 16 bit control & 16 bit data), it is reasonable to assume > the mdio transaction will take 25.6 usec. Add a 30 usec delay before > the first poll to reduce the chance of a 1000-2000 usec sleep. #define MDIO_C45 0 suggests the hardware can do C45? The timing works out different then. Maybe add a comment by the udelay() that is assumes C22, to give a clue to somebody who is adding C45 support the delay needs to be re-evaluated. Andrew
On Wed, Dec 13, 2023 at 11:57:52AM +0100, Andrew Lunn wrote: > On Tue, Dec 12, 2023 at 04:02:49PM -0800, Justin Chen wrote: > > With a clock interval of 400 nsec and a 64 bit transactions (32 bit > > preamble & 16 bit control & 16 bit data), it is reasonable to assume > > the mdio transaction will take 25.6 usec. Add a 30 usec delay before > > the first poll to reduce the chance of a 1000-2000 usec sleep. > > #define MDIO_C45 0 > > suggests the hardware can do C45? The timing works out different then. > Maybe add a comment by the udelay() that is assumes C22, to give a > clue to somebody who is adding C45 support the delay needs to be > re-evaluated. Note, however, that the driver only supports C22 operations (it only populates the read|write functions, not the c45 variants). However, it doesn't explicitly set the MDIO_C22 bit in the configuration register, so what ends up being spat out on the bus would be dependent on the boot loader configuration. However, I'm wondering why unimac_mdio_poll() isn't written as (based on current code): return read_poll_timeout(unimac_mdio_readl(priv, MDIO_CMD), val, !(val & MDIO_START_BUSY), 2000, 2000000); rather than open-coding the io polling.
On 12/13/2023 7:01 AM, Russell King (Oracle) wrote: > On Wed, Dec 13, 2023 at 11:57:52AM +0100, Andrew Lunn wrote: >> On Tue, Dec 12, 2023 at 04:02:49PM -0800, Justin Chen wrote: >>> With a clock interval of 400 nsec and a 64 bit transactions (32 bit >>> preamble & 16 bit control & 16 bit data), it is reasonable to assume >>> the mdio transaction will take 25.6 usec. Add a 30 usec delay before >>> the first poll to reduce the chance of a 1000-2000 usec sleep. >> >> #define MDIO_C45 0 >> >> suggests the hardware can do C45? The timing works out different then. >> Maybe add a comment by the udelay() that is assumes C22, to give a >> clue to somebody who is adding C45 support the delay needs to be >> re-evaluated. Yes the hardware supports C45 though as Russell points out, the driver intentionally does not support it. > > Note, however, that the driver only supports C22 operations (it only > populates the read|write functions, not the c45 variants). > > However, it doesn't explicitly set the MDIO_C22 bit in the configuration > register, so what ends up being spat out on the bus would be dependent > on the boot loader configuration. The hardware is guaranteed to come up with the MDIO_C22 bit being set by default though it would not hurt setting it explicitly, that would be more future proof. > > However, I'm wondering why unimac_mdio_poll() isn't written as > (based on current code): > > return read_poll_timeout(unimac_mdio_readl(priv, MDIO_CMD), val, > !(val & MDIO_START_BUSY), 2000, > 2000000); > > rather than open-coding the io polling. The driver long predates the introduction of the iopoll.h header and its routines. That sounds like another change that could be made.
On Wed, Dec 13, 2023 at 03:01:09PM +0000, Russell King (Oracle) wrote: > On Wed, Dec 13, 2023 at 11:57:52AM +0100, Andrew Lunn wrote: > > On Tue, Dec 12, 2023 at 04:02:49PM -0800, Justin Chen wrote: > > > With a clock interval of 400 nsec and a 64 bit transactions (32 bit > > > preamble & 16 bit control & 16 bit data), it is reasonable to assume > > > the mdio transaction will take 25.6 usec. Add a 30 usec delay before > > > the first poll to reduce the chance of a 1000-2000 usec sleep. > > > > #define MDIO_C45 0 > > > > suggests the hardware can do C45? The timing works out different then. > > Maybe add a comment by the udelay() that is assumes C22, to give a > > clue to somebody who is adding C45 support the delay needs to be > > re-evaluated. > > Note, however, that the driver only supports C22 operations (it only > populates the read|write functions, not the c45 variants). Yes, i checked that. Which is why i used the wording 'a clue to somebody who is adding C45'. Not everybody adding such support would figure out the relevance of 30us and that it might not be optimal for C45. A comment might point them on the right line of thinking. That is all i was trying to say. Andrew
diff --git a/drivers/net/mdio/mdio-bcm-unimac.c b/drivers/net/mdio/mdio-bcm-unimac.c index e8cd8eef319b..1f89b1bdb90f 100644 --- a/drivers/net/mdio/mdio-bcm-unimac.c +++ b/drivers/net/mdio/mdio-bcm-unimac.c @@ -81,7 +81,9 @@ static inline unsigned int unimac_mdio_busy(struct unimac_mdio_priv *priv) static int unimac_mdio_poll(void *wait_func_data) { struct unimac_mdio_priv *priv = wait_func_data; - unsigned int timeout = 1000; + unsigned int timeout = 100; + + udelay(30); do { if (!unimac_mdio_busy(priv))