stmmac.txt 12 KB

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