u-boot/drivers/net/fm/t1024.c

88 lines
2.2 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0+
powerpc/mpc85xx: Add T1024/T1023 SoC support Add support for Freescale T1024/T1023 SoC. The T1024 SoC includes the following function and features: - Two 64-bit Power architecture e5500 cores, up to 1.4GHz - private 256KB L2 cache each core and shared 256KB CoreNet platform cache (CPC) - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving support - Data Path Acceleration Architecture (DPAA) incorporating acceleration - Four MAC for 1G/2.5G/10G network interfaces (RGMII, SGMII, QSGMII, XFI) - High-speed peripheral interfaces - Three PCI Express 2.0 controllers - Additional peripheral interfaces - One SATA 2.0 controller - Two USB 2.0 controllers with integrated PHY - Enhanced secure digital host controller (SD/eSDHC/eMMC) - Enhanced serial peripheral interface (eSPI) - Four I2C controllers - Four 2-pin UARTs or two 4-pin UARTs - Integrated Flash Controller supporting NAND and NOR flash - Two 8-channel DMA engines - Multicore programmable interrupt controller (PIC) - LCD interface (DIU) with 12 bit dual data rate - QUICC Engine block supporting TDM, HDLC, and UART - Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB) - Support for hardware virtualization and partitioning enforcement - QorIQ Platform's Trust Architecture 2.0 Differences between T1024 and T1023: Feature T1024 T1023 QUICC Engine: yes no DIU: yes no Deep Sleep: yes no I2C controller: 4 3 DDR: 64-bit 32-bit IFC: 32-bit 28-bit Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
2014-11-24 09:11:54 +00:00
/* Copyright 2014 Freescale Semiconductor, Inc.
*
* Shengzhou Liu <Shengzhou.Liu@freescale.com>
*/
#include <common.h>
#include <phy.h>
#include <fm_eth.h>
#include <asm/immap_85xx.h>
#include <asm/fsl_serdes.h>
u32 port_to_devdisr[] = {
[FM1_DTSEC1] = FSL_CORENET_DEVDISR2_DTSEC1_1,
[FM1_DTSEC2] = FSL_CORENET_DEVDISR2_DTSEC1_2,
[FM1_DTSEC3] = FSL_CORENET_DEVDISR2_DTSEC1_3,
[FM1_DTSEC4] = FSL_CORENET_DEVDISR2_DTSEC1_4,
[FM1_10GEC1] = FSL_CORENET_DEVDISR2_10GEC1_1, /* MAC1 */
};
static int is_device_disabled(enum fm_port port)
{
ccsr_gur_t *gur = (void __iomem *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
u32 devdisr2 = in_be32(&gur->devdisr2);
return port_to_devdisr[port] & devdisr2;
}
void fman_disable_port(enum fm_port port)
{
ccsr_gur_t *gur = (void __iomem *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
setbits_be32(&gur->devdisr2, port_to_devdisr[port]);
}
phy_interface_t fman_port_enet_if(enum fm_port port)
{
ccsr_gur_t *gur = (void __iomem *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
u32 rcwsr13 = in_be32(&gur->rcwsr[13]);
if (is_device_disabled(port))
return PHY_INTERFACE_MODE_NONE;
if ((port == FM1_10GEC1) && (is_serdes_configured(XFI_FM1_MAC1)))
return PHY_INTERFACE_MODE_XGMII;
if ((port == FM1_DTSEC3) && ((rcwsr13 & FSL_CORENET_RCWSR13_EC2) ==
FSL_CORENET_RCWSR13_EC2_RGMII) &&
(!is_serdes_configured(QSGMII_FM1_A)))
return PHY_INTERFACE_MODE_RGMII;
if ((port == FM1_DTSEC4) && ((rcwsr13 & FSL_CORENET_RCWSR13_EC1) ==
FSL_CORENET_RCWSR13_EC1_RGMII) &&
(!is_serdes_configured(QSGMII_FM1_A)))
return PHY_INTERFACE_MODE_RGMII;
/* handle SGMII */
switch (port) {
case FM1_DTSEC1:
case FM1_DTSEC2:
case FM1_DTSEC3:
if (is_serdes_configured(SGMII_FM1_DTSEC1 + port - FM1_DTSEC1))
return PHY_INTERFACE_MODE_SGMII;
else if (is_serdes_configured(SGMII_2500_FM1_DTSEC1
+ port - FM1_DTSEC1))
net: freescale: replace usage of phy-mode = "sgmii-2500" with "2500base-x" After the discussion here: https://lore.kernel.org/netdev/20210603143453.if7hgifupx5k433b@pali/ which resulted in this patch: https://patchwork.kernel.org/project/netdevbpf/patch/20210704134325.24842-1-pali@kernel.org/ and many other discussions before it, notably: https://patchwork.kernel.org/project/linux-arm-kernel/patch/1512016235-15909-1-git-send-email-Bhaskar.Upadhaya@nxp.com/ it became apparent that nobody really knows what "SGMII 2500" is. Certainly, Freescale/NXP hardware engineers name this protocol "SGMII 2500" in the reference manuals, but the PCS devices do not support any "SGMII" specific features when operating at the speed of 2500 Mbps, no in-band autoneg and no speed change via symbol replication . So that leaves a fixed speed of 2500 Mbps using a coding of 8b/10b with a SERDES lane frequency of 3.125 GHz. In fact, "SGMII 2500 without in-band autoneg and at a fixed speed" is indistinguishable from "2500base-x without in-band autoneg", which is precisely what these NXP devices support. So it just appears that "SGMII 2500" is an unclear name with no clear definition that stuck. As such, in the Linux kernel, the drivers which use this SERDES protocol use the 2500base-x phy-mode. This patch converts U-Boot to use 2500base-x too, or at least, as much as it can. Note that I would have really liked to delete PHY_INTERFACE_MODE_SGMII_2500 completely, but the mvpp2 driver seems to even distinguish between SGMII 2500 and 2500base-X. Namely, it enables in-band autoneg for one but not the other, and forces flow control for one but not the other. This goes back to the idea that maybe 2500base-X is a fiber protocol and SGMII-2500 is an MII protocol (connects a MAC to a PHY such as Aquantia), but the two are practically indistinguishable through everything except use case. NXP devices can support both use cases through an identical configuration, for example RX flow control can be unconditionally enabled in order to support rate adaptation performed by an Aquantia PHY. At least I can find no indication in online documents published by Cisco which would point towards "SGMII-2500" being an actual standard with an actual definition, so I cannot say "yes, NXP devices support it". Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-18 12:32:35 +00:00
return PHY_INTERFACE_MODE_2500BASEX;
powerpc/mpc85xx: Add T1024/T1023 SoC support Add support for Freescale T1024/T1023 SoC. The T1024 SoC includes the following function and features: - Two 64-bit Power architecture e5500 cores, up to 1.4GHz - private 256KB L2 cache each core and shared 256KB CoreNet platform cache (CPC) - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving support - Data Path Acceleration Architecture (DPAA) incorporating acceleration - Four MAC for 1G/2.5G/10G network interfaces (RGMII, SGMII, QSGMII, XFI) - High-speed peripheral interfaces - Three PCI Express 2.0 controllers - Additional peripheral interfaces - One SATA 2.0 controller - Two USB 2.0 controllers with integrated PHY - Enhanced secure digital host controller (SD/eSDHC/eMMC) - Enhanced serial peripheral interface (eSPI) - Four I2C controllers - Four 2-pin UARTs or two 4-pin UARTs - Integrated Flash Controller supporting NAND and NOR flash - Two 8-channel DMA engines - Multicore programmable interrupt controller (PIC) - LCD interface (DIU) with 12 bit dual data rate - QUICC Engine block supporting TDM, HDLC, and UART - Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB) - Support for hardware virtualization and partitioning enforcement - QorIQ Platform's Trust Architecture 2.0 Differences between T1024 and T1023: Feature T1024 T1023 QUICC Engine: yes no DIU: yes no Deep Sleep: yes no I2C controller: 4 3 DDR: 64-bit 32-bit IFC: 32-bit 28-bit Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
2014-11-24 09:11:54 +00:00
break;
default:
break;
}
/* handle QSGMII */
switch (port) {
case FM1_DTSEC1:
case FM1_DTSEC2:
case FM1_DTSEC3:
case FM1_DTSEC4:
/* check lane A on SerDes1 */
if (is_serdes_configured(QSGMII_FM1_A))
return PHY_INTERFACE_MODE_QSGMII;
break;
default:
break;
}
return PHY_INTERFACE_MODE_NONE;
}