[PATCH] intel ixp2000 network driver
The way the hardware and firmware work is that there is one shared RX
queue and IRQ for a number of different network interfaces. Due to this,
we would like to process received packets for every interface in the same
NAPI poll handler, so we need a pseudo-device to schedule polling on.
What the driver currently does is that it always schedules polling for
the first network interface in the list, and processes packets for every
interface in the poll handler for that first interface -- however, this
scheme breaks down if the first network interface happens to not be up,
since netif_rx_schedule_prep() checks netif_running().
sky2 apparently has the same issue, and Stephen Hemminger suggested a
way to work around this: create a variant of netif_rx_schedule_prep()
that does not check netif_running(). I implemented this locally and
called it netif_rx_schedule_prep_notup(), and it seems to work well,
but it's something that probably not everyone would be happy with.
The ixp2000 is an ARM CPU with a high-speed network interface in the
CPU itself (full duplex 4Gb/s or 10Gb/s depending on the IXP model.)
The CPU package also contains 8 or 16 (again depending on the IXP
model) 'microengines', which are somewhat primitive but very fast
and efficient processor cores which can be used to offload various
things from the main CPU.
This driver makes the high-speed network interface in the CPU visible
and usable as a regular linux network device. Currently, it only
supports the Radisys ENP2611 IXP board, but adding support for other
board types should be fairly easy.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-11-11 12:23:13 -05:00
|
|
|
/*
|
|
|
|
|
* IXP2400 MSF network device driver for the Radisys ENP2611
|
|
|
|
|
* Copyright (C) 2004, 2005 Lennert Buytenhek <buytenh@wantstofly.org>
|
|
|
|
|
* Dedicated to Marija Kulikova.
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
|
#include <linux/netdevice.h>
|
|
|
|
|
#include <linux/etherdevice.h>
|
|
|
|
|
#include <linux/init.h>
|
|
|
|
|
#include <linux/moduleparam.h>
|
2006-03-20 12:10:17 -05:00
|
|
|
#include <asm/hardware/uengine.h>
|
[PATCH] intel ixp2000 network driver
The way the hardware and firmware work is that there is one shared RX
queue and IRQ for a number of different network interfaces. Due to this,
we would like to process received packets for every interface in the same
NAPI poll handler, so we need a pseudo-device to schedule polling on.
What the driver currently does is that it always schedules polling for
the first network interface in the list, and processes packets for every
interface in the poll handler for that first interface -- however, this
scheme breaks down if the first network interface happens to not be up,
since netif_rx_schedule_prep() checks netif_running().
sky2 apparently has the same issue, and Stephen Hemminger suggested a
way to work around this: create a variant of netif_rx_schedule_prep()
that does not check netif_running(). I implemented this locally and
called it netif_rx_schedule_prep_notup(), and it seems to work well,
but it's something that probably not everyone would be happy with.
The ixp2000 is an ARM CPU with a high-speed network interface in the
CPU itself (full duplex 4Gb/s or 10Gb/s depending on the IXP model.)
The CPU package also contains 8 or 16 (again depending on the IXP
model) 'microengines', which are somewhat primitive but very fast
and efficient processor cores which can be used to offload various
things from the main CPU.
This driver makes the high-speed network interface in the CPU visible
and usable as a regular linux network device. Currently, it only
supports the Radisys ENP2611 IXP board, but adding support for other
board types should be fairly easy.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-11-11 12:23:13 -05:00
|
|
|
#include <asm/mach-types.h>
|
|
|
|
|
#include <asm/io.h>
|
|
|
|
|
#include "ixpdev.h"
|
|
|
|
|
#include "caleb.h"
|
|
|
|
|
#include "ixp2400-msf.h"
|
|
|
|
|
#include "pm3386.h"
|
|
|
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
|
* The Radisys ENP2611 is a PCI form factor board with three SFP GBIC
|
|
|
|
|
* slots, connected via two PMC/Sierra 3386s and an SPI-3 bridge FPGA
|
|
|
|
|
* to the IXP2400.
|
|
|
|
|
*
|
|
|
|
|
* +-------------+
|
|
|
|
|
* SFP GBIC #0 ---+ | +---------+
|
|
|
|
|
* | PM3386 #0 +-------+ |
|
|
|
|
|
* SFP GBIC #1 ---+ | | "Caleb" | +---------+
|
|
|
|
|
* +-------------+ | | | |
|
|
|
|
|
* | SPI-3 +---------+ IXP2400 |
|
|
|
|
|
* +-------------+ | bridge | | |
|
|
|
|
|
* SFP GBIC #2 ---+ | | FPGA | +---------+
|
|
|
|
|
* | PM3386 #1 +-------+ |
|
|
|
|
|
* | | +---------+
|
|
|
|
|
* +-------------+
|
|
|
|
|
* ^ ^ ^
|
|
|
|
|
* | 1.25Gbaud | 104MHz | 104MHz
|
|
|
|
|
* | SERDES ea. | SPI-3 ea. | SPI-3
|
|
|
|
|
*
|
|
|
|
|
***********************************************************************/
|
|
|
|
|
static struct ixp2400_msf_parameters enp2611_msf_parameters =
|
|
|
|
|
{
|
|
|
|
|
.rx_mode = IXP2400_RX_MODE_UTOPIA_POS |
|
|
|
|
|
IXP2400_RX_MODE_1x32 |
|
|
|
|
|
IXP2400_RX_MODE_MPHY |
|
|
|
|
|
IXP2400_RX_MODE_MPHY_32 |
|
|
|
|
|
IXP2400_RX_MODE_MPHY_POLLED_STATUS |
|
|
|
|
|
IXP2400_RX_MODE_MPHY_LEVEL3 |
|
|
|
|
|
IXP2400_RX_MODE_RBUF_SIZE_64,
|
|
|
|
|
|
|
|
|
|
.rxclk01_multiplier = IXP2400_PLL_MULTIPLIER_16,
|
|
|
|
|
|
|
|
|
|
.rx_poll_ports = 3,
|
|
|
|
|
|
|
|
|
|
.rx_channel_mode = {
|
|
|
|
|
IXP2400_PORT_RX_MODE_MASTER |
|
|
|
|
|
IXP2400_PORT_RX_MODE_POS_PHY |
|
|
|
|
|
IXP2400_PORT_RX_MODE_POS_PHY_L3 |
|
|
|
|
|
IXP2400_PORT_RX_MODE_ODD_PARITY |
|
|
|
|
|
IXP2400_PORT_RX_MODE_2_CYCLE_DECODE,
|
|
|
|
|
|
|
|
|
|
IXP2400_PORT_RX_MODE_MASTER |
|
|
|
|
|
IXP2400_PORT_RX_MODE_POS_PHY |
|
|
|
|
|
IXP2400_PORT_RX_MODE_POS_PHY_L3 |
|
|
|
|
|
IXP2400_PORT_RX_MODE_ODD_PARITY |
|
|
|
|
|
IXP2400_PORT_RX_MODE_2_CYCLE_DECODE,
|
|
|
|
|
|
|
|
|
|
IXP2400_PORT_RX_MODE_MASTER |
|
|
|
|
|
IXP2400_PORT_RX_MODE_POS_PHY |
|
|
|
|
|
IXP2400_PORT_RX_MODE_POS_PHY_L3 |
|
|
|
|
|
IXP2400_PORT_RX_MODE_ODD_PARITY |
|
|
|
|
|
IXP2400_PORT_RX_MODE_2_CYCLE_DECODE,
|
|
|
|
|
|
|
|
|
|
IXP2400_PORT_RX_MODE_MASTER |
|
|
|
|
|
IXP2400_PORT_RX_MODE_POS_PHY |
|
|
|
|
|
IXP2400_PORT_RX_MODE_POS_PHY_L3 |
|
|
|
|
|
IXP2400_PORT_RX_MODE_ODD_PARITY |
|
|
|
|
|
IXP2400_PORT_RX_MODE_2_CYCLE_DECODE
|
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
.tx_mode = IXP2400_TX_MODE_UTOPIA_POS |
|
|
|
|
|
IXP2400_TX_MODE_1x32 |
|
|
|
|
|
IXP2400_TX_MODE_MPHY |
|
|
|
|
|
IXP2400_TX_MODE_MPHY_32 |
|
|
|
|
|
IXP2400_TX_MODE_MPHY_POLLED_STATUS |
|
|
|
|
|
IXP2400_TX_MODE_MPHY_LEVEL3 |
|
|
|
|
|
IXP2400_TX_MODE_TBUF_SIZE_64,
|
|
|
|
|
|
|
|
|
|
.txclk01_multiplier = IXP2400_PLL_MULTIPLIER_16,
|
|
|
|
|
|
|
|
|
|
.tx_poll_ports = 3,
|
|
|
|
|
|
|
|
|
|
.tx_channel_mode = {
|
|
|
|
|
IXP2400_PORT_TX_MODE_MASTER |
|
|
|
|
|
IXP2400_PORT_TX_MODE_POS_PHY |
|
|
|
|
|
IXP2400_PORT_TX_MODE_ODD_PARITY |
|
|
|
|
|
IXP2400_PORT_TX_MODE_2_CYCLE_DECODE,
|
|
|
|
|
|
|
|
|
|
IXP2400_PORT_TX_MODE_MASTER |
|
|
|
|
|
IXP2400_PORT_TX_MODE_POS_PHY |
|
|
|
|
|
IXP2400_PORT_TX_MODE_ODD_PARITY |
|
|
|
|
|
IXP2400_PORT_TX_MODE_2_CYCLE_DECODE,
|
|
|
|
|
|
|
|
|
|
IXP2400_PORT_TX_MODE_MASTER |
|
|
|
|
|
IXP2400_PORT_TX_MODE_POS_PHY |
|
|
|
|
|
IXP2400_PORT_TX_MODE_ODD_PARITY |
|
|
|
|
|
IXP2400_PORT_TX_MODE_2_CYCLE_DECODE,
|
|
|
|
|
|
|
|
|
|
IXP2400_PORT_TX_MODE_MASTER |
|
|
|
|
|
IXP2400_PORT_TX_MODE_POS_PHY |
|
|
|
|
|
IXP2400_PORT_TX_MODE_ODD_PARITY |
|
|
|
|
|
IXP2400_PORT_TX_MODE_2_CYCLE_DECODE
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct enp2611_ixpdev_priv
|
|
|
|
|
{
|
|
|
|
|
struct ixpdev_priv ixpdev_priv;
|
|
|
|
|
struct net_device_stats stats;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static struct net_device *nds[3];
|
|
|
|
|
static struct timer_list link_check_timer;
|
|
|
|
|
|
|
|
|
|
static struct net_device_stats *enp2611_get_stats(struct net_device *dev)
|
|
|
|
|
{
|
|
|
|
|
struct enp2611_ixpdev_priv *ip = netdev_priv(dev);
|
|
|
|
|
|
|
|
|
|
pm3386_get_stats(ip->ixpdev_priv.channel, &(ip->stats));
|
|
|
|
|
|
|
|
|
|
return &(ip->stats);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* @@@ Poll the SFP moddef0 line too. */
|
|
|
|
|
/* @@@ Try to use the pm3386 DOOL interrupt as well. */
|
|
|
|
|
static void enp2611_check_link_status(unsigned long __dummy)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < 3; i++) {
|
|
|
|
|
struct net_device *dev;
|
|
|
|
|
int status;
|
|
|
|
|
|
|
|
|
|
dev = nds[i];
|
2006-05-15 15:25:29 -04:00
|
|
|
if (dev == NULL)
|
|
|
|
|
continue;
|
[PATCH] intel ixp2000 network driver
The way the hardware and firmware work is that there is one shared RX
queue and IRQ for a number of different network interfaces. Due to this,
we would like to process received packets for every interface in the same
NAPI poll handler, so we need a pseudo-device to schedule polling on.
What the driver currently does is that it always schedules polling for
the first network interface in the list, and processes packets for every
interface in the poll handler for that first interface -- however, this
scheme breaks down if the first network interface happens to not be up,
since netif_rx_schedule_prep() checks netif_running().
sky2 apparently has the same issue, and Stephen Hemminger suggested a
way to work around this: create a variant of netif_rx_schedule_prep()
that does not check netif_running(). I implemented this locally and
called it netif_rx_schedule_prep_notup(), and it seems to work well,
but it's something that probably not everyone would be happy with.
The ixp2000 is an ARM CPU with a high-speed network interface in the
CPU itself (full duplex 4Gb/s or 10Gb/s depending on the IXP model.)
The CPU package also contains 8 or 16 (again depending on the IXP
model) 'microengines', which are somewhat primitive but very fast
and efficient processor cores which can be used to offload various
things from the main CPU.
This driver makes the high-speed network interface in the CPU visible
and usable as a regular linux network device. Currently, it only
supports the Radisys ENP2611 IXP board, but adding support for other
board types should be fairly easy.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-11-11 12:23:13 -05:00
|
|
|
|
|
|
|
|
status = pm3386_is_link_up(i);
|
2005-11-23 06:49:35 -05:00
|
|
|
if (status && !netif_carrier_ok(dev)) {
|
2005-11-23 06:49:40 -05:00
|
|
|
/* @@@ Should report autonegotiation status. */
|
|
|
|
|
printk(KERN_INFO "%s: NIC Link is Up\n", dev->name);
|
|
|
|
|
|
[PATCH] intel ixp2000 network driver
The way the hardware and firmware work is that there is one shared RX
queue and IRQ for a number of different network interfaces. Due to this,
we would like to process received packets for every interface in the same
NAPI poll handler, so we need a pseudo-device to schedule polling on.
What the driver currently does is that it always schedules polling for
the first network interface in the list, and processes packets for every
interface in the poll handler for that first interface -- however, this
scheme breaks down if the first network interface happens to not be up,
since netif_rx_schedule_prep() checks netif_running().
sky2 apparently has the same issue, and Stephen Hemminger suggested a
way to work around this: create a variant of netif_rx_schedule_prep()
that does not check netif_running(). I implemented this locally and
called it netif_rx_schedule_prep_notup(), and it seems to work well,
but it's something that probably not everyone would be happy with.
The ixp2000 is an ARM CPU with a high-speed network interface in the
CPU itself (full duplex 4Gb/s or 10Gb/s depending on the IXP model.)
The CPU package also contains 8 or 16 (again depending on the IXP
model) 'microengines', which are somewhat primitive but very fast
and efficient processor cores which can be used to offload various
things from the main CPU.
This driver makes the high-speed network interface in the CPU visible
and usable as a regular linux network device. Currently, it only
supports the Radisys ENP2611 IXP board, but adding support for other
board types should be fairly easy.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-11-11 12:23:13 -05:00
|
|
|
pm3386_enable_tx(i);
|
|
|
|
|
caleb_enable_tx(i);
|
2005-11-23 06:49:35 -05:00
|
|
|
netif_carrier_on(dev);
|
|
|
|
|
} else if (!status && netif_carrier_ok(dev)) {
|
2005-11-23 06:49:40 -05:00
|
|
|
printk(KERN_INFO "%s: NIC Link is Down\n", dev->name);
|
|
|
|
|
|
2005-11-23 06:49:35 -05:00
|
|
|
netif_carrier_off(dev);
|
[PATCH] intel ixp2000 network driver
The way the hardware and firmware work is that there is one shared RX
queue and IRQ for a number of different network interfaces. Due to this,
we would like to process received packets for every interface in the same
NAPI poll handler, so we need a pseudo-device to schedule polling on.
What the driver currently does is that it always schedules polling for
the first network interface in the list, and processes packets for every
interface in the poll handler for that first interface -- however, this
scheme breaks down if the first network interface happens to not be up,
since netif_rx_schedule_prep() checks netif_running().
sky2 apparently has the same issue, and Stephen Hemminger suggested a
way to work around this: create a variant of netif_rx_schedule_prep()
that does not check netif_running(). I implemented this locally and
called it netif_rx_schedule_prep_notup(), and it seems to work well,
but it's something that probably not everyone would be happy with.
The ixp2000 is an ARM CPU with a high-speed network interface in the
CPU itself (full duplex 4Gb/s or 10Gb/s depending on the IXP model.)
The CPU package also contains 8 or 16 (again depending on the IXP
model) 'microengines', which are somewhat primitive but very fast
and efficient processor cores which can be used to offload various
things from the main CPU.
This driver makes the high-speed network interface in the CPU visible
and usable as a regular linux network device. Currently, it only
supports the Radisys ENP2611 IXP board, but adding support for other
board types should be fairly easy.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-11-11 12:23:13 -05:00
|
|
|
caleb_disable_tx(i);
|
|
|
|
|
pm3386_disable_tx(i);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
link_check_timer.expires = jiffies + HZ / 10;
|
|
|
|
|
add_timer(&link_check_timer);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void enp2611_set_port_admin_status(int port, int up)
|
|
|
|
|
{
|
|
|
|
|
if (up) {
|
|
|
|
|
caleb_enable_rx(port);
|
2005-11-23 06:49:59 -05:00
|
|
|
|
|
|
|
|
pm3386_set_carrier(port, 1);
|
[PATCH] intel ixp2000 network driver
The way the hardware and firmware work is that there is one shared RX
queue and IRQ for a number of different network interfaces. Due to this,
we would like to process received packets for every interface in the same
NAPI poll handler, so we need a pseudo-device to schedule polling on.
What the driver currently does is that it always schedules polling for
the first network interface in the list, and processes packets for every
interface in the poll handler for that first interface -- however, this
scheme breaks down if the first network interface happens to not be up,
since netif_rx_schedule_prep() checks netif_running().
sky2 apparently has the same issue, and Stephen Hemminger suggested a
way to work around this: create a variant of netif_rx_schedule_prep()
that does not check netif_running(). I implemented this locally and
called it netif_rx_schedule_prep_notup(), and it seems to work well,
but it's something that probably not everyone would be happy with.
The ixp2000 is an ARM CPU with a high-speed network interface in the
CPU itself (full duplex 4Gb/s or 10Gb/s depending on the IXP model.)
The CPU package also contains 8 or 16 (again depending on the IXP
model) 'microengines', which are somewhat primitive but very fast
and efficient processor cores which can be used to offload various
things from the main CPU.
This driver makes the high-speed network interface in the CPU visible
and usable as a regular linux network device. Currently, it only
supports the Radisys ENP2611 IXP board, but adding support for other
board types should be fairly easy.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-11-11 12:23:13 -05:00
|
|
|
pm3386_enable_rx(port);
|
|
|
|
|
} else {
|
|
|
|
|
caleb_disable_tx(port);
|
|
|
|
|
pm3386_disable_tx(port);
|
2005-11-23 06:49:59 -05:00
|
|
|
/* @@@ Flush out pending packets. */
|
|
|
|
|
pm3386_set_carrier(port, 0);
|
|
|
|
|
|
[PATCH] intel ixp2000 network driver
The way the hardware and firmware work is that there is one shared RX
queue and IRQ for a number of different network interfaces. Due to this,
we would like to process received packets for every interface in the same
NAPI poll handler, so we need a pseudo-device to schedule polling on.
What the driver currently does is that it always schedules polling for
the first network interface in the list, and processes packets for every
interface in the poll handler for that first interface -- however, this
scheme breaks down if the first network interface happens to not be up,
since netif_rx_schedule_prep() checks netif_running().
sky2 apparently has the same issue, and Stephen Hemminger suggested a
way to work around this: create a variant of netif_rx_schedule_prep()
that does not check netif_running(). I implemented this locally and
called it netif_rx_schedule_prep_notup(), and it seems to work well,
but it's something that probably not everyone would be happy with.
The ixp2000 is an ARM CPU with a high-speed network interface in the
CPU itself (full duplex 4Gb/s or 10Gb/s depending on the IXP model.)
The CPU package also contains 8 or 16 (again depending on the IXP
model) 'microengines', which are somewhat primitive but very fast
and efficient processor cores which can be used to offload various
things from the main CPU.
This driver makes the high-speed network interface in the CPU visible
and usable as a regular linux network device. Currently, it only
supports the Radisys ENP2611 IXP board, but adding support for other
board types should be fairly easy.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-11-11 12:23:13 -05:00
|
|
|
pm3386_disable_rx(port);
|
|
|
|
|
caleb_disable_rx(port);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int __init enp2611_init_module(void)
|
|
|
|
|
{
|
2006-05-15 15:25:29 -04:00
|
|
|
int ports;
|
[PATCH] intel ixp2000 network driver
The way the hardware and firmware work is that there is one shared RX
queue and IRQ for a number of different network interfaces. Due to this,
we would like to process received packets for every interface in the same
NAPI poll handler, so we need a pseudo-device to schedule polling on.
What the driver currently does is that it always schedules polling for
the first network interface in the list, and processes packets for every
interface in the poll handler for that first interface -- however, this
scheme breaks down if the first network interface happens to not be up,
since netif_rx_schedule_prep() checks netif_running().
sky2 apparently has the same issue, and Stephen Hemminger suggested a
way to work around this: create a variant of netif_rx_schedule_prep()
that does not check netif_running(). I implemented this locally and
called it netif_rx_schedule_prep_notup(), and it seems to work well,
but it's something that probably not everyone would be happy with.
The ixp2000 is an ARM CPU with a high-speed network interface in the
CPU itself (full duplex 4Gb/s or 10Gb/s depending on the IXP model.)
The CPU package also contains 8 or 16 (again depending on the IXP
model) 'microengines', which are somewhat primitive but very fast
and efficient processor cores which can be used to offload various
things from the main CPU.
This driver makes the high-speed network interface in the CPU visible
and usable as a regular linux network device. Currently, it only
supports the Radisys ENP2611 IXP board, but adding support for other
board types should be fairly easy.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-11-11 12:23:13 -05:00
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
if (!machine_is_enp2611())
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
|
|
caleb_reset();
|
|
|
|
|
pm3386_reset();
|
|
|
|
|
|
2006-05-15 15:25:29 -04:00
|
|
|
ports = pm3386_port_count();
|
|
|
|
|
for (i = 0; i < ports; i++) {
|
[PATCH] intel ixp2000 network driver
The way the hardware and firmware work is that there is one shared RX
queue and IRQ for a number of different network interfaces. Due to this,
we would like to process received packets for every interface in the same
NAPI poll handler, so we need a pseudo-device to schedule polling on.
What the driver currently does is that it always schedules polling for
the first network interface in the list, and processes packets for every
interface in the poll handler for that first interface -- however, this
scheme breaks down if the first network interface happens to not be up,
since netif_rx_schedule_prep() checks netif_running().
sky2 apparently has the same issue, and Stephen Hemminger suggested a
way to work around this: create a variant of netif_rx_schedule_prep()
that does not check netif_running(). I implemented this locally and
called it netif_rx_schedule_prep_notup(), and it seems to work well,
but it's something that probably not everyone would be happy with.
The ixp2000 is an ARM CPU with a high-speed network interface in the
CPU itself (full duplex 4Gb/s or 10Gb/s depending on the IXP model.)
The CPU package also contains 8 or 16 (again depending on the IXP
model) 'microengines', which are somewhat primitive but very fast
and efficient processor cores which can be used to offload various
things from the main CPU.
This driver makes the high-speed network interface in the CPU visible
and usable as a regular linux network device. Currently, it only
supports the Radisys ENP2611 IXP board, but adding support for other
board types should be fairly easy.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-11-11 12:23:13 -05:00
|
|
|
nds[i] = ixpdev_alloc(i, sizeof(struct enp2611_ixpdev_priv));
|
|
|
|
|
if (nds[i] == NULL) {
|
|
|
|
|
while (--i >= 0)
|
|
|
|
|
free_netdev(nds[i]);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SET_MODULE_OWNER(nds[i]);
|
|
|
|
|
nds[i]->get_stats = enp2611_get_stats;
|
|
|
|
|
pm3386_init_port(i);
|
|
|
|
|
pm3386_get_mac(i, nds[i]->dev_addr);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ixp2400_msf_init(&enp2611_msf_parameters);
|
|
|
|
|
|
2006-05-15 15:25:29 -04:00
|
|
|
if (ixpdev_init(ports, nds, enp2611_set_port_admin_status)) {
|
|
|
|
|
for (i = 0; i < ports; i++)
|
|
|
|
|
if (nds[i])
|
|
|
|
|
free_netdev(nds[i]);
|
[PATCH] intel ixp2000 network driver
The way the hardware and firmware work is that there is one shared RX
queue and IRQ for a number of different network interfaces. Due to this,
we would like to process received packets for every interface in the same
NAPI poll handler, so we need a pseudo-device to schedule polling on.
What the driver currently does is that it always schedules polling for
the first network interface in the list, and processes packets for every
interface in the poll handler for that first interface -- however, this
scheme breaks down if the first network interface happens to not be up,
since netif_rx_schedule_prep() checks netif_running().
sky2 apparently has the same issue, and Stephen Hemminger suggested a
way to work around this: create a variant of netif_rx_schedule_prep()
that does not check netif_running(). I implemented this locally and
called it netif_rx_schedule_prep_notup(), and it seems to work well,
but it's something that probably not everyone would be happy with.
The ixp2000 is an ARM CPU with a high-speed network interface in the
CPU itself (full duplex 4Gb/s or 10Gb/s depending on the IXP model.)
The CPU package also contains 8 or 16 (again depending on the IXP
model) 'microengines', which are somewhat primitive but very fast
and efficient processor cores which can be used to offload various
things from the main CPU.
This driver makes the high-speed network interface in the CPU visible
and usable as a regular linux network device. Currently, it only
supports the Radisys ENP2611 IXP board, but adding support for other
board types should be fairly easy.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-11-11 12:23:13 -05:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
init_timer(&link_check_timer);
|
|
|
|
|
link_check_timer.function = enp2611_check_link_status;
|
|
|
|
|
link_check_timer.expires = jiffies;
|
|
|
|
|
add_timer(&link_check_timer);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void __exit enp2611_cleanup_module(void)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
del_timer_sync(&link_check_timer);
|
|
|
|
|
|
|
|
|
|
ixpdev_deinit();
|
|
|
|
|
for (i = 0; i < 3; i++)
|
|
|
|
|
free_netdev(nds[i]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
module_init(enp2611_init_module);
|
|
|
|
|
module_exit(enp2611_cleanup_module);
|
|
|
|
|
MODULE_LICENSE("GPL");
|