Initial commit of OpenSPARC T2 architecture model.
[OpenSPARC-T2-SAM] / obp / obp / dev / usb / ohci.fth
CommitLineData
920dae64
AT
1\ ========== Copyright Header Begin ==========================================
2\
3\ Hypervisor Software File: ohci.fth
4\
5\ Copyright (c) 2006 Sun Microsystems, Inc. All Rights Reserved.
6\
7\ - Do no alter or remove copyright notices
8\
9\ - Redistribution and use of this software in source and binary forms, with
10\ or without modification, are permitted provided that the following
11\ conditions are met:
12\
13\ - Redistribution of source code must retain the above copyright notice,
14\ this list of conditions and the following disclaimer.
15\
16\ - Redistribution in binary form must reproduce the above copyright notice,
17\ this list of conditions and the following disclaimer in the
18\ documentation and/or other materials provided with the distribution.
19\
20\ Neither the name of Sun Microsystems, Inc. or the names of contributors
21\ may be used to endorse or promote products derived from this software
22\ without specific prior written permission.
23\
24\ This software is provided "AS IS," without a warranty of any kind.
25\ ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
26\ INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
27\ PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN
28\ MICROSYSTEMS, INC. ("SUN") AND ITS LICENSORS SHALL NOT BE LIABLE FOR
29\ ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING OR
30\ DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN
31\ OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR
32\ FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE
33\ DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY,
34\ ARISING OUT OF THE USE OF OR INABILITY TO USE THIS SOFTWARE, EVEN IF
35\ SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
36\
37\ You acknowledge that this software is not designed, licensed or
38\ intended for use in the design, construction, operation or maintenance of
39\ any nuclear facility.
40\
41\ ========== Copyright Header End ============================================
42id: @(#)ohci.fth 1.14 06/02/01
43purpose:
44copyright: Copyright 2006 Sun Microsystems, Inc. All Rights Reserved
45copyright: Use is subject to license terms.
46
47\ stuff bits, leaving the rest alone, in the control reg.
48: controlbit-on ( bit -- )
49 chip-base hc-control rl@ or
50 chip-base hc-control rl!
51;
52
53\ turn bit off, leaving the rest alone, in control reg.
54: controlbit-off ( bit -- )
55 invert chip-base hc-control rl@ and
56 chip-base hc-control rl!
57;
58
59: periodic-on ( -- ) 4 controlbit-on ;
60
61: periodic-off ( -- ) 4 controlbit-off ;
62
63: isoc-on ( -- ) 8 controlbit-on ;
64
65: isoc-off ( -- ) 8 controlbit-off ;
66
67: control-on ( -- ) h# 10 controlbit-on ;
68
69: control-off ( -- ) h# 10 controlbit-off ;
70
71: bulk-on ( -- ) h# 20 controlbit-on ;
72
73: bulk-off ( -- ) h# 20 controlbit-off ;
74
75\ : q-on ( q-id -- )
76\ h# 3e - 0 max
77\ 4 swap lshift
78\ controlbits-on
79\ ;
80
81\ : q-off ( q-id -- )
82\ h# 3e - 0 max
83\ 4 swap lshift
84\ controlbits-off
85\ ;
86
87: >state ( n -- )
88 6 lshift
89 chip-base hc-control rl@
90 h# c0 invert and or
91 chip-base hc-control rl!
92;
93
94\ nominally 10 ms
95\ usb1.1, 7.1.7.3 says at least 50 ms
96: usb-reset ( -- ) 0 >state d# 100 ms ; \ power-on state
97
98\ nominally 20 ms; USB 7.1.4.5; also usb1.1 7.1.7.5
99: usb-resume ( -- ) 1 >state d# 40 ms ;
100
101\ usb1.1 7.1.7.3 says wait 10 ms before talking to devices after usb-reset
102\ usb1.1 7.1.7.5 says 10 ms delay after usb-resume
103\ embed the delay here, since operational is the end of usb-reset
104: usb-operational ( -- ) 2 >state d# 10 ms ;
105
106\ XXX enough time? nominally 5 ms from where? how long does it take for
107\ the controller to stop accessing memory? the time before we resume
108\ the bus doesn't seem to be an issue?
109\ The delay is to allow suspend to propagate down the bus. Devices need to
110\ see no SOF for 3 ms to go to their own suspended state.
111\ It is also to allow RIO to stop accessing memory.
112: usb-suspend ( -- ) 3 >state 5 ms ;
113
114\ stuff bit, leaving the rest alone, in the command/stat reg.
115: bit>command ( bit -- )
116 chip-base hc-cmd-status rl@ or
117 chip-base hc-cmd-status rl!
118;
119
120: ohci-reset ( -- failed? ) \ reset controller only
121 1 bit>command
122\ XXX can take up to 10 usecs before finishing reset
123\ but if it takes longer than 1 ms to go to operational state, devices
124\ on the bus can go into suspend state
125\ 1 ms \ wait 10 usec
126 chip-base hc-cmd-status rl@ 1 and \ 0 means done resetting
127;
128
129: control-filled ( -- ) 2 bit>command ;
130
131: bulk-filled ( -- ) 4 bit>command ;
132
133\ stuff bit, leaving the rest alone, in the interrupt status reg.
134: bit>int-status ( bit -- )
135 chip-base hc-int-status rl!
136;
137
138: clear-overrun ( -- ) 1 bit>int-status ;
139
140: clear-done-head ( -- ) 2 bit>int-status ;
141
142: clear-sof ( -- ) 4 bit>int-status ;
143
144: clear-bad-error ( -- ) h# 10 bit>int-status ;
145
146: clear-hub-change ( -- ) h# 40 bit>int-status ;
147
148: clear-interrupts ( -- )
149 chip-base hc-int-status rl@
150 chip-base hc-int-status rl!
151;
152
153: new-done? ( -- new-done? ) 2 chip-base hc-int-status rl@ and ;
154
155: new-sof? ( -- new-sof? ) 4 chip-base hc-int-status rl@ and ;
156
157\ XXX RIO reset-port disables the port. not good. or does it toggle enable?
158\ is it only lo-speed ports?
159\ enable-port anyway, even if it says it's enabled per OS init code.
160: clean-port ( port -- )
161 dup reset-port
162 dup enable-port
163 dup clear-connect-change
164 dup clear-port-reset
165 dup clear-port-suspend
166 clear-port-enable
167 clear-hub-change
168;
169
1700 value end-time \ used to sync wi. controller via next-frame
171
172: timed-out? ( -- timed-out? )
173 get-msecs end-time u> \ XXX problem when going thru 0
174;
175
176\ If wait-for-sof times out, the chip is not copasetic
177\ XXX throw from here; should publish some kind of error!
178: wait-for-sof ( -- )
179 get-msecs d# 10 + is end-time \ really should be only 1 ms
180 begin
181 new-sof?
182 timed-out? or
183 until
184;
185
186: wait-for-first-sof ( -- sof? ) \ used during power on
187 clear-sof
188 false \ assumes failure
189 d# 300 0 do \ wait up to 3 seconds
190 new-sof? if
191 drop true leave
192 then
193 10 ms
194 loop
195;
196
197: next-frame ( -- ) clear-sof wait-for-sof ;
198
199\ Stuff a new value into the fsmps field of fm-interval reg:
200: fsmps! ( n -- )
201 d# 16 lshift
202 chip-base hc-fm-interval rl@
203 dup 8000 and 8000 xor >r \ toggle bit needed later
204 h# 3fff and or
205 r> or
206 chip-base hc-fm-interval rl!
207;
208
209\ XXX need to bang control reg. cmd-status reg
210: start-controller ( -- ok? )
211 usb-reset
212\ make sure frameremaining field is not large (SOF tokens start on next
213\ transition)
214 usb-operational
215\ want to see SOF within 3 seconds here or something is fatally wrong:
216 wait-for-first-sof ( sof? )
217 dup 0= if
218 ." no usb SOF" cr
219 then
220 get-root-info
221 set-root-status
222\ sequence triggers port status change in RIO. it's magic and shouldn't
223\ be necessary, but it seems to get the chip more fully operational:
224 unpower-ports 2 ms \ 1 ms necessary; 2 to make sure
225 power-ports 4 ms \ 3 necessary
226\ set-root-port-status
227 clear-interrupts
228;
229
230\ must keep resume disabled.
231\ some control bits in the hub registers will keep specific ports from forcing
232\ resume.
233: stop-controller ( -- )
234 periodic-off isoc-off control-off bulk-off
235 next-frame
236 usb-suspend
237;
238
239\ set regs that have adjustable policy, that basically are touched only once
240: set-policy ( -- )
241\ h# 3e67 chip-base hc-period-start rl! \ XXX from manual; too long!
242\ h# 2a30 chip-base hc-period-start rl!
243\ give 20% to control/bulk, 80% to periodic:
244 h# 2580 chip-base hc-period-start rl!
245\ h# 628 chip-base hc-ls-threshold rl! \ 628 is reset value
246;
247
248\ Sometimes the HcFmInterval register will not hold it's value
249\ after the first write. This was seen primarily on the ULI 1575
250\ controller, but also reported on the 1535+.
251\ Loop on the write to ensure it has completed.
252: hc-fm-interval! ( data -- error? )
253 chip-base hc-fm-interval
254 d# 10 0 do
255 2dup rl!
256 2dup rl@ = if
257 leave
258 then
259 d# 10 ms
260 loop
261 rl@ <> dup if
262 cmn-error[ " Unable to write to HcFmInterval Register" ]cmn-end
263 then
264;
265
266\ Leave controller off:
267: set-regs ( -- error? )
268 0 chip-base hc-cmd-status rl!
269 h# c000.007f chip-base hc-int-disable rl! \ disable interrupts
270 clear-interrupts \ done later also; may not be needed here
271 dev-hcca chip-base hc-hcca rl!
272 dev-control-dummy dup \ empty control q
273 chip-base hc-control-head rl!
274 chip-base hc-control-current rl!
275 dev-bulk-dummy dup \ empty bulk q
276 chip-base hc-bulk-head rl!
277 chip-base hc-bulk-current rl!
278 0 chip-base hc-done-head rl! \ empty done q
279 h# a668.2edf hc-fm-interval! ( error? ) \ using 2668
280\ OS uses 2668:
281\ h# 2668 fsmps! \ XXX not here -- should calculate
282 set-root-hub
283;
284
285: toss-controller ( -- )
286 stop-controller dump-structs
287 unmap-regs
288;
289
290: init-controller ( -- ok? )
291 map-regs ohci-reset if \ reset failed error exit
292 ." usb reset failed" cr
293 false exit \ XXX throw is better?
294 then
295 make-structs
296 chip-base hc-control rl@ drop \ read, then write, per OS driver.
297 0 chip-base hc-control rl! \ does usb-reset and clears reg.
298 d# 100 ms \ wait here; nominally 10 ms; see comment on usb-reset
299 set-policy
300 set-regs if
301 dump-structs unmap-regs
302 false exit
303 then
304\ should start within 1 msec of ohci-reset?
305 start-controller
306;