Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp167256pxu; Thu, 7 Jan 2021 01:22:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJy4q7pB5dVSAzU2NnGJpbaZY0XsW/DSgBudrY0M2M/CcITgKZEF5iE3Jn5HYCAxOy47Y7CH X-Received: by 2002:a05:6402:270d:: with SMTP id y13mr993479edd.149.1610011333106; Thu, 07 Jan 2021 01:22:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610011333; cv=none; d=google.com; s=arc-20160816; b=yxIe06hdHQUSluLCfjalbAbSoqHfYYdcdEO2+oin+heO/kjo0wywc89Te3V7L9x8Iz GgwFAsovOHjpmLurGzrQZZD56Yjp+DQqOuEzHKZtV+P7OGKBCid/CCxTJB3P4e6Nop87 cvUHIRz6Fnu9SMat7beuLzfgm1bTWR3dp80PIlqB7oS/VOmgyiD7pyh53ymmbHPfonqC 8UXXK3W1enSE5CfEfPK6p8iPExOPbr/USf4rhCw7edfaixlbLvfOgIppZIQC5oorsEnS G9g2tN1PSuLzxi/6Kviib2mj4ySH9OSdP0lorIJ9MupGMlNoVPsPeh3gorXd84EpnW+U JizQ== 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 :message-id:date:subject:cc:to:from:ironport-sdr:dkim-signature; bh=CpSP2kvcn5KfoA3XmpMD2PBzAGXaedscVAZOcSy0Z3I=; b=vuFfMpl/JubPPlolGbm2h8GbSgux6lVJ7TLjhlQ5GjiFuiDncaz8zkQn9IsqEldJgq vITr4jXO0n7tinAWe9Q/TrifywOn9+l1TLWO/AzskIm5IksDTmqI2O3ASm8XodDGoEQk 98lLq2E6DDKrgvH5/UjFHBGjmjB0PZyGHxFALKM5UtE1esd3Yuuc/hCwLoFqajkFHEsX 96MqvLPz+Yf0KHvRN88HHd4w2EVf/IXZmDqCLfbKOH14HvGAv6huuGoTw6Uy9o7wEJpZ /+DmMF+eFYLTwLBsfax93WI+aaD/srznwZq66qn4k3ZoyBOpYkgqloiqH5SH0vujh9iQ OGPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@microchip.com header.s=mchp header.b=rvCPLEDa; 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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t21si2454937edi.2.2021.01.07.01.21.49; Thu, 07 Jan 2021 01:22:13 -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; dkim=fail header.i=@microchip.com header.s=mchp header.b=rvCPLEDa; 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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727403AbhAGJUs (ORCPT + 99 others); Thu, 7 Jan 2021 04:20:48 -0500 Received: from esa.microchip.iphmx.com ([68.232.154.123]:14064 "EHLO esa.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726326AbhAGJUr (ORCPT ); Thu, 7 Jan 2021 04:20:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1610011247; x=1641547247; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=lFNSOkzFxSV4qsofifMWXrJPD0AxAvZ+dw/AdAqzT/Q=; b=rvCPLEDa0hIEjZ2fXm8Uj7StLxASLrjgtQ7IQb86g1jZ+MLNh99SIFyY Y4vFImcrjCIvHYauu5AisXrKnxtwXKfiTQPQHJgfrKMB+CJAwHyxglUZg zO8+yA8oApLUaGvpEbT9tTeX6wxXPLWibcV/whjmue8DLAfwUGzbc6eXt SwFAsjMGM4L6YGNwN0roYNFmxcXenBPuWl2JO7pOTfNb+6GGOCW/3pkls 6h0PE+D3uztDNM7dXg2q1nemmaThjwHL0dioKluPSyC5ej7bV05JkHbHB jVtVfqg53nBDzmYFPVxq06dEKWJuJRWYQF/bPN0SQaZ+XnpfLd5PnF0kf g==; IronPort-SDR: ZmupYcUueJgYgTAyPbWQZPsN3P5MmgiT85SBOBnZdKS4J+Umxr3mT2HA8rD0ZSmJ2D4eywPkQ4 h3tK0CXMNlxpus0otENH8LNnd9x7PPunh0m12AQuSOFm78sQYgoAv0YP5awTWcE16YpjJ8u0w1 NDq6VC61Ry6+xEO9ELH6e6CeNow4yEj/WnmJXZxGHos+CZly4qGoSwx8F0jpc/RklA0Dle1qh3 kAKlkTA9eqPEKuAQs5SdApyfWs14qNOqilXrrLsj0mwnFsIIThK9DR78UyRZPZ7L53Fs4KkSQx oJ4= X-IronPort-AV: E=Sophos;i="5.79,329,1602572400"; d="scan'208";a="102067774" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa2.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 07 Jan 2021 02:19:31 -0700 Received: from chn-vm-ex01.mchp-main.com (10.10.85.143) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 7 Jan 2021 02:19:30 -0700 Received: from mchp-dev-shegelun.microchip.com (10.10.115.15) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server id 15.1.1979.3 via Frontend Transport; Thu, 7 Jan 2021 02:19:28 -0700 From: Steen Hegelund To: Kishon Vijay Abraham I , Vinod Koul CC: Steen Hegelund , Alexandre Belloni , Lars Povlsen , Bjarni Jonasson , Microchip UNG Driver List , , Subject: [PATCH v12 0/4] Adding the Sparx5 Serdes driver Date: Thu, 7 Jan 2021 10:19:20 +0100 Message-ID: <20210107091924.1569575-1-steen.hegelund@microchip.com> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Adding the Sparx5 Serdes driver This series of patches provides the serdes driver for the Microchip Sparx5 ethernet switch. The serdes driver supports the 10G and 25G serdes instances available in the Sparx5. The Sparx5 serdes support several interface modes with several speeds and also allows the client to change the mode and the speed according to changing in the environment such as changing cables from DAC to fiber. The serdes driver is to be used by the Sparx5 switchdev driver that will follow in subsequent series. Sparx5 Arhitecture: =================== Below is a diagram of the Ethernet transport part of the Sparx5 chip. The diagram shows the switch core that sends/receives traffic via the Frame Bus and passes to the Port Modules. The Port Modules are able to talk to a SerDes via a Port Muxing configuration. The SerDes instances (33 in all) then passes the traffic on its lanes to the attached cuPHY or SFP module. +---------------------------------------------------------+ | | | Switch Core | | | +----------------------------+----------------------------+ | -------+--------------+------+-------+--------------+-----+ Frame Bus | | | | +------+-----+ +------+-----+ +------+-----+ +------+-----+ |1G/2.G Port | |5G Port | |10G Port | |25GG Port | |Modules | |Modules | |Modules | |Modules | |MAC, PCS | |MAC, PCS | |MAC, PCS | |MAC, PCS | +------+-----+ +------+-----+ +------+-----+ +------+-----+ | | | | -------+-+------------+-------+------+----------+---+-----+ Port Muxing | | | +-----+----+ +-----+----+ +--+-------+ |SerDes 5G | |SerDes 10G| |SerDes 25G| SerDes Driver |Lane (13) | |Lane (12) | |Lane (8) | Controls these +-----+----+ +-----+----+ +-----+----+ | | | to cuPHY to cuPHY to cuPHY or SFP or SFP or SFP The 33 SerDes instances are handled internally by 2 SerDes macros types: - A 10G SerDes macro that supports the following rates and modes: - 100 Mbps: - 100BASE-FX - 1.25 Gbps: - SGMII - 1000BASE-X - 1000BASE-KX - 3.125 Gbps: - 2.5GBASE-X - 2.5GBASE-KX - 5 Gbps: - QSGMII - USGMII - 5.15625 Gbps: - 5GBASE-KR - 5G-USXGMII - 10 Gbps: - 10G-USGMII - 10.3125 Gbps: - 10GBASE-R - 10GBASE-KR - USXGMII - A 25G SerDes macro that supports the following rates and modes: - 1.25 Gbps: - SGMII - 1000BASE-X - 1000BASE-KX - 3.125 Gbps: - 2.5GBASE-X - 2.5GBASE-KX - 5 Gbps: - QSGMII - USGMII - 5.15625 Gbps: - 5GBASE-KR - 5G-USXGMII - 10 Gbps: - 10G-USGMII - 10.3125 Gbps: - 10GBASE-R - 10GBASE-KR - USXGMII - 10.3125 Gbps: - 10GBASE-R - 10GBASE-KR - USXGMII - 25.78125 Gbps: - 25GBASE-KR - 25GBASE-CR - 25GBASE-SR - 25GBASE-LR - 25GBASE-ER The SerDes driver handles these SerDes instances and configures them based on the selected mode, speed and media type. In the current version of the SerDes driver only a subset of the above modes are supported: the modes that can be tested on our current evaluation boards (PCB134 and PCB35). The first 13 10G SerDes macros are limited to 6G, and this gives the SerDes instance architecture shown on the diagram above. The Port Muxing allows a Port Module to use a specific SerDes instance, but not all combinations are allowed. This is functionality as well as the configuration of the Port Modules is handled by the SwitchDev Driver. History: -------- v11 -> v12: Used bitfields for bools in configuration structures. Removed vertical alignment in structures. Removed CONFIG_DEBUG_KERNEL guard around warning checks v10 -> v11: Rebased on v5.11-rc1 v9 -> v10: Only add the new folder to the phy Kconfig (no sort fix) Corrected the serdes mode conversion for 2.5G mode. Clarified the SGMII and 1000BASEX conversion. Improved some of the more cryptic error messages. Expanded the validate function a bit, and removed the link status from the return value. v8 -> v9: Replace pr_err with dev_err Expanded the description here in the cover letter (should probably og into the driver, at least part of it). v7 -> v8: Provide the IO targets as offsets from the start of the IO range Initialise resource index v6 -> v7: This series changes the way the IO targets are provided to the driver. Now only one IO range is available in the DT, and the driver has a table to map its targets (as their order is still not sequential), thus reducing the DT needed information and binding requirements. The register access macros have been converted to functions. - Bindings: - reg prop: minItems set to 1 - reg-names prop: removed - Driver - Use one IO range and map targets via this. - Change register access macros to use functions. - Provided a new header files with reg access functions. - Device tree - Provide only one IO range v5 -> v6: Series error: This had the same content as v5 v4 -> v5: - Bindings: - Removed .yaml from compatible string - reg prop: removed description and added minItems - reg-names prop: removed description and added const name list and minItems - #phy-cells prop: removed description and added maxItems - Configuration interface - Removed include of linux/phy.h - Added include of linux/types.h - Driver - Added include of linux/phy.h v3 -> v4: - Add a reg-names item to the binding description - Add a clocks item to the binding description - Removed the clock parameter from the configuration interface - Use the clock dt node to get the coreclock, and using that when doing the actual serdes configuration - Added a clocks entry with a system clock reference to the serdes node in the device tree v2 -> v3: - Sorted the Kconfig sourced folders - Sorted the Makefile included folders - Changed the configuration interface documentation to use kernel style v1 -> v2: Fixed kernel test robot warnings - Made these structures static: - media_presets_25g - mode_presets_25g - media_presets_10g - mode_presets_10g - Removed these duplicate initializations: - sparx5_sd25g28_params.cfg_rx_reserve_15_8 - sparx5_sd25g28_params.cfg_pi_en - sparx5_sd25g28_params.cfg_cdrck_en - sparx5_sd10g28_params.cfg_cdrck_en Lars Povlsen (2): dt-bindings: phy: Add sparx5-serdes bindings arm64: dts: sparx5: Add Sparx5 serdes driver node Steen Hegelund (2): phy: Add ethernet serdes configuration option phy: Add Sparx5 ethernet serdes PHY driver .../bindings/phy/microchip,sparx5-serdes.yaml | 100 + arch/arm64/boot/dts/microchip/sparx5.dtsi | 8 + drivers/phy/Kconfig | 1 + drivers/phy/Makefile | 1 + drivers/phy/microchip/Kconfig | 12 + drivers/phy/microchip/Makefile | 6 + drivers/phy/microchip/sparx5_serdes.c | 2444 +++++++++++++++ drivers/phy/microchip/sparx5_serdes.h | 124 + drivers/phy/microchip/sparx5_serdes_regs.h | 2695 +++++++++++++++++ include/linux/phy/phy-ethernet-serdes.h | 30 + include/linux/phy/phy.h | 4 + 11 files changed, 5425 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml create mode 100644 drivers/phy/microchip/Kconfig create mode 100644 drivers/phy/microchip/Makefile create mode 100644 drivers/phy/microchip/sparx5_serdes.c create mode 100644 drivers/phy/microchip/sparx5_serdes.h create mode 100644 drivers/phy/microchip/sparx5_serdes_regs.h create mode 100644 include/linux/phy/phy-ethernet-serdes.h -- 2.29.2