From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <441B8AC8.3030904@austin.rr.com>
Date: Fri, 17 Mar 2006 22:21:28 -0600
From: Lonnie Mendez <lmendez19@austin.rr.com>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
MIME-Version: 1.0
To: 9fans@cse.psu.edu
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [9fans] question on implementation of uhci host controller driver
Topicbox-Message-UUID: 16ddf4f6-ead1-11e9-9d60-3106f5b1d025

Hello list.

While debugging plan 9's uhci usb stack in qemu I noticed that it
immediately issues a USBCMD command to Stop(0) the controller and then
expects hchalted bit in USBSTS to be set. Is this the proper thing to
do? No other stack I've seen seems to rely on this and it seems that
when they do it's after the uhci controller framing has been started.

Here is the beginning output from the qemu logs (port is the base I/O
register offset, 0x0000 is USBCMD, 0x0002 is USBSTS):
uhci writew port=0x0000 val=0x0000
uhci readw port=0x0002 val=0x0000
uhci readw port=0x0002 val=0x0000
uhci readw port=0x0002 val=0x0000
uhci readw port=0x0002 val=0x0000
<snipped - infinite loop ouput>

 From plan 9's uhci stack source:
http://cm.bell-labs.com/sources/plan9/sys/src/9/pc/usbuhci.c

from middle of function reset(Usbhost *uh)

OUT(Cmd, 0); /* stop */
while((IN(Status) & (1<<5)) == 0) /* wait for halt */

The UHCI specification when referencing setting the hchalt bit always
mentions doing this if the "transaction" has finished/completed.
Wouldn't that imply the R/S bit had been set previously?  Is this a
compliant operation or something I don't understand?