OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [rtos/] [ecos-3.0/] [packages/] [devs/] [eth/] [phy/] [current/] [doc/] [eth_phy.sgml] - Blame information for rev 786

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 786 skrzyp
2
 
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
28
29
 
30
31
Ethernet PHY Device Support
32
33
Ethernet PHY Device Support
34
35
Ethernet PHY Device API
36
37
Modern ethernet subsystems are often separated into two pieces, the
38
media access controller (sometimes known as a MAC) and the physical
39
device or line interface (often referred to as a PHY).  In this case,
40
the MAC handles generating and parsing physical frames and the PHY
41
handles how this data is actually moved to/from the wire.  The MAC
42
and PHY communicate via a special protocol, known as MII.  This MII
43
protocol can handle control over the PHY which allows for selection
44
of such transmission criteria as line speed, duplex mode, etc.
45
46
47
In most cases, ethernet drivers only need to bother with the PHY during
48
system initialization.  Since the details of the PHY are separate from
49
the MAC, there are different drivers for each.  The drivers for the PHY
50
are described by a set of exported functions which are commonly used by
51
the MAC.  The primary use of these functions currently is to initialize
52
the PHY and determine the status of the line connection.
53
54
55
The connection between the MAC and the PHY differs from MAC to MAC, so
56
the actual routines to manipulate this data channel are a property of
57
the MAC instance.  Furthermore, there are many PHY devices each with their
58
own internal operations.  A complete MAC/PHY driver setup will be comprised
59
of the MAC MII access functions and the PHY internal driver.
60
61
62
A driver instance is contained within a
63
eth_phy_access_t:
64
65
 
66
#define PHY_BIT_LEVEL_ACCESS_TYPE 0
67
#define PHY_REG_LEVEL_ACCESS_TYPE 1
68
 
69
typedef struct {
70
    int ops_type;  // 0 => bit level, 1 => register level
71
    bool init_done;
72
    void (*init)(void);
73
    void (*reset)(void);
74
    union {
75
        struct {
76
            void (*set_data)(int);
77
            int  (*get_data)(void);
78
            void (*set_clock)(int);
79
            void (*set_dir)(int);
80
        } bit_level_ops;
81
        struct {
82
            void (*put_reg)(int reg, int unit, unsigned short data);
83
            bool (*get_reg)(int reg, int unit, unsigned short *data);
84
        } reg_level_ops;
85
    } ops;
86
    int phy_addr;
87
    struct _eth_phy_dev_entry *dev;  // Chip access functions
88
} eth_phy_access_t;
89
 
90
struct _eth_phy_dev_entry {
91
    char          *name;
92
    unsigned long  id;
93
    bool         (*stat)(eth_phy_access_t *f, int *stat);
94
};
95
 
96
97
The dev element points to the PHY specific support
98
functions.
99
Currently, the only function which must be defined is stat().
100
101
102
The MAC-MII-PHY interface is a narrow connection, with commands and status
103
moving between the MAC and PHY using a bit-serial protocol.
104
Some MAC devices contain the intelligence to run this protocol, exposing
105
a mechanism to access PHY registers one at a time.  Other MAC devices may only
106
provide access to the MII data lines (or even still, this may be considered
107
completely separate from the MAC).  In these cases, the PHY support layer
108
must handle the serial protocol.
109
The choice between the access methods is in the
110
ops_type field.
111
If it has the value
112
PHY_BIT_LEVEL_ACCESS_TYPE, then the PHY device layer will
113
run the protocol, using the access functions
114
set_data(),
115
get_data(),
116
set_clock(),
117
set_dir() are used to control the MII signals and run
118
the protocol.
119
If ops_type has the value
120
PHY_REG_LEVEL_ACCESS_TYPE,
121
then the routines
122
put_reg(), and
123
get_reg()
124
are used to access the PHY registers.
125
126
127
Two additional functions may be defined.
128
These are
129
init(), and
130
reset().
131
The purpose of these functions is for gross-level management of the
132
MII interface.
133
The
134
init()
135
function will be called once, at system initialization time.
136
It should do whatever operations are necessary to prepare the
137
MII channel.
138
In the case of
139
PHY_BIT_LEVEL_ACCESS_TYPE devices,
140
init()
141
should prepare the signals for use, i.e. set up the appropriate
142
parallel port registers, etc.
143
The
144
reset()
145
function may be called by a driver to cause the PHY device to
146
be reset to a known state.
147
Not all drivers will require this and this function may not even
148
be possible, so it's use and behavior is somewhat target specific.
149
150
151
Currently, the only function required of device specific drivers is
152
stat().
153
This routine should query appropriate registers in the PHY and return
154
a status bitmap indicating the state of the physical connection.
155
In the case where the PHY can auto-negotiate a line speed and condition,
156
this information may be useful to the MAC to indicate what speed it should
157
provide data, etc.
158
The status bitmask contains these bits:
159
160
#define ETH_PHY_STAT_LINK   0x0001   // Link up/down
161
#define ETH_PHY_STAT_100MB  0x0002   // Connection is 100Mb/10Mb
162
#define ETH_PHY_STAT_FDX    0x0004   // Connection is full/half duplex
163
#define ETH_PHY_STAT_1000MB 0x0008   // Connection is 1Gb
164
165
Note: the usage here is that if the bit is set, then the condition
166
exists.  For example, if the
167
ETH_PHY_STAT_LINK
168
is set, then a physical link has been established.
169
170
171
172

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.