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

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [packages/] [devs/] [usb/] [sa11x0/] [v2_0/] [doc/] [usbs_sa11x0.sgml] - Blame information for rev 565

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 27 unneback
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
32
33
34
35
36
 
37
38
 
39
40
41
  SA11X0 USB Device Driver
42
 
43
44
45
SA11X0 USB Device Driver
46
47
48
SA11X0 USB Support
49
Device driver for the on-chip SA11X0 USB device
50
51
 
52
SA11X0 USB Hardware
53
54
The Intel StrongARM SA11x0 family of processors is supplied with an
55
on-chip USB slave device, the UDC (USB Device Controller). This
56
supports three endpoints. Endpoint 0 can only be used for control
57
messages. Endpoint 1 can only be used for bulk transfers from host to
58
peripheral. Endpoint 2 can only be used for bulk transfers from
59
peripheral to host. Isochronous and interrupt transfers are not
60
supported.
61
62
63
64
Different revisions of the SA11x0 silicon have had various problems
65
with the USB support. The device driver has been tested primarily
66
against stepping B4 of the SA1110 processor, and may not function as
67
expected with other revisions. Application developers should obtain
68
the manufacturer's current errata sheets and specification updates.
69
The B4 stepping still has a number of problems, but the device driver
70
can work around these. However there is a penalty in terms of extra
71
code, extra cpu cycles, and increased dispatch latency because extra
72
processing is needed at DSR level. Interrupt latency should not be
73
affected.
74
75
76
There is one specific problem inherent in the UDC design of which
77
application developers should be aware: the hardware cannot fully
78
implement the USB standard for bulk transfers. A bulk transfer
79
typically consists of some number of full-size 64-byte packets and is
80
terminated by a packet less than the full size. If the amount of data
81
transferred is an exact multiple of 64 bytes then this requires a
82
terminating packet of 0 bytes of data (plus header and checksum). The
83
SA11x0 USB hardware does not allow a 0-byte packet to be transmitted,
84
so the device driver is forced to substitute a 1-byte packet and the
85
host receives more data than expected. Protocol support is needed so
86
that the appropriate host-side device driver can allow buffer space
87
for the extra byte, detect when it gets sent, and discard it.
88
Consequently certain standard USB class protocols cannot be
89
implemented using the SA11x0, and therefore custom host-side device
90
drivers will generally have to be provided, rather than re-using
91
existing ones that understand the standard protocol.
92
93
94
95
 
96
Endpoint Data Structures
97
98
The SA11x0 USB device driver can provide up to three data structures
99
corresponding to the three endpoints: a
100
usbs_control_endpoint structure
101
usbs_sa11x0_ep0; a
102
usbs_rx_endpoint
103
usbs_sa11x0_ep1; and a
104
usbs_tx_endpoint
105
usbs_sa11x0_ep2. The header file
106
cyg/io/usb/usbs_sa11x0.h
107
provides declarations for these.
108
109
110
Not all applications will require support for all the endpoints. For
111
example, if the intended use of the UDC only involves peripheral to
112
host transfers then usbs_sa11x0_ep1 is redundant.
113
The device driver provides configuration options to control the
114
presence of each endpoint:
115
116
117
118
119
Endpoint 0 is controlled by
120
CYGFUN_DEVS_USB_SA11X0_EP0. This defaults to
121
enabled if there are any higher-level packages that require USB
122
hardware or if the global preference
123
CYGGLO_IO_USB_SLAVE_APPLICATION is enabled,
124
otherwise it is disabled. Usually this has the desired effect. It may
125
be necessary to override this in special circumstances, for example if
126
the target board uses an external USB chip in preference to the UDC
127
and it is that external chip's device driver that should be used
128
rather than the on-chip UDC. It is not possible to disable endpoint 0
129
and at the same time enable one or both of the other endpoints, since
130
a USB device is only usable if it can process the standard control
131
messages.
132
133
134
135
136
Endpoint 1 is controlled by
137
CYGPKG_DEVS_USB_SA11X0_EP1. By default it is
138
enabled whenever endpoint 0 is enabled, but it can be disabled
139
manually when not required.
140
141
142
143
144
Similarly endpoint 2 is controlled by
145
CYGPKG_DEVS_USB_SA11X0_EP2. This is also enabled by
146
default whenever endpoint 0 is enabled, but it can be disabled manually.
147
148
149
150
151
The SA11X0 USB device driver implements the interface specified by the
152
common eCos USB Slave Support package. The documentation for that
153
package should be consulted for further details. There is only one
154
major deviation: when there is a peripheral to host transfer on
155
endpoint 2 which is an exact multiple of the bulk transfer packet size
156
(usually 64 bytes) the device driver has to pad the transfer with one
157
extra byte. This is because of a hardware limitation: the UDC is
158
incapable of transmitting 0-byte packets as required by the USB
159
specification. Higher-level code, including the host-side device
160
driver, needs to be aware of this and adapt accordingly.
161
162
163
The device driver assumes a bulk packet size of 64 bytes, so this
164
value should be used in the endpoint descriptors in the enumeration
165
data provided by application code. There is experimental code
166
for running with DMA disabled,
167
in which case the packet size will be 16 bytes rather than 64.
168
169
170
 
171
Devtab Entries
172
173
In addition to the endpoint data structures the SA11X0 USB device
174
driver can also provide devtab entries for each endpoint. This allows
175
higher-level code to use traditional I/O operations such as
176
open/read/write
177
rather than the USB-specific non-blocking functions like
178
usbs_start_rx_buffer. These devtab entries are
179
optional since they are not always required. The relevant
180
configuration options are
181
CYGVAR_DEVS_USB_SA11X0_EP0_DEVTAB_ENTRY,
182
CYGVAR_DEVS_USB_SA11X0_EP1_DEVTAB_ENTRY and
183
CYGVAR_DEVS_USB_SA11X0_EP2_DEVTAB_ENTRY. By default
184
these devtab entries are provided if the global preference
185
CYGGLO_USB_SLAVE_PROVIDE_DEVTAB_ENTRIES is enabled,
186
which is usually the case. Obviously a devtab entry for a given
187
endpoint will only be provided if the underlying endpoint is enabled.
188
For example, there will not be a devtab entry for endpoint 1 if
189
CYGPKG_DEVS_USB_SA11X0_EP1 is disabled.
190
191
192
The names for the three devtab entries are determined by using a
193
configurable base name and appending 0c,
194
1r or 2w. The base name is
195
determined by the configuration option
196
CYGDAT_DEVS_USB_SA11X0_DEVTAB_BASENAME and has a
197
default value of /dev/usbs, so the devtab entry for
198
endpoint 1 would default to /dev/usbs1r. If the
199
target hardware involves multiple USB devices then application
200
developers may have to change the base name to prevent a name clash.
201
202
203
 
204
DMA Engines
205
206
The SA11X0 UDC provides only limited fifos for bulk transfers on
207
endpoints 1 and 2; smaller than the normal 64-byte bulk packet size.
208
Therefore a typical transfer requires the use of DMA engines. The
209
SA11x0 provides six DMA engines that can be used for this, and the
210
endpoints require one each (assuming both endpoints are enabled). At
211
the time of writing there is no arbitration mechanism to control
212
access to the DMA engines. By default the device driver will use
213
DMA engine 4 for endpoint 1 and DMA engine 5 for endpoint 2, and it
214
assumes that no other code uses these particular engines.
215
216
217
The exact DMA engines that will be used are determined by the
218
configuration options
219
CYGNUM_DEVS_USB_SA11X0_EP1_DMA_CHANNEL and
220
CYGNUM_DEVS_USB_SA11X0_EP2_DMA_CHANNEL. These
221
options have the booldata flavor, allowing the use of DMA to be
222
disabled completely in addition to controlling which DMA engines are
223
used. If DMA is disabled then the device driver will attempt to
224
work purely using the fifos, and the packet size will be limited to
225
only 16 bytes. This limit should be reflected in the appropriate
226
endpoint descriptors in the enumeration data. The code for driving the
227
endpoints without DMA should be considered experimental. At best it
228
will be suitable only for applications where the amount of data
229
transferred is relatively small, because four times as many interrupts
230
will be raised and performance will suffer accordingly.
231
232
233
 
234
235
236

powered by: WebSVN 2.1.0

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