2011-05-21 07:18:55 +04:00
|
|
|
#
|
|
|
|
|
# Marvell device configuration
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
config NET_VENDOR_MARVELL
|
|
|
|
|
bool "Marvell devices"
|
2011-08-23 12:29:52 +04:00
|
|
|
default y
|
2016-11-17 22:19:13 +03:00
|
|
|
depends on PCI || CPU_PXA168 || MV64X60 || PPC32 || PLAT_ORION || INET || COMPILE_TEST
|
2011-05-21 07:18:55 +04:00
|
|
|
---help---
|
2015-06-21 23:28:02 +03:00
|
|
|
If you have a network (Ethernet) card belonging to this class, say Y.
|
2011-05-21 07:18:55 +04:00
|
|
|
|
|
|
|
|
Note that the answer to this question doesn't directly affect the
|
|
|
|
|
kernel: saying N will just cause the configurator to skip all
|
|
|
|
|
the questions about Marvell devices. If you say Y, you will be
|
|
|
|
|
asked for your specific card in the following questions.
|
|
|
|
|
|
|
|
|
|
if NET_VENDOR_MARVELL
|
|
|
|
|
|
|
|
|
|
config MV643XX_ETH
|
|
|
|
|
tristate "Marvell Discovery (643XX) and Orion ethernet support"
|
2016-11-17 22:19:13 +03:00
|
|
|
depends on (MV64X60 || PPC32 || PLAT_ORION || COMPILE_TEST) && INET
|
|
|
|
|
depends on HAS_DMA
|
2011-05-21 07:18:55 +04:00
|
|
|
select PHYLIB
|
2013-03-22 07:39:28 +04:00
|
|
|
select MVMDIO
|
2011-05-21 07:18:55 +04:00
|
|
|
---help---
|
|
|
|
|
This driver supports the gigabit ethernet MACs in the
|
|
|
|
|
Marvell Discovery PPC/MIPS chipset family (MV643XX) and
|
|
|
|
|
in the Marvell Orion ARM SoC family.
|
|
|
|
|
|
|
|
|
|
Some boards that use the Discovery chipset are the Momenco
|
|
|
|
|
Ocelot C and Jaguar ATX and Pegasos II.
|
|
|
|
|
|
2012-11-12 20:03:47 +04:00
|
|
|
config MVMDIO
|
|
|
|
|
tristate "Marvell MDIO interface support"
|
2014-01-14 19:45:43 +04:00
|
|
|
depends on HAS_IOMEM
|
net: mvmdio: add select PHYLIB
The mvmdio driver uses the phylib API, so it should select the PHYLIB
symbol, otherwise, a build with mvmdio (but without mvneta) fails to
build with undefined symbols such as mdiobus_unregister, mdiobus_free,
etc.
The mvneta driver does not use the phylib API directly, so it does not
need to select PHYLIB. It already selects the mvmdio driver anyway.
Historically, this problem is due to the fact that the PHY handling
was originally part of mvneta, and was later moved to a separate
driver, without updating the Kconfig select statements
accordingly. And since there was no functional reason to use mvmdio
without mvneta, this case was not tested.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-13 10:18:56 +04:00
|
|
|
select PHYLIB
|
2012-11-12 20:03:47 +04:00
|
|
|
---help---
|
|
|
|
|
This driver supports the MDIO interface found in the network
|
|
|
|
|
interface units of the Marvell EBU SoCs (Kirkwood, Orion5x,
|
|
|
|
|
Dove, Armada 370 and Armada XP).
|
|
|
|
|
|
2013-03-22 07:39:28 +04:00
|
|
|
This driver is used by the MV643XX_ETH and MVNETA drivers.
|
2012-11-12 20:03:47 +04:00
|
|
|
|
2016-03-16 00:47:14 +03:00
|
|
|
config MVNETA_BM_ENABLE
|
net: mvneta: bm: add support for hardware buffer management
Buffer manager (BM) is a dedicated hardware unit that can be used by all
ethernet ports of Armada XP and 38x SoC's. It allows to offload CPU on RX
path by sparing DRAM access on refilling buffer pool, hardware-based
filling of descriptor ring data and better memory utilization due to HW
arbitration for using 'short' pools for small packets.
Tests performed with A388 SoC working as a network bridge between two
packet generators showed increase of maximum processed 64B packets by
~20k (~555k packets with BM enabled vs ~535 packets without BM). Also
when pushing 1500B-packets with a line rate achieved, CPU load decreased
from around 25% without BM to 20% with BM.
BM comprise up to 4 buffer pointers' (BP) rings kept in DRAM, which
are called external BP pools - BPPE. Allocating and releasing buffer
pointers (BP) to/from BPPE is performed indirectly by write/read access
to a dedicated internal SRAM, where internal BP pools (BPPI) are placed.
BM hardware controls status of BPPE automatically, as well as assigning
proper buffers to RX descriptors. For more details please refer to
Functional Specification of Armada XP or 38x SoC.
In order to enable support for a separate hardware block, common for all
ports, a new driver has to be implemented ('mvneta_bm'). It provides
initialization sequence of address space, clocks, registers, SRAM,
empty pools' structures and also obtaining optional configuration
from DT (please refer to device tree binding documentation). mvneta_bm
exposes also a necessary API to mvneta driver, as well as a dedicated
structure with BM information (bm_priv), whose presence is used as a
flag notifying of BM usage by port. It has to be ensured that mvneta_bm
probe is executed prior to the ones in ports' driver. In case BM is not
used or its probe fails, mvneta falls back to use software buffer
management.
A sequence executed in mvneta_probe function is modified in order to have
an access to needed resources before possible port's BM initialization is
done. According to port-pools mapping provided by DT appropriate registers
are configured and the buffer pools are filled. RX path is modified
accordingly. Becaues the hardware allows a wide variety of configuration
options, following assumptions are made:
* using BM mechanisms can be selectively disabled/enabled basing
on DT configuration among the ports
* 'long' pool's single buffer size is tied to port's MTU
* using 'long' pool by port is obligatory and it cannot be shared
* using 'short' pool for smaller packets is optional
* one 'short' pool can be shared among all ports
This commit enables hardware buffer management operation cooperating with
existing mvneta driver. New device tree binding documentation is added and
the one of mvneta is updated accordingly.
[gregory.clement@free-electrons.com: removed the suspend/resume part]
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-14 11:39:03 +03:00
|
|
|
tristate "Marvell Armada 38x/XP network interface BM support"
|
|
|
|
|
depends on MVNETA
|
2016-12-01 20:03:08 +03:00
|
|
|
depends on !64BIT
|
net: mvneta: bm: add support for hardware buffer management
Buffer manager (BM) is a dedicated hardware unit that can be used by all
ethernet ports of Armada XP and 38x SoC's. It allows to offload CPU on RX
path by sparing DRAM access on refilling buffer pool, hardware-based
filling of descriptor ring data and better memory utilization due to HW
arbitration for using 'short' pools for small packets.
Tests performed with A388 SoC working as a network bridge between two
packet generators showed increase of maximum processed 64B packets by
~20k (~555k packets with BM enabled vs ~535 packets without BM). Also
when pushing 1500B-packets with a line rate achieved, CPU load decreased
from around 25% without BM to 20% with BM.
BM comprise up to 4 buffer pointers' (BP) rings kept in DRAM, which
are called external BP pools - BPPE. Allocating and releasing buffer
pointers (BP) to/from BPPE is performed indirectly by write/read access
to a dedicated internal SRAM, where internal BP pools (BPPI) are placed.
BM hardware controls status of BPPE automatically, as well as assigning
proper buffers to RX descriptors. For more details please refer to
Functional Specification of Armada XP or 38x SoC.
In order to enable support for a separate hardware block, common for all
ports, a new driver has to be implemented ('mvneta_bm'). It provides
initialization sequence of address space, clocks, registers, SRAM,
empty pools' structures and also obtaining optional configuration
from DT (please refer to device tree binding documentation). mvneta_bm
exposes also a necessary API to mvneta driver, as well as a dedicated
structure with BM information (bm_priv), whose presence is used as a
flag notifying of BM usage by port. It has to be ensured that mvneta_bm
probe is executed prior to the ones in ports' driver. In case BM is not
used or its probe fails, mvneta falls back to use software buffer
management.
A sequence executed in mvneta_probe function is modified in order to have
an access to needed resources before possible port's BM initialization is
done. According to port-pools mapping provided by DT appropriate registers
are configured and the buffer pools are filled. RX path is modified
accordingly. Becaues the hardware allows a wide variety of configuration
options, following assumptions are made:
* using BM mechanisms can be selectively disabled/enabled basing
on DT configuration among the ports
* 'long' pool's single buffer size is tied to port's MTU
* using 'long' pool by port is obligatory and it cannot be shared
* using 'short' pool for smaller packets is optional
* one 'short' pool can be shared among all ports
This commit enables hardware buffer management operation cooperating with
existing mvneta driver. New device tree binding documentation is added and
the one of mvneta is updated accordingly.
[gregory.clement@free-electrons.com: removed the suspend/resume part]
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-14 11:39:03 +03:00
|
|
|
---help---
|
|
|
|
|
This driver supports auxiliary block of the network
|
|
|
|
|
interface units in the Marvell ARMADA XP and ARMADA 38x SoC
|
|
|
|
|
family, which is called buffer manager.
|
|
|
|
|
|
|
|
|
|
This driver, when enabled, strictly cooperates with mvneta
|
|
|
|
|
driver and is common for all network ports of the devices,
|
|
|
|
|
even for Armada 370 SoC, which doesn't support hardware
|
|
|
|
|
buffer management.
|
|
|
|
|
|
net: mvneta: driver for Marvell Armada 370/XP network unit
This patch contains a new network driver for the network unit of the
ARM Marvell Armada 370 and the Armada XP. Both SoCs use the PJ4B
processor, a Marvell-developed ARM core that implements the ARMv7
instruction set.
Compared to previous ARM Marvell SoCs (Kirkwood, Orion, Discovery),
the network unit in Armada 370 and Armada XP is highly different. This
is the reason why this new 'mvneta' driver is needed, while the older
ARM Marvell SoCs use the 'mv643xx_eth' driver.
Here is an overview of the most important hardware changes that
require a new, specific, driver for the network unit of Armada 370/XP:
- The new network unit has a completely different design and layout
for the RX and TX descriptors. They are now organized as a simple
array (each RX and TX queue has base address and size of this
array) rather than a linked list as in the old SoCs.
- The new network unit has a different RXQ and TXQ management: this
management is done using special read/write counter registers,
while in the Old SocS, it was done using the Ownership bit in RX
and TX descriptors.
- The new network unit has different interrupt registers
- The new network unit way of cleaning of interrupts is not done by
writing to the cause register, but by updating per-queue counters
- The new network unit has different GMAC registers (link, speed,
duplex configuration) and different WRR registers.
- The new network unit has lots of new units like PnC (Parser and
Classifier), PMT, BM (Memory Buffer Management), xPON, and more.
The driver proposed in the current patch only handles the basic
features. Additional hardware features will progressively be supported
as needed.
This code has originally been written by Rami Rosen
<rosenr@marvell.com>, and then reviewed and cleaned up by Thomas
Petazzoni <thomas.petazzoni@free-electrons.com>.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: David S. Miller <davem@davemloft.net>
2012-08-17 15:04:28 +04:00
|
|
|
config MVNETA
|
2014-02-18 17:18:11 +04:00
|
|
|
tristate "Marvell Armada 370/38x/XP network interface support"
|
2016-11-17 22:19:13 +03:00
|
|
|
depends on PLAT_ORION || COMPILE_TEST
|
|
|
|
|
depends on HAS_DMA
|
net: mvneta: driver for Marvell Armada 370/XP network unit
This patch contains a new network driver for the network unit of the
ARM Marvell Armada 370 and the Armada XP. Both SoCs use the PJ4B
processor, a Marvell-developed ARM core that implements the ARMv7
instruction set.
Compared to previous ARM Marvell SoCs (Kirkwood, Orion, Discovery),
the network unit in Armada 370 and Armada XP is highly different. This
is the reason why this new 'mvneta' driver is needed, while the older
ARM Marvell SoCs use the 'mv643xx_eth' driver.
Here is an overview of the most important hardware changes that
require a new, specific, driver for the network unit of Armada 370/XP:
- The new network unit has a completely different design and layout
for the RX and TX descriptors. They are now organized as a simple
array (each RX and TX queue has base address and size of this
array) rather than a linked list as in the old SoCs.
- The new network unit has a different RXQ and TXQ management: this
management is done using special read/write counter registers,
while in the Old SocS, it was done using the Ownership bit in RX
and TX descriptors.
- The new network unit has different interrupt registers
- The new network unit way of cleaning of interrupts is not done by
writing to the cause register, but by updating per-queue counters
- The new network unit has different GMAC registers (link, speed,
duplex configuration) and different WRR registers.
- The new network unit has lots of new units like PnC (Parser and
Classifier), PMT, BM (Memory Buffer Management), xPON, and more.
The driver proposed in the current patch only handles the basic
features. Additional hardware features will progressively be supported
as needed.
This code has originally been written by Rami Rosen
<rosenr@marvell.com>, and then reviewed and cleaned up by Thomas
Petazzoni <thomas.petazzoni@free-electrons.com>.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: David S. Miller <davem@davemloft.net>
2012-08-17 15:04:28 +04:00
|
|
|
select MVMDIO
|
2015-11-09 17:08:57 +03:00
|
|
|
select FIXED_PHY
|
net: mvneta: driver for Marvell Armada 370/XP network unit
This patch contains a new network driver for the network unit of the
ARM Marvell Armada 370 and the Armada XP. Both SoCs use the PJ4B
processor, a Marvell-developed ARM core that implements the ARMv7
instruction set.
Compared to previous ARM Marvell SoCs (Kirkwood, Orion, Discovery),
the network unit in Armada 370 and Armada XP is highly different. This
is the reason why this new 'mvneta' driver is needed, while the older
ARM Marvell SoCs use the 'mv643xx_eth' driver.
Here is an overview of the most important hardware changes that
require a new, specific, driver for the network unit of Armada 370/XP:
- The new network unit has a completely different design and layout
for the RX and TX descriptors. They are now organized as a simple
array (each RX and TX queue has base address and size of this
array) rather than a linked list as in the old SoCs.
- The new network unit has a different RXQ and TXQ management: this
management is done using special read/write counter registers,
while in the Old SocS, it was done using the Ownership bit in RX
and TX descriptors.
- The new network unit has different interrupt registers
- The new network unit way of cleaning of interrupts is not done by
writing to the cause register, but by updating per-queue counters
- The new network unit has different GMAC registers (link, speed,
duplex configuration) and different WRR registers.
- The new network unit has lots of new units like PnC (Parser and
Classifier), PMT, BM (Memory Buffer Management), xPON, and more.
The driver proposed in the current patch only handles the basic
features. Additional hardware features will progressively be supported
as needed.
This code has originally been written by Rami Rosen
<rosenr@marvell.com>, and then reviewed and cleaned up by Thomas
Petazzoni <thomas.petazzoni@free-electrons.com>.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: David S. Miller <davem@davemloft.net>
2012-08-17 15:04:28 +04:00
|
|
|
---help---
|
|
|
|
|
This driver supports the network interface units in the
|
2014-02-18 17:18:11 +04:00
|
|
|
Marvell ARMADA XP, ARMADA 370 and ARMADA 38x SoC family.
|
net: mvneta: driver for Marvell Armada 370/XP network unit
This patch contains a new network driver for the network unit of the
ARM Marvell Armada 370 and the Armada XP. Both SoCs use the PJ4B
processor, a Marvell-developed ARM core that implements the ARMv7
instruction set.
Compared to previous ARM Marvell SoCs (Kirkwood, Orion, Discovery),
the network unit in Armada 370 and Armada XP is highly different. This
is the reason why this new 'mvneta' driver is needed, while the older
ARM Marvell SoCs use the 'mv643xx_eth' driver.
Here is an overview of the most important hardware changes that
require a new, specific, driver for the network unit of Armada 370/XP:
- The new network unit has a completely different design and layout
for the RX and TX descriptors. They are now organized as a simple
array (each RX and TX queue has base address and size of this
array) rather than a linked list as in the old SoCs.
- The new network unit has a different RXQ and TXQ management: this
management is done using special read/write counter registers,
while in the Old SocS, it was done using the Ownership bit in RX
and TX descriptors.
- The new network unit has different interrupt registers
- The new network unit way of cleaning of interrupts is not done by
writing to the cause register, but by updating per-queue counters
- The new network unit has different GMAC registers (link, speed,
duplex configuration) and different WRR registers.
- The new network unit has lots of new units like PnC (Parser and
Classifier), PMT, BM (Memory Buffer Management), xPON, and more.
The driver proposed in the current patch only handles the basic
features. Additional hardware features will progressively be supported
as needed.
This code has originally been written by Rami Rosen
<rosenr@marvell.com>, and then reviewed and cleaned up by Thomas
Petazzoni <thomas.petazzoni@free-electrons.com>.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: David S. Miller <davem@davemloft.net>
2012-08-17 15:04:28 +04:00
|
|
|
|
|
|
|
|
Note that this driver is distinct from the mv643xx_eth
|
|
|
|
|
driver, which should be used for the older Marvell SoCs
|
|
|
|
|
(Dove, Orion, Discovery, Kirkwood).
|
|
|
|
|
|
2016-03-16 00:47:14 +03:00
|
|
|
config MVNETA_BM
|
|
|
|
|
tristate
|
2016-12-01 20:03:08 +03:00
|
|
|
depends on !64BIT
|
2016-05-11 23:13:23 +03:00
|
|
|
default y if MVNETA=y && MVNETA_BM_ENABLE!=n
|
2016-03-16 00:47:14 +03:00
|
|
|
default MVNETA_BM_ENABLE
|
|
|
|
|
select HWBM
|
|
|
|
|
help
|
|
|
|
|
MVNETA_BM must not be 'm' if MVNETA=y, so this symbol ensures
|
|
|
|
|
that all dependencies are met.
|
|
|
|
|
|
2014-07-10 23:52:13 +04:00
|
|
|
config MVPP2
|
|
|
|
|
tristate "Marvell Armada 375 network interface support"
|
2016-11-17 22:19:13 +03:00
|
|
|
depends on MACH_ARMADA_375 || COMPILE_TEST
|
|
|
|
|
depends on HAS_DMA
|
2016-11-22 17:21:22 +03:00
|
|
|
depends on !64BIT
|
2014-07-10 23:52:13 +04:00
|
|
|
select MVMDIO
|
|
|
|
|
---help---
|
|
|
|
|
This driver supports the network interface units in the
|
|
|
|
|
Marvell ARMADA 375 SoC.
|
|
|
|
|
|
2011-05-21 07:18:55 +04:00
|
|
|
config PXA168_ETH
|
|
|
|
|
tristate "Marvell pxa168 ethernet support"
|
2014-10-09 18:15:42 +04:00
|
|
|
depends on HAS_IOMEM && HAS_DMA
|
|
|
|
|
depends on CPU_PXA168 || ARCH_BERLIN || COMPILE_TEST
|
2011-05-21 07:18:55 +04:00
|
|
|
select PHYLIB
|
|
|
|
|
---help---
|
|
|
|
|
This driver supports the pxa168 Ethernet ports.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here. The module
|
|
|
|
|
will be called pxa168_eth.
|
|
|
|
|
|
|
|
|
|
config SKGE
|
|
|
|
|
tristate "Marvell Yukon Gigabit Ethernet support"
|
|
|
|
|
depends on PCI
|
|
|
|
|
select CRC32
|
|
|
|
|
---help---
|
|
|
|
|
This driver support the Marvell Yukon or SysKonnect SK-98xx/SK-95xx
|
|
|
|
|
and related Gigabit Ethernet adapters. It is a new smaller driver
|
|
|
|
|
with better performance and more complete ethtool support.
|
|
|
|
|
|
|
|
|
|
It does not support the link failover and network management
|
|
|
|
|
features that "portable" vendor supplied sk98lin driver does.
|
|
|
|
|
|
|
|
|
|
This driver supports adapters based on the original Yukon chipset:
|
|
|
|
|
Marvell 88E8001, Belkin F5D5005, CNet GigaCard, DLink DGE-530T,
|
|
|
|
|
Linksys EG1032/EG1064, 3Com 3C940/3C940B, SysKonnect SK-9871/9872.
|
|
|
|
|
|
|
|
|
|
It does not support the newer Yukon2 chipset: a separate driver,
|
|
|
|
|
sky2, is provided for these adapters.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module
|
|
|
|
|
will be called skge. This is recommended.
|
|
|
|
|
|
|
|
|
|
config SKGE_DEBUG
|
|
|
|
|
bool "Debugging interface"
|
|
|
|
|
depends on SKGE && DEBUG_FS
|
|
|
|
|
---help---
|
|
|
|
|
This option adds the ability to dump driver state for debugging.
|
|
|
|
|
The file /sys/kernel/debug/skge/ethX displays the state of the internal
|
|
|
|
|
transmit and receive rings.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config SKGE_GENESIS
|
|
|
|
|
bool "Support for older SysKonnect Genesis boards"
|
|
|
|
|
depends on SKGE
|
|
|
|
|
---help---
|
|
|
|
|
This enables support for the older and uncommon SysKonnect Genesis
|
|
|
|
|
chips, which support MII via an external transceiver, instead of
|
|
|
|
|
an internal one. Disabling this option will save some memory
|
|
|
|
|
by making code smaller. If unsure say Y.
|
|
|
|
|
|
|
|
|
|
config SKY2
|
|
|
|
|
tristate "Marvell Yukon 2 support"
|
|
|
|
|
depends on PCI
|
|
|
|
|
select CRC32
|
|
|
|
|
---help---
|
|
|
|
|
This driver supports Gigabit Ethernet adapters based on the
|
|
|
|
|
Marvell Yukon 2 chipset:
|
|
|
|
|
Marvell 88E8021/88E8022/88E8035/88E8036/88E8038/88E8050/88E8052/
|
|
|
|
|
88E8053/88E8055/88E8061/88E8062, SysKonnect SK-9E21D/SK-9S21
|
|
|
|
|
|
|
|
|
|
There is companion driver for the older Marvell Yukon and
|
|
|
|
|
SysKonnect Genesis based adapters: skge.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module
|
|
|
|
|
will be called sky2. This is recommended.
|
|
|
|
|
|
|
|
|
|
config SKY2_DEBUG
|
|
|
|
|
bool "Debugging interface"
|
|
|
|
|
depends on SKY2 && DEBUG_FS
|
|
|
|
|
---help---
|
|
|
|
|
This option adds the ability to dump driver state for debugging.
|
|
|
|
|
The file /sys/kernel/debug/sky2/ethX displays the state of the internal
|
|
|
|
|
transmit and receive rings.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
endif # NET_VENDOR_MARVELL
|
