/* zxr10_motTsecEnd.c - zxr10_motorola Three-Speed Ethernet Controller network interface.*//* Copyright 1989-2004 Wind River Systems, Inc. */#include "copyright_wrs.h"/*modification history--------------------01t,19nov04,pmr  SPR 104443 - back-ported bug fixes from VxWorks 6.0 version01s,26oct04,rcs  Fixed SPR 102905 - multicast not working01r,14oct04,dtr  SPR 102536 - performance enhancements.01q,01oct04,rcs  Stream lined the receive and transmit fucnctions.01p,24sep04,jln  fixed a memory leak for zxr10_motTsecUnload01o,09sep04,jln  fixed MIB support01n,01sep04,rcs  Added pulled mode generic MIB support and zxr10_motTsecUnload01m,31aug04,mdo  Documentation fixes for apigen01l,08aug04,dtr  fixed SPR 100706.01k,21jul04,rcs  fixed SPR 99009 and SPR 9674501j,21jun04,mil  Changed cacheArchXXX funcs to cacheXXX funcs.01i,12may04,rcs  Set maccfg2 register to match PHY when auto-negotiation                 establishes a half duplex connection01h,12may04,rcs  Fixed SPR9701201g,14apr04,rcs  Fixed SPR9625301f,26mar04,rcs  Fixed SPR95430, SPR95433, SPR95434, and SPR9543501e,12feb04,rcs  Added pull up code to coalesce fragments when mBlk chains                 exceed available resources.01d,11feb04,rcs  Added netJobAdds for zxr10_motTsecHandle() when txStall condition.01c,02feb04,rcs  Added workaround for softReset().01b,08aug03,rcs  Modified to make operational01a,14jan03,gjc  zxr10_motorola TSEC END Driver.*//*DESCRIPTIONThis module implements a zxr10_motorola Three-Speed Ethernet Controller (TSEC)Ethernet network interface driver.The drivers work load is distributed between the interrupt and the net jobqueue. Only one net job add is allowed per interrupt. Allocation of tuples happens in the code executing on the job context.RFC 2233 and IPV6 support were added as features.The TSEC supports several communication protocols. This driver supports the TSECto operate in Ethernet mode which is fully compliant with the IEEE 802.3u10Base-T and 100Base-T specifications.The TSEC establishes a shared memory communication system with the CPU,which may be divided into three parts: a set of Control/Status Registers (CSR)and TSEC-specific parameters, the buffer descriptors (BD), and the data buffers.Both the CSRs and the internal parameters reside in the MPC8560's internalRAM. They are used for mode control and to extract status informationof a global nature. For instance, the types of events that shouldgenerate an interrupt, or features like the promiscuous mode or theheartbeat control may be set programming some of the CSRs properly.Pointers to both the Transmit Buffer Descriptors ring (TBD) and theReceive Buffer Descriptors ring (RBD) are stored in the internal parameterRAM. The latter also includes protocol-specific parameters, like theindividual physical address of this station or the max receive frame length.The BDs are used to pass data buffers and related buffer informationbetween the hardware and the software. They may reside either on the 60xbus, or on the CPM local bus They include local status information and apointer to the incoming or outgoing data buffers. These are located againin external memory, and the user may chose whether this is on the 60x bus,or the CPM local bus (see below).This driver is designed to be moderately generic. Without modification, it canoperate across all the TSECs in the MPC8260, regardless of where the internalmemory base address is located. To achieve this goal, this driver must begiven several target-specific parameters, and some external support routinesmust be provided.  These parameters, and the mechanisms used to communicatethem to the driver, are detailed below.This network interface driver does not include support for trailer protocolsor data chaining.  However, buffer loaning has been implemented in an effortto boost performance. In addition, no copy is performed of the outgoing packetbefore it is sent.BOARD LAYOUTThis device is on-board.  No jumpering diagram is necessary.EXTERNAL INTERFACEThe driver provides the standard external interface, zxr10_motTsecEnd2Load(), whichtakes a string of colon-separated parameters. The parameters should bespecified in hexadecimal, optionally preceded by "0x" or a minus sign "-".The parameter string is parsed using strtok_r() and each parameter isconverted from a string representation to binary by a call tostrtoul(parameter, NULL, 16).The format of the parameter string is:"<immrVal>:<tsecNum>:<bdBase>:<bdSize>:<bufBase>:<bufSize>:<fifoTxBase>:<fifoRxBase> :<tbdNum>:<rbdNum>:<phyAddr>:<phyDefMode>:<userFlags>:<function table>"TARGET-SPECIFIC PARAMETERS\is\i <immrVal>Indicates the address at which the host processor presents its internalmemory (also known as the internal RAM base address). With this address,and the tsecNum (see below), the driver is able to compute the location ofthe TSEC parameter RAM, and, ultimately, to program the TSEC for properoperations.\i <tsecNum>This driver is written to support multiple individual device units.This parameter is used to explicitly state which TSEC is being used (on thevads8260 board, TSEC2 is wired to the Fast Ethernet transceiver, thus thisparameter equals "2").\i <bdBase>The zxr10_motorola Fast Communication Controller is a DMA-type device and typicallyshares access to some region of memory with the CPU. This driver is designedfor systems that directly share memory between the CPU and the TSEC.This parameter tells the driver that space for both the TBDs and theRBDs needs not be allocated but should be taken from a cache-coherentprivate memory space provided by the user at the given address. The usershould be aware that memory used for buffers descriptors must be 8-bytealigned and non-cacheable. Therefore, the given memory space should allowfor all the buffer descriptors and the 8-byte alignment factor.If this parameter is "NONE", space for buffer descriptors is obtainedby calling cacheDmaMalloc() in zxr10_motTsecEndLoad().\i <bdSize>The memory size parameter specifies the size of the pre-allocated memoryregion for the BDs. If <bdBase> is specified as NONE (-1), the driver ignoresthis parameter. Otherwise, the driver checks the size of the provided memoryregion is adequate with respect to the given number of Transmit BufferDescriptors and Receive Buffer Descriptors.\i <bufBase>This parameter tells the driver that space for data buffersneeds not be allocated but should be taken from a cache-coherentprivate memory space provided by the user at the given address. The usershould be aware that memory used for buffers must be 32-bytealigned and non-cacheable. The TSEC poses one more constraint in that DMAcycles may initiate even when all the incoming data have already beentransferred to memory. This means at most 32 bytes of memory at the end ofeach receive data buffer, may be overwritten during reception. The driverpads that area out, thus consuming some additional memory.If this parameter is "NONE", space for buffer descriptors is obtainedby calling memalign() in sbczxr10_motTsecEndLoad().\i <bufSize>The memory size parameter specifies the size of the pre-allocated memoryregion for data buffers. If <bufBase> is specified as NONE (-1), the driverignores this parameter. Otherwise, the driver checks the size of the providedmemory region is adequate with respect to the given number of Receive BufferDescriptors and a non-configurable number of transmit buffers(ZXR10_MOT_TSEC_TX_CL_NUM).  All the above should fit in the given memory space.This area should also include room for buffer management structures.\i <fifoTxBase>Indicate the base location of the transmit FIFO, in internal memory.The user does not need to initialize this parameter, as the defaultvalue (see ZXR10_MOT_TSEC_FIFO_TX_BASE) is highly optimized for best performance.However, if the user wishes to reserve that very area in internal RAM forother purposes, he may set this parameter to a different value.If <fifoTxBase> is specified as NONE (-1), the driver uses the defaultvalue.\i <fifoRxBase>Indicate the base location of the receive FIFO, in internal memory.The user does not need to initialize this parameter, as the defaultvalue (see ZXR10_MOT_TSEC_FIFO_TX_BASE) is highly optimized for best performance.However, if the user wishes to reserve that very area in internal RAM forother purposes, he may set this parameter to a different value.If <fifoRxBase> is specified as NONE (-1), the driver uses the defaultvalue.\i <tbdNum>This parameter specifies the number of transmit buffer descriptors (TBDs).Each buffer descriptor resides in 8 bytes of the processor's externalRAM space, If this parameter is less than a minimum number specified in themacro ZXR10_MOT_TSEC_TBD_MIN, or if it is "NULL", a default value of 64 (seeZXR10_MOT_TSEC_TBD_DEF_NUM) is used. This number is kept deliberately high, sinceeach packet the driver sends may consume more than a single TBD. Thisparameter should always equal a even number.\i <rbdNum>This parameter specifies the number of receive buffer descriptors (RBDs).Each buffer descriptor resides in 8 bytes of the processor's externalRAM space, and each one points to a 1584-byte buffer again in externalRAM. If this parameter is less than a minimum number specified in themacro ZXR10_MOT_TSEC_RBD_MIN, or if it is "NULL", a default value of 32 (seeZXR10_MOT_TSEC_RBD_DEF_NUM) is used. This parameter should always equal a even number.\i <phyAddr>This parameter specifies the logical address of a MII-compliant physicaldevice (PHY) that is to be used as a physical media on the network.Valid addresses are in the range 0-31. There may be more than one deviceunder the control of the same management interface. The default physicallayer initialization routine will scan the whole range of PHY devicesstarting from the one in <phyAddr>. If this parameter is"MII_PHY_NULL", the default physical layer initialization routine will findout the PHY actual address by scanning the whole range. The one with the lowestaddress will be chosen.\i <phyDefMode>This parameter specifies the operating mode that will be set upby the default physical layer initialization routine in case allthe attempts made to establish a valid link failed. If that happens,the first PHY that matches the specified abilities will be chosen towork in that mode, and the physical link will not be tested.\i <pAnOrderTbl>This parameter may be set to the address of a table that specifies theorder how different subsets of technology abilities should be advertised bythe auto-negotiation process, if enabled. Unless the flag <ZXR10_MOT_TSEC_USR_PHY_TBL>is set in the userFlags field of the load string, the driver ignores thisparameter.The user does not normally need to specify this parameter, since the defaultbehaviour enables auto-negotiation process as described in IEEE 802.3u.\i <userFlags>This field enables the user to give some degree of customization to thedriver.ZXR10_MOT_TSEC_USR_PHY_NO_AN: the default physical layer initializationroutine will exploit the auto-negotiation mechanism as described inthe IEEE Std 802.3u, to bring a valid link up. According to it, allthe link partners on the media will take part to the negotiationprocess, and the highest priority common denominator technology abilitywill be chosen. It the user wishes to prevent auto-negotiation fromoccurring, he may set this bit in the user flags.ZXR10_MOT_TSEC_USR_PHY_TBL: in the auto-negotiation process, PHYsadvertise all their technology abilities at the same time,and the result is that the maximum common denominator is used. However,this behaviour may be changed, and the user may affect the order howeach subset of PHY's abilities is negotiated. Hence, when theZXR10_MOT_TSEC_USR_PHY_TBL bit is set, the default physical layerinitialization routine will look at the zxr10_motTsecAnOrderTbl[] table andauto-negotiate a subset of abilities at a time, as suggested by thetable itself. It is worth noticing here, however, that if theZXR10_MOT_TSEC_USR_PHY_NO_AN bit is on, the above table will be ignored.ZXR10_MOT_TSEC_USR_PHY_NO_FD: the PHY may be set to operate in full duplex mode,provided it has this ability, as a result of the negotiation with otherlink partners. However, in this operating mode, the TSEC will ignore thecollision detect and carrier sense signals. If the user wishes not tonegotiate full duplex mode, he should set the ZXR10_MOT_TSEC_USR_PHY_NO_FD bitin the user flags.ZXR10_MOT_TSEC_USR_PHY_NO_HD: the PHY may be set to operate in half duplex mode,provided it has this ability, as a result of the negotiation with other linkpartners. If the user wishes not to negotiate half duplex mode, he shouldset the ZXR10_MOT_TSEC_USR_PHY_NO_HD bit in the user flags.ZXR10_MOT_TSEC_USR_PHY_NO_100: the PHY may be set to operate at 100Mbit/s speed,provided it has this ability, as a result of the negotiation withother link partners. If the user wishes not to negotiate 100Mbit/s speed,he should set the ZXR10_MOT_TSEC_USR_PHY_NO_100 bit in the user flags.ZXR10_MOT_TSEC_USR_PHY_NO_10: the PHY may be set to operate at 10Mbit/s speed,provided it has this ability, as a result of the negotiation withother link partners. If the user wishes not to negotiate 10Mbit/s speed,he should set the ZXR10_MOT_TSEC_USR_PHY_NO_10 bit in the user flags.ZXR10_MOT_TSEC_USR_PHY_ISO: some boards may have different PHYs controlled by thesame management interface. In some cases, there may be the need ofelectrically isolating some of them from the interface itself, in orderto guarantee a proper behaviour on the medium layer. If the user wishes toelectrically isolate all PHYs from the MII interface, he should set theZXR10_MOT_TSEC_USR_PHY_ISO bit. The default behaviour is to not isolate anyPHY on the board.ZXR10_MOT_TSEC_USR_LOOP: when the ZXR10_MOT_TSEC_USR_LOOP bit is set, the driver willconfigure the TSEC to work in internal loopback mode, with the TX signaldirectly connected to the RX. This mode should only be used for testing.ZXR10_MOT_TSEC_USR_RMON: when the ZXR10_MOT_TSEC_USR_RMON bit is set, the driver willconfigure the TSEC to work in RMON mode, thus collecting network statisticsrequired for RMON support without the need to receive all packets as inpromiscuous mode.ZXR10_MOT_TSEC_USR_BUF_LBUS: when the ZXR10_MOT_TSEC_USR_BUF_LBUS bit is set, the driver willconfigure the TSEC to work as though the data buffers were located in theCPM local bus.ZXR10_MOT_TSEC_USR_BD_LBUS: when the ZXR10_MOT_TSEC_USR_BD_LBUS bit is set, the driver willconfigure the TSEC to work as though the buffer descriptors were located in theCPM local bus.ZXR10_MOT_TSEC_USR_HBC: if the ZXR10_MOT_TSEC_USR_HBC bit is set, the driver willconfigure the TSEC to perform heartbeat check following end of transmissionand the HB bit in the status field of the TBD will be set if the collisioninput does not assert within the heartbeat window. The user does not normallyneed to set this bit.\i <Function>This is a pointer to the structure TSEC_END_FUNCS. The structure contains mostlyFUNCPTRs that are used as a communication mechanism between the driver and theBSP. If the pointer contains a NULL value, the driver will use system defaultfunctions for the m82xxDpram DPRAM allocation and, obviously, the driver willnot support BSP function calls for heart beat errors, disconnect errors, andPHY status changes that are hardware specific.\cs    FUNCPTR miiPhyInit; BSP Mii/Phy Init Function    This function pointer is initialized by the BSP and call by the driver to    initialize the mii driver. The driver sets up it's phy settings and then    calls this routine. The BSP is responsible for setting BSP specific phy    parameters and then calling the miiPhyInit. The BSP is responsible to set    up any call to an interrupt. See miiPhyInt below.\ce\cs    FUNCPTR miiPhyInt; Driver Function for BSP to Call on a Phy Status Change    This function pointer is initialized by the driver and call by the BSP.    The BSP calls this function when it handles a hardware mii specific    interrupt. The driver initializes this to the function zxr10_motTsecPhyLSCInt.    The BSP may or may not choose to call this function. It will depend if the    BSP supports an interrupt driven PHY. The BSP can also set up the miiLib    driver to poll. In this case the miiPhy driver calls this function. See the    miiLib for details.    Note: Not calling this function when the phy duplex mode changes will    result in a duplex mis-match. This will cause TX errors in the driver    and a reduction in throughput.\ce\cs    FUNCPTR miiPhyBitRead; MII Bit Read Function    This function pointer is initialized by the BSP and call by the driver.    The driver calls this function when it needs to read a bit from the mii    interface. The mii interface is hardware specific.\ce\cs    FUNCPTR miiPhyBitWrite; MII Bit Write Function    This function pointer is initialized by the BSP and call by the driver.    The driver calls this function when it needs to write a bit to the mii    interface. This mii interface is hardware specific.\ce\cs