Message ID | 20230426104313.28950-4-harini.katakam@amd.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp147067vqo; Wed, 26 Apr 2023 03:48:17 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5/drLzcHoO7vvkC1YreULFXe6Bz64lrKJHfIITUuCT91ZEqNwfkRedqSIXyFQs0fKxB9Q3 X-Received: by 2002:a05:6a21:339a:b0:f0:4a5e:b686 with SMTP id yy26-20020a056a21339a00b000f04a5eb686mr2163450pzb.29.1682506097037; Wed, 26 Apr 2023 03:48:17 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1682506097; cv=pass; d=google.com; s=arc-20160816; b=gLF6ts2dd321gqgAiPbo3CwJK7bUT/g7KTSuyBrU4y30LbJTxLdvdi/A/45Cu7yV6d bWeZA+nzeYutMNRifIZRGehte7HKKaEQvKyw7HgLqdlgLUQT5jGpj0xGV/OFWpOyudcX oA+lZMzmZoMqOVEZWttfOqx9Q6RIpbNukfQS1dw3/POPYu/3pGp6G3H0JlPjUs2hfdnV 7L8cQAvHbgkXVwWUm+Ub7rV6QZ0hqnvZZQXX8fIphwlyXmETMMhNnv9tjLSZ5Scw89W3 1ZzrcRzqUAWOXVAYXj2UZKEuU6NO3kYCrdlU+bYy7z2xNaqWh2LJ8MN7gkAs+dicoFdo YdvQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=QyuNeOLwppd5nT2AJUzdSQ3CApNXJ/zLRwIoTahw6eM=; b=mKHP9TlI9EFmjAfXmwvESYim4W+Ei0wx2o3Jd64N3oFMYZyFYYzOZmroPT/ZMKrHxn 6v/BIfdJdPczMKARJ2U8Vh1f2qJ7s6m7REFd8u2qSyscsVqo1Dl/tPxQgnh4BegTmxe6 puyB3Y/vrgORdfBGsqzevxp0O2oM0vS9QU78zWYVFl4suQVgJ/sfT6fMq1DRGVOQC5mV Wr4GlG70aH4byh0OklWQHQg2M747hmUwtcxqeM0sULEXrE/i/oCW2n22V3fpPrxJGT8L jVxBX6esbbw/fuHtsh/63aja8sbAdNpVco3ywwJwg27KxHIjRrCQJUDO0+0n11P0pF+w /ylw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=ljPmumTh; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b9-20020aa78ec9000000b0063d3387b4a3si15920052pfr.303.2023.04.26.03.48.04; Wed, 26 Apr 2023 03:48:17 -0700 (PDT) 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=@amd.com header.s=selector1 header.b=ljPmumTh; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240549AbjDZKoM (ORCPT <rfc822;zxc52fgh@gmail.com> + 99 others); Wed, 26 Apr 2023 06:44:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38938 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240545AbjDZKnk (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 26 Apr 2023 06:43:40 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2079.outbound.protection.outlook.com [40.107.244.79]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBEB54206; Wed, 26 Apr 2023 03:43:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PzikHipTjmcq98vngdbxrRIE09I10/WLCnJCyIq0WCEN0LdY1AbkMNqZdlyshpIAcbz+rnViinP/KtLMWhn7FQ6PfqCaV4HZYj2Pv8wl1INvt51ZhlDZ6spB9PAMfE/NRtOTvJNWkMK4NiLe+CB4RV2WoxlwIqIY3UfVNngyqo5vwq/5tm9eusdXvCm/MIKj8+FRgaTtK7ZPS9So88FTDiCagGe2g5NT6Ex4Lw5Rtawa3jdYHxm9g1MU7APKCMmH9lag+bO9MSFtL4X2FZyDHwk+70tBQ0u1TLrna5c4btuJjgkloseq4r+Ue2gDy7D7zTmHZthjxvSOlmY1AGcwww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QyuNeOLwppd5nT2AJUzdSQ3CApNXJ/zLRwIoTahw6eM=; b=lb8t6vp6D5NGisHilvgzvFaCUAcGuKhsPRmlId0fcoBZiRbt4ikWmVIsVAZt7svmwH6D8UygegiYPbh7OhNznJ3uXcj95pGiTKJQBkCgiM5mdBg7Zh4vGLxg3jrk49y4gsZ9lcEmM7RxYNldgipzCFE5XJ7IzuhVnzwO8HtU3VKndKVWQh3Sh7CRNhNaJJty982ZgkE7J/Gab/Z3RXh9YizeNX1zDDzEvSsB5z7wFLBE9VpdlkgRKy9xe1E7IM64sh2hxR6mFAJnkNPRyoyoxjkE4fOmFbRnrvUPzbEXCu1t2I+3KJ/sk9Rc/vlJVw72/+j6XE2RiONebUHAl3V77Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QyuNeOLwppd5nT2AJUzdSQ3CApNXJ/zLRwIoTahw6eM=; b=ljPmumThE9guTo59oBbDk/4cmUev7aY2iZB1qEAumct/ytpiaQsY9NaBsAM/n9tL3xfYRSK5JoYzQj43UStThk1Vt7QgLse/UiSlQDwFQFQReaU7RnRKRubL435Jx619qg+YWE1ipLe1zbXT2Y+fGuiDI0Nz+UtzGpZbuV7TZb8= Received: from MW3PR05CA0007.namprd05.prod.outlook.com (2603:10b6:303:2b::12) by MN2PR12MB4207.namprd12.prod.outlook.com (2603:10b6:208:1d9::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6340.21; Wed, 26 Apr 2023 10:43:35 +0000 Received: from CO1NAM11FT077.eop-nam11.prod.protection.outlook.com (2603:10b6:303:2b:cafe::69) by MW3PR05CA0007.outlook.office365.com (2603:10b6:303:2b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6363.5 via Frontend Transport; Wed, 26 Apr 2023 10:43:35 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Received: from SATLEXMB03.amd.com (165.204.84.17) by CO1NAM11FT077.mail.protection.outlook.com (10.13.175.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6340.22 via Frontend Transport; Wed, 26 Apr 2023 10:43:35 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Wed, 26 Apr 2023 05:43:34 -0500 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Wed, 26 Apr 2023 05:43:34 -0500 Received: from xhdharinik40.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2375.34 via Frontend Transport; Wed, 26 Apr 2023 05:43:29 -0500 From: Harini Katakam <harini.katakam@amd.com> To: <robh+dt@kernel.org>, <andrew@lunn.ch>, <hkallweit1@gmail.com>, <linux@armlinux.org.uk>, <davem@davemloft.net>, <kuba@kernel.org>, <edumazet@google.com>, <pabeni@redhat.com>, <vladimir.oltean@nxp.com>, <wsa+renesas@sang-engineering.com>, <krzysztof.kozlowski+dt@linaro.org>, <simon.horman@corigine.com> CC: <netdev@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <harinikatakamlinux@gmail.com>, <michal.simek@amd.com>, <harini.katakam@amd.com>, <radhey.shyam.pandey@amd.com> Subject: [PATCH net-next v2 3/3] phy: mscc: Add support for VSC8531_02 with RGMII tuning Date: Wed, 26 Apr 2023 16:13:13 +0530 Message-ID: <20230426104313.28950-4-harini.katakam@amd.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20230426104313.28950-1-harini.katakam@amd.com> References: <20230426104313.28950-1-harini.katakam@amd.com> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1NAM11FT077:EE_|MN2PR12MB4207:EE_ X-MS-Office365-Filtering-Correlation-Id: 392f4ec5-f7c0-4799-dc3e-08db46431630 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZGRPs2GhVZmY3XbY+1QYoO7xusvkkp3I9nXWXt96gtcJCyOExcMSm1LBMnAjXvMm0RU2K4pxukDrIE6vm7MRk7eIHrWlkaNGKhXz3WbBImju/+kC1NteF8jHcu8goinyvDnpN8+8E9HFVrs6BT1q2bUQPn2OnBOmjHMvmb1YSaVLgjpksGc+IyMm0SiCKyojsKyKDBFCnluhaoj6nQJkPS/LHLpR4vdk/pKLUmCspitJGBorQxc4h0VZl4CiDRBkrhdcdOqAITWa/XPPmNhZCfluBIZ2Cn5LEONC1upWtcHIKu0JdHQG3PONIlO5gZpZ3miDS7fBeIWxDIHJDqMXhJrh5kWw6h67b39QRF0qukq9pzX+8bg/wBxlw9pt0eEJzVObH4LYaqQqvIeXEdgBlmFjTmemgCXCKuTYBDBffT7SQISLo/3rxTnF4k3f31JkWRFGLmhle9yhUYplPzS1wrD0GoF/Uo0Zy2pg3Bg6H0DBBOshnDyOWoaDfzG8sxQWN14b38ot2lNPuDPT3uXe6t0ReX2hhbgB2NcLa+BNjKQNkHUWhFkdq13J1v7sotVyXk+mgIdsbSacMQZJAX3x4zzkt8NOr1QNJqbcGJMuTp6pa7iFMMIpWmkUaZZXxt1U0K7kGBzdLjshpG+io7n1W1FN5KxLBHchSD/lfCDNDugoKIHAzuL30kkqAsFDyuEIdrZhs1B2Vrac68YKnFjFy+EGtmXGE3AvXXR4TXblqkuyQocUJ+L25LGLtOICxv1y X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230028)(4636009)(39860400002)(136003)(346002)(396003)(376002)(451199021)(40470700004)(46966006)(36840700001)(82310400005)(36756003)(86362001)(40480700001)(40460700003)(54906003)(478600001)(6666004)(110136005)(8936002)(356005)(8676002)(81166007)(921005)(41300700001)(70586007)(70206006)(316002)(82740400003)(2616005)(4326008)(36860700001)(83380400001)(47076005)(186003)(336012)(426003)(26005)(1076003)(2906002)(7416002)(44832011)(5660300002)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2023 10:43:35.0548 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 392f4ec5-f7c0-4799-dc3e-08db46431630 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT077.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4207 X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764235512987797992?= X-GMAIL-MSGID: =?utf-8?q?1764235512987797992?= |
Series |
Add support for VSC8531_02 PHY and DT RGMII tuning
|
|
Commit Message
Harini Katakam
April 26, 2023, 10:43 a.m. UTC
From: Harini Katakam <harini.katakam@xilinx.com> Add support for VSC8531_02 (Rev 2) device. Add support for optional RGMII RX and TX delay tuning via devicetree. The hierarchy is: - Retain the defaul 0.2ns delay when RGMII tuning is not set. - Retain the default 2ns delay when RGMII tuning is set and DT delay property is NOT specified. - Use the DT delay value when RGMII tuning is set and a DT delay property is specified. Signed-off-by: Harini Katakam <harini.katakam@amd.com> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> --- v2: - Switch both VSC8531 and VSC8531-02 to use exact phy id match as they share the same model number - Ensure RCT - Improve optional property read drivers/net/phy/mscc/mscc.h | 3 +++ drivers/net/phy/mscc/mscc_main.c | 40 ++++++++++++++++++++++++++++---- 2 files changed, 39 insertions(+), 4 deletions(-)
Comments
On Wed, Apr 26, 2023 at 04:13:13PM +0530, Harini Katakam wrote: > From: Harini Katakam <harini.katakam@xilinx.com> > > Add support for VSC8531_02 (Rev 2) device. > Add support for optional RGMII RX and TX delay tuning via devicetree. > The hierarchy is: > - Retain the defaul 0.2ns delay when RGMII tuning is not set. > - Retain the default 2ns delay when RGMII tuning is set and DT delay > property is NOT specified. > - Use the DT delay value when RGMII tuning is set and a DT delay > property is specified. > > Signed-off-by: Harini Katakam <harini.katakam@amd.com> > Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> > Signed-off-by: Michal Simek <michal.simek@xilinx.com> > --- > v2: > - Switch both VSC8531 and VSC8531-02 to use exact phy id match as they > share the same model number > - Ensure RCT > - Improve optional property read > > drivers/net/phy/mscc/mscc.h | 3 +++ > drivers/net/phy/mscc/mscc_main.c | 40 ++++++++++++++++++++++++++++---- > 2 files changed, 39 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/phy/mscc/mscc.h b/drivers/net/phy/mscc/mscc.h > index a50235fdf7d9..5a26eba0ace0 100644 > --- a/drivers/net/phy/mscc/mscc.h > +++ b/drivers/net/phy/mscc/mscc.h > @@ -281,6 +281,7 @@ enum rgmii_clock_delay { > #define PHY_ID_VSC8514 0x00070670 > #define PHY_ID_VSC8530 0x00070560 > #define PHY_ID_VSC8531 0x00070570 > +#define PHY_ID_VSC8531_02 0x00070572 > #define PHY_ID_VSC8540 0x00070760 > #define PHY_ID_VSC8541 0x00070770 > #define PHY_ID_VSC8552 0x000704e0 > @@ -373,6 +374,8 @@ struct vsc8531_private { > * package. > */ > unsigned int base_addr; > + u32 rx_delay; > + u32 tx_delay; > > #if IS_ENABLED(CONFIG_MACSEC) > /* MACsec fields: > diff --git a/drivers/net/phy/mscc/mscc_main.c b/drivers/net/phy/mscc/mscc_main.c > index 75d9582e5784..80cc90a23d57 100644 > --- a/drivers/net/phy/mscc/mscc_main.c > +++ b/drivers/net/phy/mscc/mscc_main.c > @@ -525,6 +525,7 @@ static int vsc85xx_rgmii_set_skews(struct phy_device *phydev, u32 rgmii_cntl, > { > u16 rgmii_rx_delay_pos = ffs(rgmii_rx_delay_mask) - 1; > u16 rgmii_tx_delay_pos = ffs(rgmii_tx_delay_mask) - 1; > + struct vsc8531_private *vsc8531 = phydev->priv; > u16 reg_val = 0; > int rc; > > @@ -532,10 +533,10 @@ static int vsc85xx_rgmii_set_skews(struct phy_device *phydev, u32 rgmii_cntl, > > if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID || > phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) > - reg_val |= RGMII_CLK_DELAY_2_0_NS << rgmii_rx_delay_pos; > + reg_val |= vsc8531->rx_delay << rgmii_rx_delay_pos; > if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID || > phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) > - reg_val |= RGMII_CLK_DELAY_2_0_NS << rgmii_tx_delay_pos; > + reg_val |= vsc8531->tx_delay << rgmii_tx_delay_pos; > > rc = phy_modify_paged(phydev, MSCC_PHY_PAGE_EXTENDED_2, > rgmii_cntl, > @@ -1812,6 +1813,15 @@ static int vsc85xx_config_init(struct phy_device *phydev) > { > int rc, i, phy_id; > struct vsc8531_private *vsc8531 = phydev->priv; > + struct device_node *of_node = phydev->mdio.dev.of_node; > + > + vsc8531->rx_delay = RGMII_CLK_DELAY_2_0_NS; > + rc = of_property_read_u32(of_node, "mscc,rx-delay", > + &vsc8531->rx_delay); > + > + vsc8531->tx_delay = RGMII_CLK_DELAY_2_0_NS; > + rc = of_property_read_u32(of_node, "mscc,tx-delay", > + &vsc8531->tx_delay); Since the dt-bindings document says "If this property is present then the PHY applies the RX|TX delay", then I guess the precedence as applied by vsc85xx_rgmii_set_skews() should be different. The RX delays should be applied based on rx-internal-delay-ps (if present) regardless of phy-mode, or set to RGMII_CLK_DELAY_2_0_NS if we are in the rgmii-rxid or rgmii-id modes. Similar for tx. Also, please split the VSC8531-02 addition into a separate patch, since the configurable RGMII delays also affect existing PHYs (like VSC8502).
Hi Vladimir, > -----Original Message----- > From: Vladimir Oltean <vladimir.oltean@nxp.com> > Sent: Wednesday, April 26, 2023 4:48 PM > To: Katakam, Harini <harini.katakam@amd.com> > Cc: robh+dt@kernel.org; andrew@lunn.ch; hkallweit1@gmail.com; > linux@armlinux.org.uk; davem@davemloft.net; kuba@kernel.org; > edumazet@google.com; pabeni@redhat.com; wsa+renesas@sang- > engineering.com; krzysztof.kozlowski+dt@linaro.org; > simon.horman@corigine.com; netdev@vger.kernel.org; > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; > harinikatakamlinux@gmail.com; Simek, Michal <michal.simek@amd.com>; > Pandey, Radhey Shyam <radhey.shyam.pandey@amd.com> > Subject: Re: [PATCH net-next v2 3/3] phy: mscc: Add support for VSC8531_02 > with RGMII tuning > > On Wed, Apr 26, 2023 at 04:13:13PM +0530, Harini Katakam wrote: > > From: Harini Katakam <harini.katakam@xilinx.com> > > > > Add support for VSC8531_02 (Rev 2) device. > > Add support for optional RGMII RX and TX delay tuning via devicetree. > > The hierarchy is: > > - Retain the defaul 0.2ns delay when RGMII tuning is not set. > > - Retain the default 2ns delay when RGMII tuning is set and DT delay > > property is NOT specified. > > - Use the DT delay value when RGMII tuning is set and a DT delay > > property is specified. > > > > Signed-off-by: Harini Katakam <harini.katakam@amd.com> > > Signed-off-by: Radhey Shyam Pandey > <radhey.shyam.pandey@xilinx.com> > > Signed-off-by: Michal Simek <michal.simek@xilinx.com> > > --- <snip> > > @@ -532,10 +533,10 @@ static int vsc85xx_rgmii_set_skews(struct > phy_device *phydev, u32 rgmii_cntl, > > > > if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID || > > phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) > > - reg_val |= RGMII_CLK_DELAY_2_0_NS << > rgmii_rx_delay_pos; > > + reg_val |= vsc8531->rx_delay << rgmii_rx_delay_pos; > > if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID || > > phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) > > - reg_val |= RGMII_CLK_DELAY_2_0_NS << > rgmii_tx_delay_pos; > > + reg_val |= vsc8531->tx_delay << rgmii_tx_delay_pos; > > > > rc = phy_modify_paged(phydev, MSCC_PHY_PAGE_EXTENDED_2, > > rgmii_cntl, > > @@ -1812,6 +1813,15 @@ static int vsc85xx_config_init(struct phy_device > *phydev) > > { > > int rc, i, phy_id; > > struct vsc8531_private *vsc8531 = phydev->priv; > > + struct device_node *of_node = phydev->mdio.dev.of_node; > > + > > + vsc8531->rx_delay = RGMII_CLK_DELAY_2_0_NS; > > + rc = of_property_read_u32(of_node, "mscc,rx-delay", > > + &vsc8531->rx_delay); > > + > > + vsc8531->tx_delay = RGMII_CLK_DELAY_2_0_NS; > > + rc = of_property_read_u32(of_node, "mscc,tx-delay", > > + &vsc8531->tx_delay); > > Since the dt-bindings document says "If this property is present then > the PHY applies the RX|TX delay", then I guess the precedence as applied > by vsc85xx_rgmii_set_skews() should be different. The RX delays should > be applied based on rx-internal-delay-ps (if present) regardless of > phy-mode, or set to RGMII_CLK_DELAY_2_0_NS if we are in the rgmii-rxid phy_get_internal_delay > or rgmii-id modes. Similar for tx. Thanks for the review. The intention is to have the following precedence (I'll rephrase the commit if required) -> If phy-mode is rgmii, current behavior persists for all devices -> If phy-mode is rgmii-id/rgmii-rxid/rgmii-txid, current behavior persists for all devices (i.e. delay of RGMII_CLK_DELAY_2_0_NS) -> If phy-mode is rgmii-id/rgmii-rxid/rgmii-txid AND rx-internal-delay-ps/tx-internal-delay-ps is defined, then the value from DT is considered instead of 2ns. (NOT irrespective of phy-mode) I'm checking the phy drivers that use phy_get_internal_delay and the description phy-mode in ethernet-controller.yaml and rx/tx-internal-delay-ps in ethernet-phy.yaml. It does look like the above is allowed. Please do let me know otherwise. I will re-spin the series using phy_get_internal_delay. Regards, Harini
On Wed, Apr 26, 2023 at 04:13:13PM +0530, Harini Katakam wrote: > From: Harini Katakam <harini.katakam@xilinx.com> > > Add support for VSC8531_02 (Rev 2) device. > Add support for optional RGMII RX and TX delay tuning via devicetree. > The hierarchy is: > - Retain the defaul 0.2ns delay when RGMII tuning is not set. > - Retain the default 2ns delay when RGMII tuning is set and DT delay > property is NOT specified. tuning is probably the wrong word here. I normally consider tuning as small changes from 0ns/2ns. The course setting of 0ns or 2ns is not tuning. I normally use RGMII internal delays to refer to that. However, i'm not sure there is consistency among drivers. Andrew
On Wed, Apr 26, 2023 at 12:21:47PM +0000, Katakam, Harini wrote: > Thanks for the review. > The intention is to have the following precedence (I'll rephrase the commit if required) > -> If phy-mode is rgmii, current behavior persists for all devices > -> If phy-mode is rgmii-id/rgmii-rxid/rgmii-txid, current behavior persists for all devices > (i.e. delay of RGMII_CLK_DELAY_2_0_NS) > -> If phy-mode is rgmii-id/rgmii-rxid/rgmii-txid AND rx-internal-delay-ps/tx-internal-delay-ps > is defined, then the value from DT is considered instead of 2ns. (NOT irrespective of phy-mode) > > I'm checking the phy drivers that use phy_get_internal_delay and the description phy-mode > in ethernet-controller.yaml and rx/tx-internal-delay-ps in ethernet-phy.yaml. It does look like > the above is allowed. Please do let me know otherwise. I understood what your intention was. What I meant was: phy-mode rgmii rgmii-rxid/rgmii-id -------------------------------------------------------------------------------------------- rx-internal-delay-ps absent 0.2 ns 2 ns rx-internal-delay-ps present follow rx-internal-delay-ps follow rx-internal-delay-ps I agree with Andrew that probably there isn't consistency among PHY drivers for this interpretation - see dp83822 vs intel-xway for example. My interpretation was based on the wording from the dt-bindings document, which seems to suggest that rx-internal-delay-ps takes precedence.
On Wed, Apr 26, 2023 at 04:13:13PM +0530, Harini Katakam wrote: > From: Harini Katakam <harini.katakam@xilinx.com> > > Add support for VSC8531_02 (Rev 2) device. > Add support for optional RGMII RX and TX delay tuning via devicetree. > The hierarchy is: > - Retain the defaul 0.2ns delay when RGMII tuning is not set. nit: s/defaul/default/ ...
Hi Andrew, > -----Original Message----- > From: Andrew Lunn <andrew@lunn.ch> > Sent: Wednesday, April 26, 2023 7:18 PM > To: Katakam, Harini <harini.katakam@amd.com> > Cc: robh+dt@kernel.org; hkallweit1@gmail.com; linux@armlinux.org.uk; > davem@davemloft.net; kuba@kernel.org; edumazet@google.com; > pabeni@redhat.com; vladimir.oltean@nxp.com; wsa+renesas@sang- > engineering.com; krzysztof.kozlowski+dt@linaro.org; > simon.horman@corigine.com; netdev@vger.kernel.org; > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; > harinikatakamlinux@gmail.com; Simek, Michal <michal.simek@amd.com>; > Pandey, Radhey Shyam <radhey.shyam.pandey@amd.com> > Subject: Re: [PATCH net-next v2 3/3] phy: mscc: Add support for VSC8531_02 > with RGMII tuning > > On Wed, Apr 26, 2023 at 04:13:13PM +0530, Harini Katakam wrote: > > From: Harini Katakam <harini.katakam@xilinx.com> > > > > Add support for VSC8531_02 (Rev 2) device. > > Add support for optional RGMII RX and TX delay tuning via devicetree. > > The hierarchy is: > > - Retain the defaul 0.2ns delay when RGMII tuning is not set. > > - Retain the default 2ns delay when RGMII tuning is set and DT delay > > property is NOT specified. > > tuning is probably the wrong word here. I normally consider tuning as small > changes from 0ns/2ns. The course setting of 0ns or 2ns is not tuning. I > normally use RGMII internal delays to refer to that. > > However, i'm not sure there is consistency among drivers. Thanks for the input, I understand. I'm planning on re-phrasing this with phy-mode and property values to describe rather than say tuning. Regards, Harini
Hi Vladimir, > -----Original Message----- > From: Vladimir Oltean <vladimir.oltean@nxp.com> > Sent: Wednesday, April 26, 2023 7:49 PM > To: Katakam, Harini <harini.katakam@amd.com> > Cc: robh+dt@kernel.org; andrew@lunn.ch; hkallweit1@gmail.com; > linux@armlinux.org.uk; davem@davemloft.net; kuba@kernel.org; > edumazet@google.com; pabeni@redhat.com; wsa+renesas@sang- > engineering.com; krzysztof.kozlowski+dt@linaro.org; > simon.horman@corigine.com; netdev@vger.kernel.org; > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; > harinikatakamlinux@gmail.com; Simek, Michal <michal.simek@amd.com>; > Pandey, Radhey Shyam <radhey.shyam.pandey@amd.com> > Subject: Re: [PATCH net-next v2 3/3] phy: mscc: Add support for VSC8531_02 > with RGMII tuning > > On Wed, Apr 26, 2023 at 12:21:47PM +0000, Katakam, Harini wrote: > > Thanks for the review. > > The intention is to have the following precedence (I'll rephrase the > > commit if required) > > -> If phy-mode is rgmii, current behavior persists for all devices If > > -> phy-mode is rgmii-id/rgmii-rxid/rgmii-txid, current behavior > > -> persists for all devices > > (i.e. delay of RGMII_CLK_DELAY_2_0_NS) > > -> If phy-mode is rgmii-id/rgmii-rxid/rgmii-txid AND > > -> rx-internal-delay-ps/tx-internal-delay-ps > > is defined, then the value from DT is considered instead of 2ns. (NOT > > irrespective of phy-mode) > > > > I'm checking the phy drivers that use phy_get_internal_delay and the > > description phy-mode in ethernet-controller.yaml and > > rx/tx-internal-delay-ps in ethernet-phy.yaml. It does look like the above is > allowed. Please do let me know otherwise. > > I understood what your intention was. What I meant was: > > phy-mode rgmii rgmii-rxid/rgmii-id > -------------------------------------------------------------------------------------------- > rx-internal-delay-ps absent 0.2 ns 2 ns > rx-internal-delay-ps present follow rx-internal-delay-ps follow rx-internal- > delay-ps > > I agree with Andrew that probably there isn't consistency among PHY drivers > for this interpretation - see dp83822 vs intel-xway for example. Thanks, yes I noticed the difference here and also in older PHY drivers that used custom properties (see dp83867 which is what I originally aligned it to). But the table you mentioned above makes sense; I'll re-spin accordingly. > My interpretation was based on the wording from the dt-bindings document, > which seems to suggest that rx-internal-delay-ps takes precedence. OK I understand. Regards, Harini
diff --git a/drivers/net/phy/mscc/mscc.h b/drivers/net/phy/mscc/mscc.h index a50235fdf7d9..5a26eba0ace0 100644 --- a/drivers/net/phy/mscc/mscc.h +++ b/drivers/net/phy/mscc/mscc.h @@ -281,6 +281,7 @@ enum rgmii_clock_delay { #define PHY_ID_VSC8514 0x00070670 #define PHY_ID_VSC8530 0x00070560 #define PHY_ID_VSC8531 0x00070570 +#define PHY_ID_VSC8531_02 0x00070572 #define PHY_ID_VSC8540 0x00070760 #define PHY_ID_VSC8541 0x00070770 #define PHY_ID_VSC8552 0x000704e0 @@ -373,6 +374,8 @@ struct vsc8531_private { * package. */ unsigned int base_addr; + u32 rx_delay; + u32 tx_delay; #if IS_ENABLED(CONFIG_MACSEC) /* MACsec fields: diff --git a/drivers/net/phy/mscc/mscc_main.c b/drivers/net/phy/mscc/mscc_main.c index 75d9582e5784..80cc90a23d57 100644 --- a/drivers/net/phy/mscc/mscc_main.c +++ b/drivers/net/phy/mscc/mscc_main.c @@ -525,6 +525,7 @@ static int vsc85xx_rgmii_set_skews(struct phy_device *phydev, u32 rgmii_cntl, { u16 rgmii_rx_delay_pos = ffs(rgmii_rx_delay_mask) - 1; u16 rgmii_tx_delay_pos = ffs(rgmii_tx_delay_mask) - 1; + struct vsc8531_private *vsc8531 = phydev->priv; u16 reg_val = 0; int rc; @@ -532,10 +533,10 @@ static int vsc85xx_rgmii_set_skews(struct phy_device *phydev, u32 rgmii_cntl, if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID || phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) - reg_val |= RGMII_CLK_DELAY_2_0_NS << rgmii_rx_delay_pos; + reg_val |= vsc8531->rx_delay << rgmii_rx_delay_pos; if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID || phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) - reg_val |= RGMII_CLK_DELAY_2_0_NS << rgmii_tx_delay_pos; + reg_val |= vsc8531->tx_delay << rgmii_tx_delay_pos; rc = phy_modify_paged(phydev, MSCC_PHY_PAGE_EXTENDED_2, rgmii_cntl, @@ -1812,6 +1813,15 @@ static int vsc85xx_config_init(struct phy_device *phydev) { int rc, i, phy_id; struct vsc8531_private *vsc8531 = phydev->priv; + struct device_node *of_node = phydev->mdio.dev.of_node; + + vsc8531->rx_delay = RGMII_CLK_DELAY_2_0_NS; + rc = of_property_read_u32(of_node, "mscc,rx-delay", + &vsc8531->rx_delay); + + vsc8531->tx_delay = RGMII_CLK_DELAY_2_0_NS; + rc = of_property_read_u32(of_node, "mscc,tx-delay", + &vsc8531->tx_delay); rc = vsc85xx_default_config(phydev); if (rc) @@ -2413,9 +2423,8 @@ static struct phy_driver vsc85xx_driver[] = { .get_stats = &vsc85xx_get_stats, }, { - .phy_id = PHY_ID_VSC8531, + PHY_ID_MATCH_EXACT(PHY_ID_VSC8531), .name = "Microsemi VSC8531", - .phy_id_mask = 0xfffffff0, /* PHY_GBIT_FEATURES */ .soft_reset = &genphy_soft_reset, .config_init = &vsc85xx_config_init, @@ -2436,6 +2445,29 @@ static struct phy_driver vsc85xx_driver[] = { .get_strings = &vsc85xx_get_strings, .get_stats = &vsc85xx_get_stats, }, +{ + PHY_ID_MATCH_EXACT(PHY_ID_VSC8531_02), + .name = "Microsemi VSC8531-02", + /* PHY_GBIT_FEATURES */ + .soft_reset = &genphy_soft_reset, + .config_init = &vsc85xx_config_init, + .config_aneg = &vsc85xx_config_aneg, + .read_status = &vsc85xx_read_status, + .handle_interrupt = vsc85xx_handle_interrupt, + .config_intr = &vsc85xx_config_intr, + .suspend = &genphy_suspend, + .resume = &genphy_resume, + .probe = &vsc85xx_probe, + .set_wol = &vsc85xx_wol_set, + .get_wol = &vsc85xx_wol_get, + .get_tunable = &vsc85xx_get_tunable, + .set_tunable = &vsc85xx_set_tunable, + .read_page = &vsc85xx_phy_read_page, + .write_page = &vsc85xx_phy_write_page, + .get_sset_count = &vsc85xx_get_sset_count, + .get_strings = &vsc85xx_get_strings, + .get_stats = &vsc85xx_get_stats, +}, { .phy_id = PHY_ID_VSC8540, .name = "Microsemi FE VSC8540 SyncE",