1 STMicroelectronics 10/100/1000 Synopsys Ethernet driver 2 3Copyright (C) 2007-2015 STMicroelectronics Ltd 4Author: Giuseppe Cavallaro <peppe.cavallaro@st.com> 5 6This is the driver for the MAC 10/100/1000 on-chip Ethernet controllers 7(Synopsys IP blocks). 8 9Currently this network device driver is for all STi embedded MAC/GMAC 10(i.e. 7xxx/5xxx SoCs), SPEAr (arm), Loongson1B (mips) and XLINX XC2V3000 11FF1152AMT0221 D1215994A VIRTEX FPGA board. 12 13DWC Ether MAC 10/100/1000 Universal version 3.70a (and older) and DWC Ether 14MAC 10/100 Universal version 4.0 have been used for developing this driver. 15 16This driver supports both the platform bus and PCI. 17 18Please, for more information also visit: www.stlinux.com 19 201) Kernel Configuration 21The kernel configuration option is STMMAC_ETH: 22 Device Drivers ---> Network device support ---> Ethernet (1000 Mbit) ---> 23 STMicroelectronics 10/100/1000 Ethernet driver (STMMAC_ETH) 24 25CONFIG_STMMAC_PLATFORM: is to enable the platform driver. 26CONFIG_STMMAC_PCI: is to enable the pci driver. 27 282) Driver parameters list: 29 debug: message level (0: no output, 16: all); 30 phyaddr: to manually provide the physical address to the PHY device; 31 dma_rxsize: DMA rx ring size; 32 dma_txsize: DMA tx ring size; 33 buf_sz: DMA buffer size; 34 tc: control the HW FIFO threshold; 35 watchdog: transmit timeout (in milliseconds); 36 flow_ctrl: Flow control ability [on/off]; 37 pause: Flow Control Pause Time; 38 eee_timer: tx EEE timer; 39 chain_mode: select chain mode instead of ring. 40 413) Command line options 42Driver parameters can be also passed in command line by using: 43 stmmaceth=dma_rxsize:128,dma_txsize:512 44 454) Driver information and notes 46 474.1) Transmit process 48The xmit method is invoked when the kernel needs to transmit a packet; it sets 49the descriptors in the ring and informs the DMA engine that there is a packet 50ready to be transmitted. 51By default, the driver sets the NETIF_F_SG bit in the features field of the 52net_device structure enabling the scatter-gather feature. This is true on 53chips and configurations where the checksum can be done in hardware. 54Once the controller has finished transmitting the packet, napi will be 55scheduled to release the transmit resources. 56 574.2) Receive process 58When one or more packets are received, an interrupt happens. The interrupts 59are not queued so the driver has to scan all the descriptors in the ring during 60the receive process. 61This is based on NAPI so the interrupt handler signals only if there is work 62to be done, and it exits. 63Then the poll method will be scheduled at some future point. 64The incoming packets are stored, by the DMA, in a list of pre-allocated socket 65buffers in order to avoid the memcpy (zero-copy). 66 674.3) Interrupt Mitigation 68The driver is able to mitigate the number of its DMA interrupts 69using NAPI for the reception on chips older than the 3.50. 70New chips have an HW RX-Watchdog used for this mitigation. 71Mitigation parameters can be tuned by ethtool. 72 734.4) WOL 74Wake up on Lan feature through Magic and Unicast frames are supported for the 75GMAC core. 76 774.5) DMA descriptors 78Driver handles both normal and alternate descriptors. The latter has been only 79tested on DWC Ether MAC 10/100/1000 Universal version 3.41a and later. 80 81STMMAC supports DMA descriptor to operate both in dual buffer (RING) 82and linked-list(CHAINED) mode. In RING each descriptor points to two 83data buffer pointers whereas in CHAINED mode they point to only one data 84buffer pointer. RING mode is the default. 85 86In CHAINED mode each descriptor will have pointer to next descriptor in 87the list, hence creating the explicit chaining in the descriptor itself, 88whereas such explicit chaining is not possible in RING mode. 89 904.5.1) Extended descriptors 91 The extended descriptors give us information about the Ethernet payload 92 when it is carrying PTP packets or TCP/UDP/ICMP over IP. 93 These are not available on GMAC Synopsys chips older than the 3.50. 94 At probe time the driver will decide if these can be actually used. 95 This support also is mandatory for PTPv2 because the extra descriptors 96 are used for saving the hardware timestamps and Extended Status. 97 984.6) Ethtool support 99Ethtool is supported. 100 101For example, driver statistics (including RMON), internal errors can be taken 102using: 103 # ethtool -S ethX command 104 1054.7) Jumbo and Segmentation Offloading 106Jumbo frames are supported and tested for the GMAC. 107The GSO has been also added but it's performed in software. 108LRO is not supported. 109 1104.8) Physical 111The driver is compatible with Physical Abstraction Layer to be connected with 112PHY and GPHY devices. 113 1144.9) Platform information 115Several information can be passed through the platform and device-tree. 116 117struct plat_stmmacenet_data { 118 char *phy_bus_name; 119 int bus_id; 120 int phy_addr; 121 int interface; 122 struct stmmac_mdio_bus_data *mdio_bus_data; 123 struct stmmac_dma_cfg *dma_cfg; 124 int clk_csr; 125 int has_gmac; 126 int enh_desc; 127 int tx_coe; 128 int rx_coe; 129 int bugged_jumbo; 130 int pmt; 131 int force_sf_dma_mode; 132 int force_thresh_dma_mode; 133 int riwt_off; 134 int max_speed; 135 int maxmtu; 136 void (*fix_mac_speed)(void *priv, unsigned int speed); 137 void (*bus_setup)(void __iomem *ioaddr); 138 int (*init)(struct platform_device *pdev, void *priv); 139 void (*exit)(struct platform_device *pdev, void *priv); 140 void *bsp_priv; 141 int has_gmac4; 142 bool tso_en; 143}; 144 145Where: 146 o phy_bus_name: phy bus name to attach to the stmmac. 147 o bus_id: bus identifier. 148 o phy_addr: the physical address can be passed from the platform. 149 If it is set to -1 the driver will automatically 150 detect it at run-time by probing all the 32 addresses. 151 o interface: PHY device's interface. 152 o mdio_bus_data: specific platform fields for the MDIO bus. 153 o dma_cfg: internal DMA parameters 154 o pbl: the Programmable Burst Length is maximum number of beats to 155 be transferred in one DMA transaction. 156 GMAC also enables the 4xPBL by default. 157 o fixed_burst/mixed_burst/burst_len 158 o clk_csr: fixed CSR Clock range selection. 159 o has_gmac: uses the GMAC core. 160 o enh_desc: if sets the MAC will use the enhanced descriptor structure. 161 o tx_coe: core is able to perform the tx csum in HW. 162 o rx_coe: the supports three check sum offloading engine types: 163 type_1, type_2 (full csum) and no RX coe. 164 o bugged_jumbo: some HWs are not able to perform the csum in HW for 165 over-sized frames due to limited buffer sizes. 166 Setting this flag the csum will be done in SW on 167 JUMBO frames. 168 o pmt: core has the embedded power module (optional). 169 o force_sf_dma_mode: force DMA to use the Store and Forward mode 170 instead of the Threshold. 171 o force_thresh_dma_mode: force DMA to use the Threshold mode other than 172 the Store and Forward mode. 173 o riwt_off: force to disable the RX watchdog feature and switch to NAPI mode. 174 o fix_mac_speed: this callback is used for modifying some syscfg registers 175 (on ST SoCs) according to the link speed negotiated by the 176 physical layer . 177 o bus_setup: perform HW setup of the bus. For example, on some ST platforms 178 this field is used to configure the AMBA bridge to generate more 179 efficient STBus traffic. 180 o init/exit: callbacks used for calling a custom initialization; 181 this is sometime necessary on some platforms (e.g. ST boxes) 182 where the HW needs to have set some PIO lines or system cfg 183 registers. init/exit callbacks should not use or modify 184 platform data. 185 o bsp_priv: another private pointer. 186 o has_gmac4: uses GMAC4 core. 187 o tso_en: Enables TSO (TCP Segmentation Offload) feature. 188 189For MDIO bus The we have: 190 191 struct stmmac_mdio_bus_data { 192 int (*phy_reset)(void *priv); 193 unsigned int phy_mask; 194 int *irqs; 195 int probed_phy_irq; 196 }; 197 198Where: 199 o phy_reset: hook to reset the phy device attached to the bus. 200 o phy_mask: phy mask passed when register the MDIO bus within the driver. 201 o irqs: list of IRQs, one per PHY. 202 o probed_phy_irq: if irqs is NULL, use this for probed PHY. 203 204For DMA engine we have the following internal fields that should be 205tuned according to the HW capabilities. 206 207struct stmmac_dma_cfg { 208 int pbl; 209 int fixed_burst; 210 int burst_len_supported; 211}; 212 213Where: 214 o pbl: Programmable Burst Length 215 o fixed_burst: program the DMA to use the fixed burst mode 216 o burst_len: this is the value we put in the register 217 supported values are provided as macros in 218 linux/stmmac.h header file. 219 220--- 221 222Below an example how the structures above are using on ST platforms. 223 224 static struct plat_stmmacenet_data stxYYY_ethernet_platform_data = { 225 .has_gmac = 0, 226 .enh_desc = 0, 227 .fix_mac_speed = stxYYY_ethernet_fix_mac_speed, 228 | 229 |-> to write an internal syscfg 230 | on this platform when the 231 | link speed changes from 10 to 232 | 100 and viceversa 233 .init = &stmmac_claim_resource, 234 | 235 |-> On ST SoC this calls own "PAD" 236 | manager framework to claim 237 | all the resources necessary 238 | (GPIO ...). The .custom_cfg field 239 | is used to pass a custom config. 240}; 241 242Below the usage of the stmmac_mdio_bus_data: on this SoC, in fact, 243there are two MAC cores: one MAC is for MDIO Bus/PHY emulation 244with fixed_link support. 245 246static struct stmmac_mdio_bus_data stmmac1_mdio_bus = { 247 .phy_reset = phy_reset; 248 | 249 |-> function to provide the phy_reset on this board 250 .phy_mask = 0, 251}; 252 253static struct fixed_phy_status stmmac0_fixed_phy_status = { 254 .link = 1, 255 .speed = 100, 256 .duplex = 1, 257}; 258 259During the board's device_init we can configure the first 260MAC for fixed_link by calling: 261 fixed_phy_add(PHY_POLL, 1, &stmmac0_fixed_phy_status, -1); 262and the second one, with a real PHY device attached to the bus, 263by using the stmmac_mdio_bus_data structure (to provide the id, the 264reset procedure etc). 265 266Note that, starting from new chips, where it is available the HW capability 267register, many configurations are discovered at run-time for example to 268understand if EEE, HW csum, PTP, enhanced descriptor etc are actually 269available. As strategy adopted in this driver, the information from the HW 270capability register can replace what has been passed from the platform. 271 2724.10) Device-tree support. 273 274Please see the following document: 275 Documentation/devicetree/bindings/net/stmmac.txt 276 2774.11) This is a summary of the content of some relevant files: 278 o stmmac_main.c: to implement the main network device driver; 279 o stmmac_mdio.c: to provide mdio functions; 280 o stmmac_pci: this the PCI driver; 281 o stmmac_platform.c: this the platform driver (OF supported) 282 o stmmac_ethtool.c: to implement the ethtool support; 283 o stmmac.h: private driver structure; 284 o common.h: common definitions and VFTs; 285 o mmc_core.c/mmc.h: Management MAC Counters; 286 o stmmac_hwtstamp.c: HW timestamp support for PTP; 287 o stmmac_ptp.c: PTP 1588 clock; 288 o stmmac_pcs.h: Physical Coding Sublayer common implementation; 289 o dwmac-<XXX>.c: these are for the platform glue-logic file; e.g. dwmac-sti.c 290 for STMicroelectronics SoCs. 291 292- GMAC 3.x 293 o descs.h: descriptor structure definitions; 294 o dwmac1000_core.c: dwmac GiGa core functions; 295 o dwmac1000_dma.c: dma functions for the GMAC chip; 296 o dwmac1000.h: specific header file for the dwmac GiGa; 297 o dwmac100_core: dwmac 100 core code; 298 o dwmac100_dma.c: dma functions for the dwmac 100 chip; 299 o dwmac1000.h: specific header file for the MAC; 300 o dwmac_lib.c: generic DMA functions; 301 o enh_desc.c: functions for handling enhanced descriptors; 302 o norm_desc.c: functions for handling normal descriptors; 303 o chain_mode.c/ring_mode.c:: functions to manage RING/CHAINED modes; 304 305- GMAC4.x generation 306 o dwmac4_core.c: dwmac GMAC4.x core functions; 307 o dwmac4_desc.c: functions for handling GMAC4.x descriptors; 308 o dwmac4_descs.h: descriptor definitions; 309 o dwmac4_dma.c: dma functions for the GMAC4.x chip; 310 o dwmac4_dma.h: dma definitions for the GMAC4.x chip; 311 o dwmac4.h: core definitions for the GMAC4.x chip; 312 o dwmac4_lib.c: generic GMAC4.x functions; 313 3144.12) TSO support (GMAC4.x) 315 316TSO (Tcp Segmentation Offload) feature is supported by GMAC 4.x chip family. 317When a packet is sent through TCP protocol, the TCP stack ensures that 318the SKB provided to the low level driver (stmmac in our case) matches with 319the maximum frame len (IP header + TCP header + payload <= 1500 bytes (for 320MTU set to 1500)). It means that if an application using TCP want to send a 321packet which will have a length (after adding headers) > 1514 the packet 322will be split in several TCP packets: The data payload is split and headers 323(TCP/IP ..) are added. It is done by software. 324 325When TSO is enabled, the TCP stack doesn't care about the maximum frame 326length and provide SKB packet to stmmac as it is. The GMAC IP will have to 327perform the segmentation by it self to match with maximum frame length. 328 329This feature can be enabled in device tree through "snps,tso" entry. 330 3315) Debug Information 332 333The driver exports many information i.e. internal statistics, 334debug information, MAC and DMA registers etc. 335 336These can be read in several ways depending on the 337type of the information actually needed. 338 339For example a user can be use the ethtool support 340to get statistics: e.g. using: ethtool -S ethX 341(that shows the Management counters (MMC) if supported) 342or sees the MAC/DMA registers: e.g. using: ethtool -d ethX 343 344Compiling the Kernel with CONFIG_DEBUG_FS the driver will export the following 345debugfs entries: 346 347/sys/kernel/debug/stmmaceth/descriptors_status 348 To show the DMA TX/RX descriptor rings 349 350Developer can also use the "debug" module parameter to get further debug 351information (please see: NETIF Msg Level). 352 3536) Energy Efficient Ethernet 354 355Energy Efficient Ethernet(EEE) enables IEEE 802.3 MAC sublayer along 356with a family of Physical layer to operate in the Low power Idle(LPI) 357mode. The EEE mode supports the IEEE 802.3 MAC operation at 100Mbps, 3581000Mbps & 10Gbps. 359 360The LPI mode allows power saving by switching off parts of the 361communication device functionality when there is no data to be 362transmitted & received. The system on both the side of the link can 363disable some functionalities & save power during the period of low-link 364utilization. The MAC controls whether the system should enter or exit 365the LPI mode & communicate this to PHY. 366 367As soon as the interface is opened, the driver verifies if the EEE can 368be supported. This is done by looking at both the DMA HW capability 369register and the PHY devices MCD registers. 370To enter in Tx LPI mode the driver needs to have a software timer 371that enable and disable the LPI mode when there is nothing to be 372transmitted. 373 3747) Precision Time Protocol (PTP) 375The driver supports the IEEE 1588-2002, Precision Time Protocol (PTP), 376which enables precise synchronization of clocks in measurement and 377control systems implemented with technologies such as network 378communication. 379 380In addition to the basic timestamp features mentioned in IEEE 1588-2002 381Timestamps, new GMAC cores support the advanced timestamp features. 382IEEE 1588-2008 that can be enabled when configure the Kernel. 383 3848) SGMII/RGMII supports 385New GMAC devices provide own way to manage RGMII/SGMII. 386This information is available at run-time by looking at the 387HW capability register. This means that the stmmac can manage 388auto-negotiation and link status w/o using the PHYLIB stuff 389In fact, the HW provides a subset of extended registers to 390restart the ANE, verify Full/Half duplex mode and Speed. 391Also thanks to these registers it is possible to look at the 392Auto-negotiated Link Parter Ability. 393