2005-10-29 04:25:58 +08:00
|
|
|
/*
|
|
|
|
* Platform information definitions for the
|
|
|
|
* universal Freescale Ethernet driver.
|
|
|
|
*
|
|
|
|
* Copyright (c) 2003 Intracom S.A.
|
|
|
|
* by Pantelis Antoniou <panto@intracom.gr>
|
|
|
|
*
|
|
|
|
* 2005 (c) MontaVista Software, Inc.
|
|
|
|
* Vitaly Bordug <vbordug@ru.mvista.com>
|
|
|
|
*
|
|
|
|
* This file is licensed under the terms of the GNU General Public License
|
|
|
|
* version 2. This program is licensed "as is" without any warranty of any
|
|
|
|
* kind, whether express or implied.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef FS_ENET_PD_H
|
|
|
|
#define FS_ENET_PD_H
|
|
|
|
|
2007-10-02 03:20:49 +08:00
|
|
|
#include <linux/string.h>
|
2009-04-25 20:53:33 +08:00
|
|
|
#include <linux/of_mdio.h>
|
2005-10-29 04:25:58 +08:00
|
|
|
#include <asm/types.h>
|
|
|
|
|
|
|
|
#define FS_ENET_NAME "fs_enet"
|
|
|
|
|
|
|
|
enum fs_id {
|
|
|
|
fsid_fec1,
|
|
|
|
fsid_fec2,
|
|
|
|
fsid_fcc1,
|
|
|
|
fsid_fcc2,
|
|
|
|
fsid_fcc3,
|
|
|
|
fsid_scc1,
|
|
|
|
fsid_scc2,
|
|
|
|
fsid_scc3,
|
|
|
|
fsid_scc4,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define FS_MAX_INDEX 9
|
|
|
|
|
|
|
|
static inline int fs_get_fec_index(enum fs_id id)
|
|
|
|
{
|
|
|
|
if (id >= fsid_fec1 && id <= fsid_fec2)
|
|
|
|
return id - fsid_fec1;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int fs_get_fcc_index(enum fs_id id)
|
|
|
|
{
|
|
|
|
if (id >= fsid_fcc1 && id <= fsid_fcc3)
|
|
|
|
return id - fsid_fcc1;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int fs_get_scc_index(enum fs_id id)
|
|
|
|
{
|
|
|
|
if (id >= fsid_scc1 && id <= fsid_scc4)
|
|
|
|
return id - fsid_scc1;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
POWERPC: Bring the fs_no calculation to the relevant SoC enumeration
The fs_no mean used to be fs_enet driver driven, hence it was an
enumeration across all the possible fs_enet "users" in the SoC. Now, with
QE on the pipeline, and to make DTS descriptions more clear, fs_no features
relevant SoC part number, with additional field to describe the SoC type.
Another reason for that is now not only fs_enet is going to utilize those
stuff. There might be UART, HLDC, and even USB, so to prevent confusion and
be ready for upcoming OF_device transfer, fs_enet and cpm_uart drivers were
updated in that concern, as well as the relevant DTS.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
2006-09-22 02:38:05 +08:00
|
|
|
static inline int fs_fec_index2id(int index)
|
|
|
|
{
|
|
|
|
int id = fsid_fec1 + index - 1;
|
|
|
|
if (id >= fsid_fec1 && id <= fsid_fec2)
|
|
|
|
return id;
|
|
|
|
return FS_MAX_INDEX;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int fs_fcc_index2id(int index)
|
|
|
|
{
|
|
|
|
int id = fsid_fcc1 + index - 1;
|
|
|
|
if (id >= fsid_fcc1 && id <= fsid_fcc3)
|
|
|
|
return id;
|
|
|
|
return FS_MAX_INDEX;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int fs_scc_index2id(int index)
|
|
|
|
{
|
|
|
|
int id = fsid_scc1 + index - 1;
|
|
|
|
if (id >= fsid_scc1 && id <= fsid_scc4)
|
|
|
|
return id;
|
|
|
|
return FS_MAX_INDEX;
|
|
|
|
}
|
|
|
|
|
2005-10-29 04:25:58 +08:00
|
|
|
enum fs_mii_method {
|
|
|
|
fsmii_fixed,
|
|
|
|
fsmii_fec,
|
|
|
|
fsmii_bitbang,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum fs_ioport {
|
|
|
|
fsiop_porta,
|
|
|
|
fsiop_portb,
|
|
|
|
fsiop_portc,
|
|
|
|
fsiop_portd,
|
|
|
|
fsiop_porte,
|
|
|
|
};
|
|
|
|
|
2006-08-15 14:00:31 +08:00
|
|
|
struct fs_mii_bit {
|
|
|
|
u32 offset;
|
|
|
|
u8 bit;
|
|
|
|
u8 polarity;
|
|
|
|
};
|
|
|
|
struct fs_mii_bb_platform_info {
|
|
|
|
struct fs_mii_bit mdio_dir;
|
|
|
|
struct fs_mii_bit mdio_dat;
|
|
|
|
struct fs_mii_bit mdc_dat;
|
|
|
|
int delay; /* delay in us */
|
|
|
|
int irq[32]; /* irqs per phy's */
|
2005-10-29 04:25:58 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct fs_platform_info {
|
2006-09-22 02:38:05 +08:00
|
|
|
|
|
|
|
void(*init_ioports)(struct fs_platform_info *);
|
2005-10-29 04:25:58 +08:00
|
|
|
/* device specific information */
|
|
|
|
int fs_no; /* controller index */
|
POWERPC: Bring the fs_no calculation to the relevant SoC enumeration
The fs_no mean used to be fs_enet driver driven, hence it was an
enumeration across all the possible fs_enet "users" in the SoC. Now, with
QE on the pipeline, and to make DTS descriptions more clear, fs_no features
relevant SoC part number, with additional field to describe the SoC type.
Another reason for that is now not only fs_enet is going to utilize those
stuff. There might be UART, HLDC, and even USB, so to prevent confusion and
be ready for upcoming OF_device transfer, fs_enet and cpm_uart drivers were
updated in that concern, as well as the relevant DTS.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
2006-09-22 02:38:05 +08:00
|
|
|
char fs_type[4]; /* controller type */
|
2005-10-29 04:25:58 +08:00
|
|
|
|
|
|
|
u32 cp_page; /* CPM page */
|
|
|
|
u32 cp_block; /* CPM sblock */
|
2007-10-02 23:55:58 +08:00
|
|
|
u32 cp_command; /* CPM page/sblock/mcn */
|
2006-09-22 02:38:05 +08:00
|
|
|
|
2005-10-29 04:25:58 +08:00
|
|
|
u32 clk_trx; /* some stuff for pins & mux configuration*/
|
2006-09-22 02:38:05 +08:00
|
|
|
u32 clk_rx;
|
|
|
|
u32 clk_tx;
|
2005-10-29 04:25:58 +08:00
|
|
|
u32 clk_route;
|
|
|
|
u32 clk_mask;
|
2006-09-22 02:38:05 +08:00
|
|
|
|
2005-10-29 04:25:58 +08:00
|
|
|
u32 mem_offset;
|
|
|
|
u32 dpram_offset;
|
|
|
|
u32 fcc_regs_c;
|
|
|
|
|
|
|
|
u32 device_flags;
|
|
|
|
|
2009-04-25 20:53:33 +08:00
|
|
|
struct device_node *phy_node;
|
2005-10-29 04:25:58 +08:00
|
|
|
const struct fs_mii_bus_info *bus_info;
|
|
|
|
|
|
|
|
int rx_ring, tx_ring; /* number of buffers on rx */
|
|
|
|
__u8 macaddr[6]; /* mac address */
|
|
|
|
int rx_copybreak; /* limit we copy small frames */
|
|
|
|
int use_napi; /* use NAPI */
|
|
|
|
int napi_weight; /* NAPI weight */
|
|
|
|
|
|
|
|
int use_rmii; /* use RMII mode */
|
2006-08-15 14:00:31 +08:00
|
|
|
int has_phy; /* if the network is phy container as well...*/
|
|
|
|
};
|
|
|
|
struct fs_mii_fec_platform_info {
|
|
|
|
u32 irq[32];
|
|
|
|
u32 mii_speed;
|
2005-10-29 04:25:58 +08:00
|
|
|
};
|
POWERPC: Bring the fs_no calculation to the relevant SoC enumeration
The fs_no mean used to be fs_enet driver driven, hence it was an
enumeration across all the possible fs_enet "users" in the SoC. Now, with
QE on the pipeline, and to make DTS descriptions more clear, fs_no features
relevant SoC part number, with additional field to describe the SoC type.
Another reason for that is now not only fs_enet is going to utilize those
stuff. There might be UART, HLDC, and even USB, so to prevent confusion and
be ready for upcoming OF_device transfer, fs_enet and cpm_uart drivers were
updated in that concern, as well as the relevant DTS.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
2006-09-22 02:38:05 +08:00
|
|
|
|
|
|
|
static inline int fs_get_id(struct fs_platform_info *fpi)
|
|
|
|
{
|
|
|
|
if(strstr(fpi->fs_type, "SCC"))
|
|
|
|
return fs_scc_index2id(fpi->fs_no);
|
|
|
|
if(strstr(fpi->fs_type, "FCC"))
|
|
|
|
return fs_fcc_index2id(fpi->fs_no);
|
|
|
|
if(strstr(fpi->fs_type, "FEC"))
|
|
|
|
return fs_fec_index2id(fpi->fs_no);
|
|
|
|
return fpi->fs_no;
|
|
|
|
}
|
|
|
|
|
2005-10-29 04:25:58 +08:00
|
|
|
#endif
|