1       STMicroelectronics 10/100/1000 Synopsys Ethernet driver
   3Copyright (C) 2007-2010  STMicroelectronics Ltd
   4Author: Giuseppe Cavallaro <>
   6This is the driver for the MAC 10/100/1000 on-chip Ethernet controllers
   7(Synopsys IP blocks).
   9Currently this network device driver is for all STM embedded MAC/GMAC
  10(i.e. 7xxx/5xxx SoCs), SPEAr (arm), Loongson1B (mips) and XLINX XC2V3000
  11FF1152AMT0221 D1215994A VIRTEX FPGA board.
  13DWC Ether MAC 10/100/1000 Universal version 3.60a (and older) and DWC Ether
  14MAC 10/100 Universal version 4.0 have been used for developing this driver.
  16This driver supports both the platform bus and PCI.
  18Please, for more information also visit:
  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)
  252) Driver parameters list:
  26        debug: message level (0: no output, 16: all);
  27        phyaddr: to manually provide the physical address to the PHY device;
  28        dma_rxsize: DMA rx ring size;
  29        dma_txsize: DMA tx ring size;
  30        buf_sz: DMA buffer size;
  31        tc: control the HW FIFO threshold;
  32        tx_coe: Enable/Disable Tx Checksum Offload engine;
  33        watchdog: transmit timeout (in milliseconds);
  34        flow_ctrl: Flow control ability [on/off];
  35        pause: Flow Control Pause Time;
  36        tmrate: timer period (only if timer optimisation is configured).
  383) Command line options
  39Driver parameters can be also passed in command line by using:
  40        stmmaceth=dma_rxsize:128,dma_txsize:512
  424) Driver information and notes
  444.1) Transmit process
  45The xmit method is invoked when the kernel needs to transmit a packet; it sets
  46the descriptors in the ring and informs the DMA engine that there is a packet
  47ready to be transmitted.
  48Once the controller has finished transmitting the packet, an interrupt is
  49triggered; So the driver will be able to release the socket buffers.
  50By default, the driver sets the NETIF_F_SG bit in the features field of the
  51net_device structure enabling the scatter/gather feature.
  534.2) Receive process
  54When one or more packets are received, an interrupt happens. The interrupts
  55are not queued so the driver has to scan all the descriptors in the ring during
  56the receive process.
  57This is based on NAPI so the interrupt handler signals only if there is work
  58to be done, and it exits.
  59Then the poll method will be scheduled at some future point.
  60The incoming packets are stored, by the DMA, in a list of pre-allocated socket
  61buffers in order to avoid the memcpy (Zero-copy).
  634.3) Timer-Driver Interrupt
  64Instead of having the device that asynchronously notifies the frame receptions,
  65the driver configures a timer to generate an interrupt at regular intervals.
  66Based on the granularity of the timer, the frames that are received by the
  67device will experience different levels of latency. Some NICs have dedicated
  68timer device to perform this task. STMMAC can use either the RTC device or the
  69TMU channel 2  on STLinux platforms.
  70The timers frequency can be passed to the driver as parameter; when change it,
  71take care of both hardware capability and network stability/performance impact.
  72Several performance tests on STM platforms showed this optimisation allows to
  73spare the CPU while having the maximum throughput.
  754.4) WOL
  76Wake up on Lan feature through Magic and Unicast frames are supported for the
  77GMAC core.
  794.5) DMA descriptors
  80Driver handles both normal and enhanced descriptors. The latter has been only
  81tested on DWC Ether MAC 10/100/1000 Universal version 3.41a and later.
  83STMMAC supports DMA descriptor to operate both in dual buffer (RING)
  84and linked-list(CHAINED) mode. In RING each descriptor points to two
  85data buffer pointers whereas in CHAINED mode they point to only one data
  86buffer pointer. RING mode is the default.
  88In CHAINED mode each descriptor will have pointer to next descriptor in
  89the list, hence creating the explicit chaining in the descriptor itself,
  90whereas such explicit chaining is not possible in RING mode.
  924.6) Ethtool support
  93Ethtool is supported. Driver statistics and internal errors can be taken using:
  94ethtool -S ethX command. It is possible to dump registers etc.
  964.7) Jumbo and Segmentation Offloading
  97Jumbo frames are supported and tested for the GMAC.
  98The GSO has been also added but it's performed in software.
  99LRO is not supported.
 1014.8) Physical
 102The driver is compatible with PAL to work with PHY and GPHY devices.
 1044.9) Platform information
 105Several driver's information can be passed through the platform
 106These are included in the include/linux/stmmac.h header file
 107and detailed below as well:
 109struct plat_stmmacenet_data {
 110        char *phy_bus_name;
 111        int bus_id;
 112        int phy_addr;
 113        int interface;
 114        struct stmmac_mdio_bus_data *mdio_bus_data;
 115        struct stmmac_dma_cfg *dma_cfg;
 116        int clk_csr;
 117        int has_gmac;
 118        int enh_desc;
 119        int tx_coe;
 120        int rx_coe;
 121        int bugged_jumbo;
 122        int pmt;
 123        int force_sf_dma_mode;
 124        void (*fix_mac_speed)(void *priv, unsigned int speed);
 125        void (*bus_setup)(void __iomem *ioaddr);
 126        int (*init)(struct platform_device *pdev);
 127        void (*exit)(struct platform_device *pdev);
 128        void *custom_cfg;
 129        void *custom_data;
 130        void *bsp_priv;
 131 };
 134 o phy_bus_name: phy bus name to attach to the stmmac.
 135 o bus_id: bus identifier.
 136 o phy_addr: the physical address can be passed from the platform.
 137            If it is set to -1 the driver will automatically
 138            detect it at run-time by probing all the 32 addresses.
 139 o interface: PHY device's interface.
 140 o mdio_bus_data: specific platform fields for the MDIO bus.
 141 o dma_cfg: internal DMA parameters
 142   o pbl: the Programmable Burst Length is maximum number of beats to
 143       be transferred in one DMA transaction.
 144       GMAC also enables the 4xPBL by default.
 145   o fixed_burst/mixed_burst/burst_len
 146 o clk_csr: fixed CSR Clock range selection.
 147 o has_gmac: uses the GMAC core.
 148 o enh_desc: if sets the MAC will use the enhanced descriptor structure.
 149 o tx_coe: core is able to perform the tx csum in HW.
 150 o rx_coe: the supports three check sum offloading engine types:
 151           type_1, type_2 (full csum) and no RX coe.
 152 o bugged_jumbo: some HWs are not able to perform the csum in HW for
 153                over-sized frames due to limited buffer sizes.
 154                Setting this flag the csum will be done in SW on
 155                JUMBO frames.
 156 o pmt: core has the embedded power module (optional).
 157 o force_sf_dma_mode: force DMA to use the Store and Forward mode
 158                     instead of the Threshold.
 159 o fix_mac_speed: this callback is used for modifying some syscfg registers
 160                 (on ST SoCs) according to the link speed negotiated by the
 161                 physical layer .
 162 o bus_setup: perform HW setup of the bus. For example, on some ST platforms
 163             this field is used to configure the AMBA  bridge to generate more
 164             efficient STBus traffic.
 165 o init/exit: callbacks used for calling a custom initialisation;
 166             this is sometime necessary on some platforms (e.g. ST boxes)
 167             where the HW needs to have set some PIO lines or system cfg
 168             registers.
 169 o custom_cfg/custom_data: this is a custom configuration that can be passed
 170                           while initialising the resources.
 171 o bsp_priv: another private poiter.
 173For MDIO bus The we have:
 175 struct stmmac_mdio_bus_data {
 176        int (*phy_reset)(void *priv);
 177        unsigned int phy_mask;
 178        int *irqs;
 179        int probed_phy_irq;
 180 };
 183 o phy_reset: hook to reset the phy device attached to the bus.
 184 o phy_mask: phy mask passed when register the MDIO bus within the driver.
 185 o irqs: list of IRQs, one per PHY.
 186 o probed_phy_irq: if irqs is NULL, use this for probed PHY.
 188For DMA engine we have the following internal fields that should be
 189tuned according to the HW capabilities.
 191struct stmmac_dma_cfg {
 192        int pbl;
 193        int fixed_burst;
 194        int burst_len_supported;
 198 o pbl: Programmable Burst Length
 199 o fixed_burst: program the DMA to use the fixed burst mode
 200 o burst_len: this is the value we put in the register
 201              supported values are provided as macros in
 202              linux/stmmac.h header file.
 206Below an example how the structures above are using on ST platforms.
 208 static struct plat_stmmacenet_data stxYYY_ethernet_platform_data = {
 209        .has_gmac = 0,
 210        .enh_desc = 0,
 211        .fix_mac_speed = stxYYY_ethernet_fix_mac_speed,
 212                                |
 213                                |-> to write an internal syscfg
 214                                |   on this platform when the
 215                                |   link speed changes from 10 to
 216                                |   100 and viceversa
 217        .init = &stmmac_claim_resource,
 218                                |
 219                                |-> On ST SoC this calls own "PAD"
 220                                |   manager framework to claim
 221                                |   all the resources necessary
 222                                |   (GPIO ...). The .custom_cfg field
 223                                |   is used to pass a custom config.
 226Below the usage of the stmmac_mdio_bus_data: on this SoC, in fact,
 227there are two MAC cores: one MAC is for MDIO Bus/PHY emulation
 228with fixed_link support.
 230static struct stmmac_mdio_bus_data stmmac1_mdio_bus = {
 231        .phy_reset = phy_reset;
 232                |
 233                |-> function to provide the phy_reset on this board
 234        .phy_mask = 0,
 237static struct fixed_phy_status stmmac0_fixed_phy_status = {
 238        .link = 1,
 239        .speed = 100,
 240        .duplex = 1,
 243During the board's device_init we can configure the first
 244MAC for fixed_link by calling:
 245  fixed_phy_add(PHY_POLL, 1, &stmmac0_fixed_phy_status));)
 246and the second one, with a real PHY device attached to the bus,
 247by using the stmmac_mdio_bus_data structure (to provide the id, the
 248reset procedure etc).
 2504.10) List of source files:
 251 o Kconfig
 252 o Makefile
 253 o stmmac_main.c: main network device driver;
 254 o stmmac_mdio.c: mdio functions;
 255 o stmmac_pci: PCI driver;
 256 o stmmac_platform.c: platform driver
 257 o stmmac_ethtool.c: ethtool support;
 258 o stmmac_timer.[ch]: timer code used for mitigating the driver dma interrupts
 259                      (only tested on ST40 platforms based);
 260 o stmmac.h: private driver structure;
 261 o common.h: common definitions and VFTs;
 262 o descs.h: descriptor structure definitions;
 263 o dwmac1000_core.c: GMAC core functions;
 264 o dwmac1000_dma.c:  dma functions for the GMAC chip;
 265 o dwmac1000.h: specific header file for the GMAC;
 266 o dwmac100_core: MAC 100 core and dma code;
 267 o dwmac100_dma.c: dma funtions for the MAC chip;
 268 o dwmac1000.h: specific header file for the MAC;
 269 o dwmac_lib.c: generic DMA functions shared among chips;
 270 o enh_desc.c: functions for handling enhanced descriptors;
 271 o norm_desc.c: functions for handling normal descriptors;
 272 o chain_mode.c/ring_mode.c:: functions to manage RING/CHAINED modes;
 273 o mmc_core.c/mmc.h: Management MAC Counters;
 2755) Debug Information
 277The driver exports many information i.e. internal statistics,
 278debug information, MAC and DMA registers etc.
 280These can be read in several ways depending on the
 281type of the information actually needed.
 283For example a user can be use the ethtool support
 284to get statistics: e.g. using: ethtool -S ethX
 285(that shows the Management counters (MMC) if supported)
 286or sees the MAC/DMA registers: e.g. using: ethtool -d ethX
 288Compiling the Kernel with CONFIG_DEBUG_FS and enabling the
 289STMMAC_DEBUG_FS option the driver will export the following
 290debugfs entries:
 293  To show the DMA TX/RX descriptor rings
 295Developer can also use the "debug" module parameter to get
 296further debug information.
 298In the end, there are other macros (that cannot be enabled
 299via menuconfig) to turn-on the RX/TX DMA debugging,
 300specific MAC core debug printk etc. Others to enable the
 301debug in the TX and RX processes.
 302All these are only useful during the developing stage
 303and should never enabled inside the code for general usage.
 304In fact, these can generate an huge amount of debug messages.
 3066) Energy Efficient Ethernet
 308Energy Efficient Ethernet(EEE) enables IEEE 802.3 MAC sublayer along
 309with a family of Physical layer to operate in the Low power Idle(LPI)
 310mode. The EEE mode supports the IEEE 802.3 MAC operation at 100Mbps,
 3111000Mbps & 10Gbps.
 313The LPI mode allows power saving by switching off parts of the
 314communication device functionality when there is no data to be
 315transmitted & received. The system on both the side of the link can
 316disable some functionalities & save power during the period of low-link
 317utilization. The MAC controls whether the system should enter or exit
 318the LPI mode & communicate this to PHY.
 320As soon as the interface is opened, the driver verifies if the EEE can
 321be supported. This is done by looking at both the DMA HW capability
 322register and the PHY devices MCD registers.
 323To enter in Tx LPI mode the driver needs to have a software timer
 324that enable and disable the LPI mode when there is nothing to be
 3277) TODO:
 328 o XGMAC is not supported.
 329 o Add the PTP - precision time protocol
 330 kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.