Adds an ET1011C PHY driver which is derived from the
Linux kernel PHY driver (drivers/net/phy/et1011c.c)
from the v3.9-rc2 tag. Note that an errata workaround
config option is implemented to allow for TX_CLK to be
enabled even when gigabit mode is negotiated. This
workaround is used on the PG1.0 TI814X EVM.
Signed-off-by: Matt Porter <mporter@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
TI814x's version 1 CPSW has a different slave_regs layout.
Add support for the differing registers.
Signed-off-by: Matt Porter <mporter@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
Avoid overwriting GEMx_RCLK_CTRL and GEMx_CLK_CTRL
if the Ethernet interface is connect on EMIO
Do not enable emio for this standard board configuration for now.
Signed-off-by: David Andrey <david.andrey@netmodule.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@ti.com>
Pass the PHY address to the driver init to
allow parallel use of both interfaces
Signed-off-by: David Andrey <david.andrey@netmodule.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@ti.com>
The whole driver used 100Mbps because of zc702 rev B.
Fix problem with not setup proper clock for gem1.
This is generic approach for clk setup.
Signed-off-by: Michal Simek <monstr@monstr.eu>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@ti.com>
BDs can be correctly setup just once and init function
performs only phy autodetection and enabling RX/TX.
RX/TX are disabled in halt function.
This patch solves the problem with repeatable tftp transfers.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@ti.com>
Removing this bit causes that frame is sent only once.
(With wrap big one packet has been sent several times
which dramatically decrease throughput)
TRM: (Table 16-3: Tx Buffer Descriptor Entry)
Signed-off-by: Michal Simek <monstr@monstr.eu>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@ti.com>
This phy is used on zedboard (xilinx zynq platform).
Signed-off-by: Michal Simek <monstr@monstr.eu>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@ti.com>
'bool' is defined in random places. This patch consolidates them into a
single header file include/linux/types.h, using stdbool.h introduced in C99.
All other #define, typedef and enum are removed. They are all consistent with
true = 1, false = 0.
Replace FALSE, False with false. Replace TRUE, True with true.
Skip *.py, *.php, lib/* files.
Signed-off-by: York Sun <yorksun@freescale.com>
- In arch/arm/cpu/armv7/omap-common/timer.c,
drivers/mtd/nand/omap_gpmc.c and drivers/net/cpsw.c add #include files
that the driver needs but had been relying on <config.h> to bring in.
- In arch/arm/cpu/armv7/omap-common/lowlevel_init.S add <config.h>
- In am335x_evm.h and pcm051.h don't globally include
<asm/arch/hardware.h> and <asm/arch/cpu.h> but just <asm/arch/omap.h>
as that is the only include which defines things the config uses.
Cc: Lars Poeschel <poeschel@lemonage.de>
Signed-off-by: Tom Rini <trini@ti.com>
In master we had already taken a patch to fix the davinci GPIO code for
CONFIG_SOC_DM646X and in u-boot-ti we have additional patches to support
DA830 (which is CONFIG_SOC_DA8XX && !CONFIG_SOC_DA850). Resolve these
conflicts manually and comment the #else/#endif lines for clarity.
Conflicts:
arch/arm/include/asm/arch-davinci/gpio.h
drivers/gpio/da8xx_gpio.c
Signed-off-by: Tom Rini <trini@ti.com>
Before submitting packets to cpdma, phy status is updated on every packet
which leads to delay in packet send intern reduces the Ethernet performance.
Checking mdio status for each packet will reduce timetaken to send a packet
and there by increasing the Ethernet performance. With this the performance
is increased from 208KiB/s to 375KiB/s on EVMsk
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
It is useful to be able to try a range of
possible phy addresses to connect.
Also, an ethernet device is not required
to use phy_find_by_mask leading to better
separation of mii vs ethernet, as suggested
by Andy Fleming.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Only the hardware ethernet registers are needed
for this function, so don't pass the more general
structure. I'm trying to separate MII and fec.
This also fixes MX28 fec_mii_setspeed use on secondary ethernet port
This was found by inspection of the code and should be
checked on real hardware.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
It is more logical to test for CONFIG_FEC_MXC_PHYADDR
to determine whether to define the function fecmxc_initialize.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
SH7752 has two fast ethernet controllers and two gigabit ethernet
controllers. It is similar to SH7757.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Marvell 88E1118R has different uid then 88E1118.
Signed-off-by: Michal Simek <monstr@monstr.eu>
CC: Andy Fleming <afleming@freescale.com>
CC: Zang Roy-R61911 <tie-fei.zang@freescale.com>
CC: Kumar Gala <galak@kernel.crashing.org>
In e1000e driver, Rx descriptor queue is used such that hardware can add only
one descriptor at a time. So the WTHRESH granularity in RXDCTL should be set
to single descriptor. This would ensure that every time controller fills a Rx
descriptor, it is flushed to host memory. Earlier this granularity was in
cache line units i.e 2 descriptors. This leads to controller always waiting
for 2 descriptors before flushing them out. But since not more than one Rx BD
is actually available , the accumulation condition never gets hit.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
Signed-off-by: Vakul Garg <vakul@freescale.com>
Acked-by: Roy Zang <tie-fei.zang@freescale.com>
The P5040DS reference board (a.k.a "Superhydra") is an enhanced version of
P3041DS/P5020DS ("Hydra") reference board.
Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
phy.c:46:5: warning: symbol 'genphy_config_advert' was not declared. Should it be static?
phy.c:121:5: warning: symbol 'genphy_setup_forced' was not declared. Should it be static?
phy.c:468:5: warning: symbol 'phy_probe' was not declared. Should it be static?
phy.c:491:19: warning: symbol 'get_phy_driver' was not declared. Should it be static?
phy.c:508:19: warning: symbol 'phy_device_create' was not declared. Should it be static?
phy.c:552:5: warning: symbol 'get_phy_id' was not declared. Should it be static?
phy.c:584:19: warning: symbol 'get_phy_device' was not declared. Should it be sta
vitesse.c:126:5: warning: symbol 'vsc8601_config' was not declared. Should it be static?
vsc7385.c:33:5: warning: symbol 'vsc7385_upload_firmware' was not declared. Should it be static?
tgec_phy.c:33:5: warning: symbol 'tgec_mdio_write' was not declared. Should it be static?
tgec_phy.c:75:5: warning: symbol 'tgec_mdio_read' was not declared. Should it be static?
tgec_phy.c:117:5: warning: symbol 'tgec_mdio_reset' was not declared. Should it be static?
eth.c:48:6: warning: symbol 'dtsec_configure_serdes' was not declared. Should it be static?
p4080.c:26:5: warning: symbol 'port_to_devdisr' was not declared. Should it be static?
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
bootp.c:44:14: warning: symbol 'dhcp_state' was not declared. Should it be static?
bootp.c:45:15: warning: symbol 'dhcp_leasetime' was not declared. Should it be static?
bootp.c:46:10: warning: symbol 'NetDHCPServerIP' was not declared. Should it be static?
arp.c:30:17: warning: symbol 'NetArpWaitReplyIP' was not declared. Should it be static?
arp.c:37:16: warning: symbol 'NetArpTxPacket' was not declared. Should it be static?
arp.c:38:17: warning: symbol 'NetArpPacketBuf' was not declared. Should it be static?
atheros.c:33:19: warning: symbol 'AR8021_driver' was not declared. Should it be static?
net.c:183:7: warning: symbol 'PktBuf' was not declared. Should it be static?
net.c:159:21: warning: symbol 'net_state' was not declared. Should it be static?
ping.c:73:6: warning: symbol 'ping_start' was not declared. Should it be static?
ping.c:82:13: warning: symbol 'ping_receive' was not declared. Should it be static?
tftp.c:53:7: warning: symbol 'TftpRRQTimeoutMSecs' was not declared. Should it be static?
tftp.c:54:5: warning: symbol 'TftpRRQTimeoutCountMax' was not declared. Should it be static?
eth.c:125:19: warning: symbol 'eth_current' was not declared. Should it be static?
Note: in the ping.c fix, commit a36b12f95a
"net: Move PING out of net.c" mistakenly carried the ifdef CMD_PING
clause from when it was necessary to avoid warnings when it was embedded
in net.c.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
u-boot's byteorder headers did not contain endianness attributions
for use with sparse, causing a lot of false positives. Import the
kernel's latest definitions, and enable them by including compiler.h
and types.h. They come with 'const' added for some swab functions, so
fix those up, too:
include/linux/byteorder/big_endian.h:46:2: warning: passing argument 1 of '__swab64p' discards 'const' qualifier from pointer target type [enabled by default]
Also, note: u-boot's historic __BYTE_ORDER definition has been
preserved (for the time being at least).
We also remove ad-hoc barrier() definitions, since we're including
compiler.h in files that hadn't in the past:
macb.c:54:0: warning: "barrier" redefined [enabled by default]
In addition, including compiler.h in byteorder changes the 'noinline'
definition to expand to __attribute__((noinline)). This fixes
arch/powerpc/lib/bootm.c:
bootm.c:329:16: error: attribute '__attribute__': unknown attribute
bootm.c:329:16: error: expected ')' before '__attribute__'
bootm.c:329:25: error: expected identifier or '(' before ')' token
powerpc sparse builds yield:
include/common.h:356:22: error: marked inline, but without a definition
the unknown-reason inlining without a definition is considered obsolete
given it was part of the 2002 initial commit, and no arm version was
'fixed.'
also fixed:
ydirectenv.h:60:0: warning: "inline" redefined [enabled by default]
and:
Configuring for devconcenter - Board: intip, Options: DEVCONCENTER
make[1]: *** [4xx_ibm_ddr2_autocalib.o] Error 1
make: *** [arch/powerpc/cpu/ppc4xx/libppc4xx.o] Error 2
powerpc-fsl-linux-size: './u-boot': No such file
4xx_ibm_ddr2_autocalib.c: In function 'DQS_autocalibration':
include/asm/ppc4xx-sdram.h:1407:13: sorry, unimplemented: inlining failed in call to 'ppc4xx_ibm_ddr2_register_dump': function body not available
4xx_ibm_ddr2_autocalib.c:1243:32: sorry, unimplemented: called from here
and:
In file included from crc32.c:50:0:
crc32table.h:4:1: warning: implicit declaration of function '___constant_swab32' [-Wimplicit-function-declaration]
crc32table.h:4:1: error: initializer element is not constant
crc32table.h:4:1: error: (near initialization for 'crc32table_le[0]')
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
[trini: Remove '#endif' in include/common.h around setenv portion]
Signed-off-by: Tom Rini <trini@ti.com>
TBI PHY address (TBIPA) register is set in general frame manager
phy init funciton dtsec_init_phy() in drivers/net/fm/eth.c, and
it is supposed to set TBIPA on FM1@DTSEC1 in case of FM1@DTSEC1
isn't used directly, which provides MDIO for other ports. So
following code is wrong in case of FM2, which has a different
mac base.
struct dtsec *regs = (struct dtsec *)fm_eth->mac->base;
/* Assign a Physical address to the TBI */
out_be32(®s->tbipa, CONFIG_SYS_TBIPA_VALUE);
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
The multirate ethernet media access controller (mEMAC) interfaces to
10Gbps and below Ethernet/IEEE 802.3 networks via either RGMII/RMII
interfaces or XAUI/XFI/SGMII/QSGMII using the high-speed SerDes interface.
Signed-off-by: Sandeep Singh <Sandeep@freescale.com>
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Add support for Freescale B4860 and variant SoCs. Features of B4860 are
(incomplete list):
Six fully-programmable StarCore SC3900 FVP subsystems, divided into three
clusters-each core runs up to 1.2 GHz, with an architecture highly
optimized for wireless base station applications
Four dual-thread e6500 Power Architecture processors organized in one
cluster-each core runs up to 1.8 GHz
Two DDR3/3L controllers for high-speed, industry-standard memory interface
each runs at up to 1866.67 MHz
MAPLE-B3 hardware acceleration-for forward error correction schemes
including Turbo or Viterbi decoding, Turbo encoding and rate matching,
MIMO MMSE equalization scheme, matrix operations, CRC insertion and
check, DFT/iDFT and FFT/iFFT calculations, PUSCH/PDSCH acceleration,
and UMTS chip rate acceleration
CoreNet fabric that fully supports coherency using MESI protocol between
the e6500 cores, SC3900 FVP cores, memories and external interfaces.
CoreNet fabric interconnect runs at 667 MHz and supports coherent and
non-coherent out of order transactions with prioritization and
bandwidth allocation amongst CoreNet endpoints.
Data Path Acceleration Architecture, which includes the following:
Frame Manager (FMan), which supports in-line packet parsing and general
classification to enable policing and QoS-based packet distribution
Queue Manager (QMan) and Buffer Manager (BMan), which allow offloading
of queue management, task management, load distribution, flow ordering,
buffer management, and allocation tasks from the cores
Security engine (SEC 5.3)-crypto-acceleration for protocols such as
IPsec, SSL, and 802.16
RapidIO manager (RMAN) - Support SRIO types 8, 9, 10, and 11 (inbound and
outbound). Supports types 5, 6 (outbound only)
Large internal cache memory with snooping and stashing capabilities for
bandwidth saving and high utilization of processor elements. The
9856-Kbyte internal memory space includes the following:
32 Kbyte L1 ICache per e6500/SC3900 core
32 Kbyte L1 DCache per e6500/SC3900 core
2048 Kbyte unified L2 cache for each SC3900 FVP cluster
2048 Kbyte unified L2 cache for the e6500 cluster
Two 512 Kbyte shared L3 CoreNet platform caches (CPC)
Sixteen 10-GHz SerDes lanes serving:
Two Serial RapidIO interfaces. Each supports up to 4 lanes and a total
of up to 8 lanes
Up to 8-lanes Common Public Radio Interface (CPRI) controller for glue-
less antenna connection
Two 10-Gbit Ethernet controllers (10GEC)
Six 1G/2.5-Gbit Ethernet controllers for network communications
PCI Express controller
Debug (Aurora)
Two OCeaN DMAs
Various system peripherals
182 32-bit timers
Signed-off-by: York Sun <yorksun@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Add support for Freescale T4240 SoC. Feature of T4240 are
(incomplete list):
12 dual-threaded e6500 cores built on Power Architecture® technology
Arranged as clusters of four cores sharing a 2 MB L2 cache.
Up to 1.8 GHz at 1.0 V with 64-bit ISA support (Power Architecture
v2.06-compliant)
Three levels of instruction: user, supervisor, and hypervisor
1.5 MB CoreNet Platform Cache (CPC)
Hierarchical interconnect fabric
CoreNet fabric supporting coherent and non-coherent transactions with
prioritization and bandwidth allocation amongst CoreNet end-points
1.6 Tbps coherent read bandwidth
Queue Manager (QMan) fabric supporting packet-level queue management and
quality of service scheduling
Three 64-bit DDR3/3L SDRAM memory controllers with ECC and interleaving
support
Memory prefetch engine (PMan)
Data Path Acceleration Architecture (DPAA) incorporating acceleration for
the following functions:
Packet parsing, classification, and distribution (Frame Manager 1.1)
Queue management for scheduling, packet sequencing, and congestion
management (Queue Manager 1.1)
Hardware buffer management for buffer allocation and de-allocation
(BMan 1.1)
Cryptography acceleration (SEC 5.0) at up to 40 Gbps
RegEx Pattern Matching Acceleration (PME 2.1) at up to 10 Gbps
Decompression/Compression Acceleration (DCE 1.0) at up to 20 Gbps
DPAA chip-to-chip interconnect via RapidIO Message Manager (RMAN 1.0)
32 SerDes lanes at up to 10.3125 GHz
Ethernet interfaces
Up to four 10 Gbps Ethernet MACs
Up to sixteen 1 Gbps Ethernet MACs
Maximum configuration of 4 x 10 GE + 8 x 1 GE
High-speed peripheral interfaces
Four PCI Express 2.0/3.0 controllers
Two Serial RapidIO 2.0 controllers/ports running at up to 5 GHz with
Type 11 messaging and Type 9 data streaming support
Interlaken look-aside interface for serial TCAM connection
Additional peripheral interfaces
Two serial ATA (SATA 2.0) controllers
Two high-speed USB 2.0 controllers with integrated PHY
Enhanced secure digital host controller (SD/MMC/eMMC)
Enhanced serial peripheral interface (eSPI)
Four I2C controllers
Four 2-pin or two 4-pin UARTs
Integrated Flash controller supporting NAND and NOR flash
Two eight-channel DMA engines
Support for hardware virtualization and partitioning enforcement
QorIQ Platform's Trust Architecture 1.1
Signed-off-by: York Sun <yorksun@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
The following warning was produced, fix it:
mcfmii.c: In function 'mcffec_miiphy_write':
mcfmii.c:318:8: warning: variable 'rdreg' set but not used [-Wunused-but-set-variable]
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: "Jin Zhengxiong-R64188" <R64188@freescale.com>
Cc: Jason Jin <jason.jin@freescale.com>
As the board seems to be unmaintained for some time, lets remove
the support in mainline completely.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: James MacAulay <james.macaulay@amirix.com>
Acked-by: Marek Vasut <marex@denx.de>
The mechanism waiting for transmission to finish in fec_send() now
relies on the E-bit being cleared in the TX buffer descriptor. In
case of data cache being on, this means invalidation of data cache
above this TX buffer descriptor on each test for the E-bit being
cleared.
Apparently, there is another way to check if the transmission did
complete. This is by checking the TDAR bit in the X_DES_ACTIVE
register. Reading a register does not need any data cache invalidation,
which is beneficial.
Rework the sequence that wait for completion of the transmission so that
the TDAR bit is tested first and afterwards check the E-bit being clear.
This cuts down the number of cache invalidation calls to one.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Stefano Babic <sbabic@denx.de>
The FEC hardware sometimes errors out on data transfer and hangs in
the tightloop adjusted by this patch. So add timeout into the tightloop
to make such a hang recoverable.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Stefano Babic <sbabic@denx.de>
Align the address that's to be invalidated/flushed properly.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Benoit Thebaudeau <benoit.thebaudeau@advans>
Cc: Eric Nelson <eric.nelson@boundarydevices.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
