Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp2126579pxb; Sat, 14 Nov 2020 14:40:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJxmDKSo2MKZq3xO4AvdI1iUbwhlDed3iV8Jol2O0Sjr+MuLhhVCa24weDJd3wYIOH611lrO X-Received: by 2002:aa7:d4c9:: with SMTP id t9mr9509884edr.313.1605393642966; Sat, 14 Nov 2020 14:40:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605393642; cv=none; d=google.com; s=arc-20160816; b=vJqfoI9xaMI7i5kYJB56oh1LPKjASyaHzAG/2c5rn5O4z1/gfSvus75ztJjTxlWg0M SWyhqVZixxwAC36AqbY9I4ZYZdHup12RjW2FSE0kzIHpglNXdBSukacKnM7aGdQlXKdt xor1C+V25cwqfRf/pqcSmWXK/zh4/aJMAgCtwSYUMqEcHIkPOFap6xWy8luazvNv8u+L O29fPg5592idq3eu0RKrck0Gkv0q5oA3qTTD8UxLMECcdOry6D0ytKUcZrWJcsIdjWph ssvYqZDVDT/lGPkwyc+tnQ+B0TC3N67t3jmiI2dPKvaXg9MeNej9Iq46GY7B1Ejrdyqy fekg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=eIC1f+DKUDTaGWPbrFABpfcmjAcRZvqJsFJZY6Q3Ywk=; b=UeSAKhMtQy9pOcFP7X86OFkgo1ldTeFOLeqGw0AgLgx/6lARikHt6hdzLk61hkU7MC OJiY47/d64czqjJe2zjj7DAFVyhm5qGH6AVr1Qqq4NIJWqfXlw4P3GQU6nKOGRUqHpWb CvIEd5p7GeEKyHzGl91xCGiMzmgfRGLOKDegkeeuUG4vJG1I8Ltj3i3cMicmpqPWKsK1 0AUxWoGFp/UB/Jli0X/wDvYQz/Sd7UkTwe340+gXEQ+dQM9Q2DwGiasa3NU1TJeTmG3t HTH7RcudNfj2HLOaOabJpc0PEPA5xgqKvhTziBW8vgqx9jpKA2LDwog+hzM37tST2Hx8 Ycww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g2si8820831ejf.243.2020.11.14.14.40.20; Sat, 14 Nov 2020 14:40:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726291AbgKNWc6 (ORCPT + 99 others); Sat, 14 Nov 2020 17:32:58 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:55664 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726125AbgKNWc6 (ORCPT ); Sat, 14 Nov 2020 17:32:58 -0500 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1ke46E-0075um-ET; Sat, 14 Nov 2020 23:32:50 +0100 Date: Sat, 14 Nov 2020 23:32:50 +0100 From: Andrew Lunn To: Martin Blumenstingl Cc: davem@davemloft.net, kuba@kernel.org, linux-amlogic@lists.infradead.org, devicetree@vger.kernel.org, robh+dt@kernel.org, jianxin.pan@amlogic.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, khilman@baylibre.com, narmstrong@baylibre.com, jbrunet@baylibre.com Subject: Re: [PATCH RFC v1 1/4] dt-bindings: net: dwmac-meson: use picoseconds for the RGMII RX delay Message-ID: <20201114223250.GI1480543@lunn.ch> References: <20201114200104.4148283-1-martin.blumenstingl@googlemail.com> <20201114200104.4148283-2-martin.blumenstingl@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201114200104.4148283-2-martin.blumenstingl@googlemail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 14, 2020 at 09:01:01PM +0100, Martin Blumenstingl wrote: > Amlogic Meson G12A, G12B and SM1 SoCs have a more advanced RGMII RX > delay register which allows picoseconds precision. Deprecate the old > "amlogic,rx-delay-ns" in favour of a new "amlogic,rgmii-rx-delay-ps" > property. > > For older SoCs the only known supported values were 0ns and 2ns. The new > SoCs have 200ps precision and support RGMII RX delays between 0ps and > 3000ps. > > Signed-off-by: Martin Blumenstingl > --- > .../bindings/net/amlogic,meson-dwmac.yaml | 52 ++++++++++++++++++- > 1 file changed, 51 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml > index 6b057b117aa0..bafde1194193 100644 > --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml > +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml > @@ -74,18 +74,68 @@ allOf: > Any configuration is ignored when the phy-mode is set to "rmii". > > amlogic,rx-delay-ns: > + deprecated: true > enum: > - 0 > - 2 > default: 0 > + description: > + The internal RGMII RX clock delay in nanoseconds. Deprecated, use > + amlogic,rgmii-rx-delay-ps instead. > + > + amlogic,rgmii-rx-delay-ps: > + default: 0 > description: > The internal RGMII RX clock delay (provided by this IP block) in > - nanoseconds. When phy-mode is set to "rgmii" then the RX delay > + picoseconds. When phy-mode is set to "rgmii" then the RX delay > should be explicitly configured. When the phy-mode is set to > either "rgmii-id" or "rgmii-rxid" the RX clock delay is already > provided by the PHY. Any configuration is ignored when the > phy-mode is set to "rmii". Hi Martin I don't think the wording matches what the driver is actually doing: if (dwmac->rx_delay_ns == 2) rx_dly_config = PRG_ETH0_ADJ_ENABLE | PRG_ETH0_ADJ_SETUP; else rx_dly_config = 0; switch (dwmac->phy_mode) { case PHY_INTERFACE_MODE_RGMII: delay_config = tx_dly_config | rx_dly_config; break; case PHY_INTERFACE_MODE_RGMII_RXID: delay_config = tx_dly_config; break; case PHY_INTERFACE_MODE_RGMII_TXID: delay_config = rx_dly_config; break; case PHY_INTERFACE_MODE_RGMII_ID: case PHY_INTERFACE_MODE_RMII: delay_config = 0; break; So rx_delay is used for both rgmii and rgmii-txid. The binding says nothing about rgmii-txid. And while i'm looking at the code, i wonder about this: if (rx_dly_config & PRG_ETH0_ADJ_ENABLE) { if (!dwmac->timing_adj_clk) { dev_err(dwmac->dev, "The timing-adjustment clock is mandatory for the RX delay re-timing\n"); return -EINVAL; } /* The timing adjustment logic is driven by a separate clock */ ret = meson8b_devm_clk_prepare_enable(dwmac, dwmac->timing_adj_clk); if (ret) { dev_err(dwmac->dev, "Failed to enable the timing-adjustment clock\n"); return ret; } } It looks like it can be that rx_dly_config & PRG_ETH0_ADJ_ENABLE is true, so the clock is enabled, but delay_config does not contain rx_delay_config, so it is pointless turning it on. Andrew