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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9D89BC4332F for ; Fri, 23 Dec 2022 14:20:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Z0yhahEgwFzBH9Ao5aGT7EBwhl0mKhVVT1AH3Evq1Dk=; b=yTiGMDmAyFvAYD 5FbfYzKb9B+Cqo5/fHT3IQ8zzvtquFZItgd/Vu6ix3kDmLu0v/Gw2D6kfLHbrcExvysB8cg336h0L vLPFasW1XFaTp6rI3JEnUJs6412Vo9EnqA4xiq4nJXphecl99GCu6Rn4DO4WAD4UP6oSTkTXJBcmr cqzTo+x+Sm5LyF/QDiGtXdz3YMb3q2BUxdhm5IYzvIO11hpatKVubIHv1YVfrewpdKSQoAx77Ghzb 7Nz8aCexivK701arIKqPwdkGinQran0TxuoKFmlnNSKCN7CGarC5tg1A0GkgAaEnDhTpW/xtRSaDj jqodszuP6UnUKElpEpYg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p8it8-008mxN-Sa; Fri, 23 Dec 2022 14:19:07 +0000 Received: from vps0.lunn.ch ([156.67.10.101]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p8it4-008mrw-5o; Fri, 23 Dec 2022 14:19:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=yOe6ftm83MjcbSsPzfhXQYYG0KG1pAc9ELl18Zq14Gs=; b=M2rXfeoOXsELTA+n9t49bHnxKd /wuaZLFU+jz64uDHhv+ghw745Z3XrazuJOTRWkpzlOBC0e51iNCGGcb2N2OsIve322+kf9B8NNdAd MgP4OMuifOp1S+jNaZxbtOGlrLO2D1WYbDiWEi9FP9JNPOUohxdVdgQYtOPQN94VVw5c=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1p8ish-000LAe-KP; Fri, 23 Dec 2022 15:18:39 +0100 Date: Fri, 23 Dec 2022 15:18:39 +0100 From: Andrew Lunn To: Biao Huang Cc: AngeloGioacchino Del Regno , Rob Herring , Krzysztof Kozlowski , Matthias Brugger , Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , Richard Cochran , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, macpaul.lin@mediatek.com Subject: Re: [PATCH v5 1/2] stmmac: dwmac-mediatek: enable 2ns delay only for special cases Message-ID: References: <20221223015029.24978-1-biao.huang@mediatek.com> <20221223015029.24978-2-biao.huang@mediatek.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20221223015029.24978-2-biao.huang@mediatek.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221223_061902_287767_4060C1E4 X-CRM114-Status: GOOD ( 19.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Dec 23, 2022 at 09:50:28AM +0800, Biao Huang wrote: > In current driver, MAC will always enable 2ns delay in RGMII mode, > but that will lead to transmission failures for "rgmii-id"/"rgmii-txid" > cases. > > Modify the implementation of fix_mac_speed() to ensure the 2ns delay > will only take effect for "rgmii-rxid"/"rgmii" cases, then user can > choose phy-mode freely. This does not seem correct. There are three ways the delays can be added: 1) The MAC 2) The PHY 3) Extra long lines on the board. What the four RGMII modes tell you is what is needed in addition to whatever the board provides. So it describes the combination of 1) and 2). Your board does not appear to be applying any delays, so you should be using rgmii-id. The MAC and PHY driver then need to decide how to add these delays, and in most cases, the MAC does nothing, and passes phy-mode to the PHY and the PHY adds the delay. The MAC can add delays, but if it does, it need to mask out the delays it added to the value passed to the PHY. Otherwise the PHY will add the delay as well. > > - if ((phy_interface_mode_is_rgmii(priv_plat->phy_mode))) { > + switch (priv_plat->phy_mode) { > + case PHY_INTERFACE_MODE_RGMII: > + case PHY_INTERFACE_MODE_RGMII_RXID: > /* prefer 2ns fixed delay which is controlled by TXC_PHASE_CTRL, > * when link speed is 1Gbps with RGMII interface, > * Fall back to delay macro circuit for 10/100Mbps link speed. So this is wrong. PHY_INTERFACE_MODE_RGMII means the board is adding the delay via long lines. You should not be added any delay at all. For PHY_INTERFACE_MODE_RGMII_RXID, you need to mask the RXID bit from phy_mode when connecting the MAC to the PHY. Otherwise the PHY is going to add this delay as well. Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel