1 /*****************************************************************************
3 * (c) Copyright 2010-11 Xilinx, Inc. All rights reserved.
5 * This file contains confidential and proprietary information of Xilinx, Inc.
6 * and is protected under U.S. and international copyright and other
7 * intellectual property laws.
10 * This disclaimer is not a license and does not grant any rights to the
11 * materials distributed herewith. Except as otherwise provided in a valid
12 * license issued to you by Xilinx, and to the maximum extent permitted by
13 * applicable law: (1) THESE MATERIALS ARE MADE AVAILABLE "AS IS" AND WITH ALL
14 * FAULTS, AND XILINX HEREBY DISCLAIMS ALL WARRANTIES AND CONDITIONS, EXPRESS,
15 * IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO WARRANTIES OF
16 * MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE;
17 * and (2) Xilinx shall not be liable (whether in contract or tort, including
18 * negligence, or under any other theory of liability) for any loss or damage
19 * of any kind or nature related to, arising under or in connection with these
20 * materials, including for any direct, or any indirect, special, incidental,
21 * or consequential loss or damage (including loss of data, profits, goodwill,
22 * or any type of loss or damage suffered as a result of any action brought by
23 * a third party) even if such damage or loss was reasonably foreseeable or
24 * Xilinx had been advised of the possibility of the same.
26 * CRITICAL APPLICATIONS
27 * Xilinx products are not designed or intended to be fail-safe, or for use in
28 * any application requiring fail-safe performance, such as life-support or
29 * safety devices or systems, Class III medical devices, nuclear facilities,
30 * applications related to the deployment of airbags, or any other applications
31 * that could lead to death, personal injury, or severe property or
32 * environmental damage (individually and collectively, "Critical
33 * Applications"). Customer assumes the sole risk and liability of any use of
34 * Xilinx products in Critical Applications, subject only to applicable laws
35 * and regulations governing limitations on product liability.
37 * THIS COPYRIGHT NOTICE AND DISCLAIMER MUST BE RETAINED AS PART OF THIS FILE
40 *****************************************************************************/
41 /****************************************************************************/
46 * The Xilinx Embedded Processor Block Ethernet driver.
48 * For a full description of XEMACPS features, please see the hardware spec.
49 * This driver supports the following features:
50 * - Memory mapped access to host interface registers
51 * - Statistics counter registers for RMON/MIB
52 * - API for interrupt driven frame transfers for hardware configured DMA
53 * - Virtual memory support
54 * - Unicast, broadcast, and multicast receive address filtering
55 * - Full and half duplex operation
56 * - Automatic PAD & FCS insertion and stripping
58 * - Support up to four 48bit addresses
59 * - Address checking for four specific 48bit addresses
60 * - VLAN frame support
61 * - Pause frame support
62 * - Large frame support up to 1536 bytes
65 * <b>Driver Description</b>
67 * The device driver enables higher layer software (e.g., an application) to
68 * communicate to the XEmacPs. The driver handles transmission and reception
69 * of Ethernet frames, as well as configuration and control. No pre or post
70 * processing of frame data is performed. The driver does not validate the
71 * contents of an incoming frame in addition to what has already occurred in
73 * A single device driver can support multiple devices even when those devices
74 * have significantly different configurations.
76 * <b>Initialization & Configuration</b>
78 * The XEmacPs_Config structure is used by the driver to configure itself.
79 * This configuration structure is typically created by the tool-chain based
80 * on hardware build properties.
82 * The driver instance can be initialized in
84 * - XEmacPs_CfgInitialize(InstancePtr, CfgPtr, EffectiveAddress): Uses a
85 * configuration structure provided by the caller. If running in a system
86 * with address translation, the provided virtual memory base address
87 * replaces the physical address present in the configuration structure.
89 * The device supports DMA only as current development plan. No FIFO mode is
90 * supported. The driver expects to start the DMA channels and expects that
91 * the user has set up the buffer descriptor lists.
93 * <b>Interrupts and Asynchronous Callbacks</b>
95 * The driver has no dependencies on the interrupt controller. When an
96 * interrupt occurs, the handler will perform a small amount of
97 * housekeeping work, determine the source of the interrupt, and call the
98 * appropriate callback function. All callbacks are registered by the user
101 * <b>Virtual Memory</b>
103 * All virtual to physical memory mappings must occur prior to accessing the
106 * For DMA transactions, user buffers supplied to the driver must be in terms
107 * of their physical address.
111 * The DMA engine uses buffer descriptors (BDs) to describe Ethernet frames.
112 * These BDs are typically chained together into a list the hardware follows
113 * when transferring data in and out of the packet buffers. Each BD describes
114 * a memory region containing either a full or partial Ethernet packet.
116 * Interrupt coalescing is not suppoted from this built-in DMA engine.
118 * This API requires the user to understand how the DMA operates. The
119 * following paragraphs provide some explanation, but the user is encouraged
120 * to read documentation in xemacps_bdring.h as well as study example code
121 * that accompanies this driver.
123 * The API is designed to get BDs to and from the DMA engine in the most
124 * efficient means possible. The first step is to establish a memory region
125 * to contain all BDs for a specific channel. This is done with
126 * XEmacPs_BdRingCreate(). This function sets up a BD ring that hardware will
127 * follow as BDs are processed. The ring will consist of a user defined number
128 * of BDs which will all be partially initialized. For example on the transmit
129 * channel, the driver will initialize all BDs' so that they are configured
130 * for transmit. The more fields that can be permanently setup at
131 * initialization, then the fewer accesses will be needed to each BD while
132 * the DMA engine is in operation resulting in better throughput and CPU
133 * utilization. The best case initialization would require the user to set
134 * only a frame buffer address and length prior to submitting the BD to the
137 * BDs move through the engine with the help of functions
138 * XEmacPs_BdRingAlloc(), XEmacPs_BdRingToHw(), XEmacPs_BdRingFromHw(),
139 * and XEmacPs_BdRingFree().
140 * All these functions handle BDs that are in place. That is, there are no
141 * copies of BDs kept anywhere and any BD the user interacts with is an actual
142 * BD from the same ring hardware accesses.
144 * BDs in the ring go through a series of states as follows:
145 * 1. Idle. The driver controls BDs in this state.
146 * 2. The user has data to transfer. XEmacPs_BdRingAlloc() is called to
147 * reserve BD(s). Once allocated, the user may setup the BD(s) with
148 * frame buffer address, length, and other attributes. The user controls
150 * 3. The user submits BDs to the DMA engine with XEmacPs_BdRingToHw. BDs
151 * in this state are either waiting to be processed by hardware, are in
152 * process, or have been processed. The DMA engine controls BDs in this
154 * 4. Processed BDs are retrieved with XEmacEpv_BdRingFromHw() by the
155 * user. Once retrieved, the user can examine each BD for the outcome of
156 * the DMA transfer. The user controls BDs in this state. After examining
157 * the BDs the user calls XEmacPs_BdRingFree() which places the BDs back
160 * Each of the four BD accessor functions operate on a set of BDs. A set is
161 * defined as a segment of the BD ring consisting of one or more BDs. The user
162 * views the set as a pointer to the first BD along with the number of BDs for
163 * that set. The set can be navigated by using macros XEmacPs_BdNext(). The
164 * user must exercise extreme caution when changing BDs in a set as there is
165 * nothing to prevent doing a mBdNext past the end of the set and modifying a
168 * XEmacPs_BdRingAlloc() + XEmacPs_BdRingToHw(), as well as
169 * XEmacPs_BdRingFromHw() + XEmacPs_BdRingFree() are designed to be used in
170 * tandem. The same BD set retrieved with BdRingAlloc should be the same one
171 * provided to hardware with BdRingToHw. Same goes with BdRingFromHw and
174 * <b>Alignment & Data Cache Restrictions</b>
176 * Due to the design of the hardware, all RX buffers, BDs need to be 4-byte
177 * aligned. Please reference xemacps_bd.h for cache related macros.
181 * - If frame buffers exist in cached memory, then they must be flushed
182 * prior to committing them to hardware.
186 * - If frame buffers exist in cached memory, then the cache must be
187 * invalidated for the memory region containing the frame prior to data
190 * Both cache invalidate/flush are taken care of in driver code.
192 * <b>Buffer Copying</b>
194 * The driver is designed for a zero-copy buffer scheme. That is, the driver
195 * will not copy buffers. This avoids potential throughput bottlenecks within
196 * the driver. If byte copying is required, then the transfer will take longer
199 * <b>Checksum Offloading</b>
201 * The Embedded Processor Block Ethernet can be configured to perform IP, TCP
202 * and UDP checksum offloading in both receive and transmit directions.
204 * IP packets contain a 16-bit checksum field, which is the 16-bit 1s
205 * complement of the 1s complement sum of all 16-bit words in the header.
206 * TCP and UDP packets contain a 16-bit checksum field, which is the 16-bit
207 * 1s complement of the 1s complement sum of all 16-bit words in the header,
208 * the data and a conceptual pseudo header.
210 * To calculate these checksums in software requires each byte of the packet
211 * to be read. For TCP and UDP this can use a large amount of processing power.
212 * Offloading the checksum calculation to hardware can result in significant
213 * performance improvements.
215 * The transmit checksum offload is only available to use DMA in packet buffer
216 * mode. This is because the complete frame to be transmitted must be read
217 * into the packet buffer memory before the checksum can be calculated and
218 * written to the header at the beginning of the frame.
220 * For IP, TCP or UDP receive checksum offload to be useful, the operating
221 * system containing the protocol stack must be aware that this offload is
222 * available so that it can make use of the fact that the hardware has verified
225 * When receive checksum offloading is enabled in the hardware, the IP header
226 * checksum is checked, where the packet meets the following criteria:
228 * 1. If present, the VLAN header must be four octets long and the CFI bit
230 * 2. Encapsulation must be RFC 894 Ethernet Type Encoding or RFC 1042 SNAP
233 * 4. IP header is of a valid length.
234 * 5. Good IP header checksum.
235 * 6. No IP fragmentation.
236 * 7. TCP or UDP packet.
238 * When an IP, TCP or UDP frame is received, the receive buffer descriptor
239 * gives an indication if the hardware was able to verify the checksums.
240 * There is also an indication if the frame had SNAP encapsulation. These
241 * indication bits will replace the type ID match indication bits when the
242 * receive checksum offload is enabled.
244 * If any of the checksums are verified incorrect by the hardware, the packet
245 * is discarded and the appropriate statistics counter incremented.
247 * <b>PHY Interfaces</b>
249 * RGMII 1.3 is the only interface supported.
253 * Asserts are used within all Xilinx drivers to enforce constraints on
254 * parameters. Asserts can be turned off on a system-wide basis by defining,
255 * at compile time, the NDEBUG identifier. By default, asserts are turned on
256 * and it is recommended that users leave asserts on during development. For
257 * deployment use -DNDEBUG compiler switch to remove assert code.
261 * Xilinx drivers are typically composed of two parts, one is the driver
262 * and the other is the adapter. The driver is independent of OS and processor
263 * and is intended to be highly portable. The adapter is OS-specific and
264 * facilitates communication between the driver and an OS.
265 * This driver is intended to be RTOS and processor independent. Any needs for
266 * dynamic memory management, threads or thread mutual exclusion, or cache
267 * control must be satisfied bythe layer above this driver.
270 * MODIFICATION HISTORY:
272 * Ver Who Date Changes
273 * ----- ---- -------- -------------------------------------------------------
274 * 1.00a wsy 01/10/10 First release
275 * 1.00a asa 11/21/11 The function XEmacPs_BdRingFromHwTx in file
276 * xemacps_bdring.c is modified. Earlier it was checking for
277 * "BdLimit"(passed argument) number of BDs for finding out
278 * which BDs are successfully processed. Now one more check
279 * is added. It looks for BDs till the current BD pointer
280 * reaches HwTail. By doing this processing time is saved.
281 * 1.00a asa 01/24/12 The function XEmacPs_BdRingFromHwTx in file
282 * xemacps_bdring.c is modified. Now start of packet is
283 * searched for returning the number of BDs processed.
284 * 1.02a asa 11/05/12 Added a new API for deleting an entry from the HASH
285 * registers. Added a new API to set the bust length.
286 * Added some new hash-defines.
287 * 1.03a asa 01/23/12 Fix for CR #692702 which updates error handling for
288 * Rx errors. Under heavy Rx traffic, there will be a large
289 * number of errors related to receive buffer not available.
290 * Because of a HW bug (SI #692601), under such heavy errors,
291 * the Rx data path can become unresponsive. To reduce the
292 * probabilities for hitting this HW bug, the SW writes to
293 * bit 18 to flush a packet from Rx DPRAM immediately. The
294 * changes for it are done in the function
295 * XEmacPs_IntrHandler.
296 * 1.05a asa 09/23/13 Cache operations on BDs are not required and hence
297 * removed. It is expected that all BDs are allocated in
298 * from uncached area.
299 * 1.06a asa 11/02/13 Changed the value for XEMACPS_RXBUF_LEN_MASK from 0x3fff
300 * to 0x1fff. This fixes the CR#744902.
301 * Made changes in example file xemacps_example.h to fix compilation
302 * issues with iarcc compiler.
303 * 2.0 adk 10/12/13 Updated as per the New Tcl API's
306 ****************************************************************************/
308 #ifndef XEMACPS_H /* prevent circular inclusions */
309 #define XEMACPS_H /* by using protection macros */
315 /***************************** Include Files ********************************/
317 #include "xil_types.h"
318 #include "xil_assert.h"
320 #include "xemacps_hw.h"
321 #include "xemacps_bd.h"
322 #include "xemacps_bdring.h"
324 /************************** Constant Definitions ****************************/
329 #define XEMACPS_DEVICE_NAME "xemacps"
330 #define XEMACPS_DEVICE_DESC "Xilinx PS 10/100/1000 MAC"
333 /** @name Configuration options
335 * Device configuration options. See the XEmacPs_SetOptions(),
336 * XEmacPs_ClearOptions() and XEmacPs_GetOptions() for information on how to
339 * The default state of the options are noted and are what the device and
340 * driver will be set to after calling XEmacPs_Reset() or
341 * XEmacPs_Initialize().
346 #define XEMACPS_PROMISC_OPTION 0x00000001
347 /**< Accept all incoming packets.
348 * This option defaults to disabled (cleared) */
350 #define XEMACPS_FRAME1536_OPTION 0x00000002
351 /**< Frame larger than 1516 support for Tx & Rx.
352 * This option defaults to disabled (cleared) */
354 #define XEMACPS_VLAN_OPTION 0x00000004
355 /**< VLAN Rx & Tx frame support.
356 * This option defaults to disabled (cleared) */
358 #define XEMACPS_FLOW_CONTROL_OPTION 0x00000010
359 /**< Enable recognition of flow control frames on Rx
360 * This option defaults to enabled (set) */
362 #define XEMACPS_FCS_STRIP_OPTION 0x00000020
363 /**< Strip FCS and PAD from incoming frames. Note: PAD from VLAN frames is not
365 * This option defaults to enabled (set) */
367 #define XEMACPS_FCS_INSERT_OPTION 0x00000040
368 /**< Generate FCS field and add PAD automatically for outgoing frames.
369 * This option defaults to disabled (cleared) */
371 #define XEMACPS_LENTYPE_ERR_OPTION 0x00000080
372 /**< Enable Length/Type error checking for incoming frames. When this option is
373 * set, the MAC will filter frames that have a mismatched type/length field
374 * and if XEMACPS_REPORT_RXERR_OPTION is set, the user is notified when these
375 * types of frames are encountered. When this option is cleared, the MAC will
376 * allow these types of frames to be received.
378 * This option defaults to disabled (cleared) */
380 #define XEMACPS_TRANSMITTER_ENABLE_OPTION 0x00000100
381 /**< Enable the transmitter.
382 * This option defaults to enabled (set) */
384 #define XEMACPS_RECEIVER_ENABLE_OPTION 0x00000200
385 /**< Enable the receiver
386 * This option defaults to enabled (set) */
388 #define XEMACPS_BROADCAST_OPTION 0x00000400
389 /**< Allow reception of the broadcast address
390 * This option defaults to enabled (set) */
392 #define XEMACPS_MULTICAST_OPTION 0x00000800
393 /**< Allows reception of multicast addresses programmed into hash
394 * This option defaults to disabled (clear) */
396 #define XEMACPS_RX_CHKSUM_ENABLE_OPTION 0x00001000
397 /**< Enable the RX checksum offload
398 * This option defaults to enabled (set) */
400 #define XEMACPS_TX_CHKSUM_ENABLE_OPTION 0x00002000
401 /**< Enable the TX checksum offload
402 * This option defaults to enabled (set) */
405 #define XEMACPS_DEFAULT_OPTIONS \
406 (XEMACPS_FLOW_CONTROL_OPTION | \
407 XEMACPS_FCS_INSERT_OPTION | \
408 XEMACPS_FCS_STRIP_OPTION | \
409 XEMACPS_BROADCAST_OPTION | \
410 XEMACPS_LENTYPE_ERR_OPTION | \
411 XEMACPS_TRANSMITTER_ENABLE_OPTION | \
412 XEMACPS_RECEIVER_ENABLE_OPTION | \
413 XEMACPS_RX_CHKSUM_ENABLE_OPTION | \
414 XEMACPS_TX_CHKSUM_ENABLE_OPTION)
416 /**< Default options set when device is initialized or reset */
419 /** @name Callback identifiers
421 * These constants are used as parameters to XEmacPs_SetHandler()
424 #define XEMACPS_HANDLER_DMASEND 1
425 #define XEMACPS_HANDLER_DMARECV 2
426 #define XEMACPS_HANDLER_ERROR 3
429 /* Constants to determine the configuration of the hardware device. They are
430 * used to allow the driver to verify it can operate with the hardware.
432 #define XEMACPS_MDIO_DIV_DFT MDC_DIV_32 /**< Default MDIO clock divisor */
434 /* The next few constants help upper layers determine the size of memory
435 * pools used for Ethernet buffers and descriptor lists.
437 #define XEMACPS_MAC_ADDR_SIZE 6 /* size of Ethernet header */
439 #define XEMACPS_MTU 1500 /* max MTU size of Ethernet frame */
440 #define XEMACPS_HDR_SIZE 14 /* size of Ethernet header */
441 #define XEMACPS_HDR_VLAN_SIZE 18 /* size of Ethernet header with VLAN */
442 #define XEMACPS_TRL_SIZE 4 /* size of Ethernet trailer (FCS) */
443 #define XEMACPS_MAX_FRAME_SIZE (XEMACPS_MTU + XEMACPS_HDR_SIZE + \
445 #define XEMACPS_MAX_VLAN_FRAME_SIZE (XEMACPS_MTU + XEMACPS_HDR_SIZE + \
446 XEMACPS_HDR_VLAN_SIZE + XEMACPS_TRL_SIZE)
448 /* DMACR Bust length hash defines */
450 #define XEMACPS_SINGLE_BURST 1
451 #define XEMACPS_4BYTE_BURST 4
452 #define XEMACPS_8BYTE_BURST 8
453 #define XEMACPS_16BYTE_BURST 16
456 /**************************** Type Definitions ******************************/
457 /** @name Typedefs for callback functions
459 * These callbacks are invoked in interrupt context.
463 * Callback invoked when frame(s) have been sent or received in interrupt
464 * driven DMA mode. To set the send callback, invoke XEmacPs_SetHandler().
466 * @param CallBackRef is user data assigned when the callback was set.
469 * See xemacps_hw.h for bitmasks definitions and the device hardware spec for
470 * further information on their meaning.
473 typedef void (*XEmacPs_Handler) (void *CallBackRef);
476 * Callback when an asynchronous error occurs. To set this callback, invoke
477 * XEmacPs_SetHandler() with XEMACPS_HANDLER_ERROR in the HandlerType
480 * @param CallBackRef is user data assigned when the callback was set.
481 * @param Direction defines either receive or transmit error(s) has occurred.
482 * @param ErrorWord definition varies with Direction
485 typedef void (*XEmacPs_ErrHandler) (void *CallBackRef, u8 Direction,
491 * This typedef contains configuration information for a device.
494 u16 DeviceId; /**< Unique ID of device */
495 u32 BaseAddress;/**< Physical base address of IPIF registers */
500 * The XEmacPs driver instance data. The user is required to allocate a
501 * structure of this type for every XEmacPs device in the system. A pointer
502 * to a structure of this type is then passed to the driver API functions.
504 typedef struct XEmacPs {
505 XEmacPs_Config Config; /* Hardware configuration */
506 u32 IsStarted; /* Device is currently started */
507 u32 IsReady; /* Device is initialized and ready */
508 u32 Options; /* Current options word */
510 XEmacPs_BdRing TxBdRing; /* Transmit BD ring */
511 XEmacPs_BdRing RxBdRing; /* Receive BD ring */
513 XEmacPs_Handler SendHandler;
514 XEmacPs_Handler RecvHandler;
518 XEmacPs_ErrHandler ErrorHandler;
524 /***************** Macros (Inline Functions) Definitions ********************/
526 /****************************************************************************/
528 * Retrieve the Tx ring object. This object can be used in the various Ring
531 * @param InstancePtr is the DMA channel to operate on.
533 * @return TxBdRing attribute
537 * XEmacPs_BdRing XEmacPs_GetTxRing(XEmacPs *InstancePtr)
539 *****************************************************************************/
540 #define XEmacPs_GetTxRing(InstancePtr) ((InstancePtr)->TxBdRing)
542 /****************************************************************************/
544 * Retrieve the Rx ring object. This object can be used in the various Ring
547 * @param InstancePtr is the DMA channel to operate on.
549 * @return RxBdRing attribute
553 * XEmacPs_BdRing XEmacPs_GetRxRing(XEmacPs *InstancePtr)
555 *****************************************************************************/
556 #define XEmacPs_GetRxRing(InstancePtr) ((InstancePtr)->RxBdRing)
558 /****************************************************************************/
561 * Enable interrupts specified in <i>Mask</i>. The corresponding interrupt for
562 * each bit set to 1 in <i>Mask</i>, will be enabled.
564 * @param InstancePtr is a pointer to the instance to be worked on.
565 * @param Mask contains a bit mask of interrupts to enable. The mask can
566 * be formed using a set of bitwise or'd values.
569 * The state of the transmitter and receiver are not modified by this function.
571 * void XEmacPs_IntEnable(XEmacPs *InstancePtr, u32 Mask)
573 *****************************************************************************/
574 #define XEmacPs_IntEnable(InstancePtr, Mask) \
575 XEmacPs_WriteReg((InstancePtr)->Config.BaseAddress, \
576 XEMACPS_IER_OFFSET, \
577 (Mask & XEMACPS_IXR_ALL_MASK));
579 /****************************************************************************/
582 * Disable interrupts specified in <i>Mask</i>. The corresponding interrupt for
583 * each bit set to 1 in <i>Mask</i>, will be enabled.
585 * @param InstancePtr is a pointer to the instance to be worked on.
586 * @param Mask contains a bit mask of interrupts to disable. The mask can
587 * be formed using a set of bitwise or'd values.
590 * The state of the transmitter and receiver are not modified by this function.
592 * void XEmacPs_IntDisable(XEmacPs *InstancePtr, u32 Mask)
594 *****************************************************************************/
595 #define XEmacPs_IntDisable(InstancePtr, Mask) \
596 XEmacPs_WriteReg((InstancePtr)->Config.BaseAddress, \
597 XEMACPS_IDR_OFFSET, \
598 (Mask & XEMACPS_IXR_ALL_MASK));
600 /****************************************************************************/
603 * This macro triggers trasmit circuit to send data currently in TX buffer(s).
605 * @param InstancePtr is a pointer to the XEmacPs instance to be worked on.
611 * Signature: void XEmacPs_Transmit(XEmacPs *InstancePtr)
613 *****************************************************************************/
614 #define XEmacPs_Transmit(InstancePtr) \
615 XEmacPs_WriteReg(InstancePtr->Config.BaseAddress, \
616 XEMACPS_NWCTRL_OFFSET, \
617 (XEmacPs_ReadReg(InstancePtr->Config.BaseAddress, \
618 XEMACPS_NWCTRL_OFFSET) | XEMACPS_NWCTRL_STARTTX_MASK))
620 /****************************************************************************/
623 * This macro determines if the device is configured with checksum offloading
624 * on the receive channel
626 * @param InstancePtr is a pointer to the XEmacPs instance to be worked on.
630 * Boolean TRUE if the device is configured with checksum offloading, or
635 * Signature: u32 XEmacPs_IsRxCsum(XEmacPs *InstancePtr)
637 *****************************************************************************/
638 #define XEmacPs_IsRxCsum(InstancePtr) \
639 ((XEmacPs_ReadReg((InstancePtr)->Config.BaseAddress, \
640 XEMACPS_NWCFG_OFFSET) & XEMACPS_NWCFG_RXCHKSUMEN_MASK) \
643 /****************************************************************************/
646 * This macro determines if the device is configured with checksum offloading
647 * on the transmit channel
649 * @param InstancePtr is a pointer to the XEmacPs instance to be worked on.
653 * Boolean TRUE if the device is configured with checksum offloading, or
658 * Signature: u32 XEmacPs_IsTxCsum(XEmacPs *InstancePtr)
660 *****************************************************************************/
661 #define XEmacPs_IsTxCsum(InstancePtr) \
662 ((XEmacPs_ReadReg((InstancePtr)->Config.BaseAddress, \
663 XEMACPS_DMACR_OFFSET) & XEMACPS_DMACR_TCPCKSUM_MASK) \
666 /************************** Function Prototypes *****************************/
669 * Initialization functions in xemacps.c
671 int XEmacPs_CfgInitialize(XEmacPs *InstancePtr, XEmacPs_Config *CfgPtr,
672 u32 EffectiveAddress);
673 void XEmacPs_Start(XEmacPs *InstancePtr);
674 void XEmacPs_Stop(XEmacPs *InstancePtr);
675 void XEmacPs_Reset(XEmacPs *InstancePtr);
678 * Lookup configuration in xemacps_sinit.c
680 XEmacPs_Config *XEmacPs_LookupConfig(u16 DeviceId);
683 * Interrupt-related functions in xemacps_intr.c
684 * DMA only and FIFO is not supported. This DMA does not support coalescing.
686 int XEmacPs_SetHandler(XEmacPs *InstancePtr, u32 HandlerType,
687 void *FuncPtr, void *CallBackRef);
688 void XEmacPs_IntrHandler(void *InstancePtr);
691 * MAC configuration/control functions in XEmacPs_control.c
693 int XEmacPs_SetOptions(XEmacPs *InstancePtr, u32 Options);
694 int XEmacPs_ClearOptions(XEmacPs *InstancePtr, u32 Options);
695 u32 XEmacPs_GetOptions(XEmacPs *InstancePtr);
697 int XEmacPs_SetMacAddress(XEmacPs *InstancePtr, void *AddressPtr, u8 Index);
698 void XEmacPs_GetMacAddress(XEmacPs *InstancePtr, void *AddressPtr, u8 Index);
700 int XEmacPs_SetHash(XEmacPs *InstancePtr, void *AddressPtr);
701 void XEmacPs_ClearHash(XEmacPs *InstancePtr);
702 void XEmacPs_GetHash(XEmacPs *InstancePtr, void *AddressPtr);
704 void XEmacPs_SetMdioDivisor(XEmacPs *InstancePtr,
705 XEmacPs_MdcDiv Divisor);
706 void XEmacPs_SetOperatingSpeed(XEmacPs *InstancePtr, u16 Speed);
707 u16 XEmacPs_GetOperatingSpeed(XEmacPs *InstancePtr);
708 int XEmacPs_PhyRead(XEmacPs *InstancePtr, u32 PhyAddress,
709 u32 RegisterNum, u16 *PhyDataPtr);
710 int XEmacPs_PhyWrite(XEmacPs *InstancePtr, u32 PhyAddress,
711 u32 RegisterNum, u16 PhyData);
712 int XEmacPs_SetTypeIdCheck(XEmacPs *InstancePtr, u32 Id_Check, u8 Index);
714 int XEmacPs_SendPausePacket(XEmacPs *InstancePtr);
715 void XEmacPs_DMABLengthUpdate(XEmacPs *InstancePtr, int BLength);
721 #endif /* end of protection macro */