From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <441BC014.5060003@austin.rr.com> Date: Sat, 18 Mar 2006 02:08:52 -0600 From: Lonnie Mendez User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] question on implementation of uhci host controller driver References: <0fea342da51a133c78f83c73175a64ee@terzarima.net> In-Reply-To: <0fea342da51a133c78f83c73175a64ee@terzarima.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 172e7fde-ead1-11e9-9d60-3106f5b1d025 Charles Forsyth wrote: Morning. Thanks for checking the mail. > >The 1.1 Revision says of the RS bit: > > When set to a 1, the Host Controller proceeds with execution of the > schedule. The Host Controller continues execution as long as this bit > is set. When this bit is set to 0, the Host Controller completes the > current transaction on the USB and then halts. The HC Halted bit in > the status register indicates when the Host Controller has finished > the transaction and has entered the stopped state. ... > >the description of HCHalted is consistent with that, >and there are several examples (eg, in the section describing software debug mode) >that suggest clearing the stop bit and waiting for halt. > >you're suggesting that this should be read as ``provided the bus has been used at least >once after reset, otherwise both bits are zero, and setting RS to zero will do nothing'', >or at least that the qemu people took it that way (or perhaps some chip implementation does so). >the wait could certainly be made conditional on the RS having been set. > >by coincidence i got up early this morning to try to see how far the OHCI >driver would get, but fairly typically started this displacement activity with email. > You're correct, the software debug mode does reference the hchalted bit... but in that reference it seems to support that fact that hchalted shouldn't be set unless the stack has come out of Run/Stop state bit being set. Of course this doesn't explain why it works on physical hardware. To Enter Software Debug Mode: 1. HCD puts Host Controller in Stop state by setting the Run/Stop bit to 0. 2. HCD pus Host Controller in Debug Mode by setting the SWDBG bit to 1. 3. HCD sets up the correct command list and Start Of Frame value for starting point in the Frame List.Single Step Loop: 4. HCD sets Run/Stop bit to 1. 5. Host Controller executes next active TD, sets Run/Stop bit to 0, and stops. 6. HCD reads the USBCMD register to check if the single step execution is completed (HCHalted=1). 7. HCD checks results of TD execution. Go to step 4 to execute next TD or step 8 to end Software Debug mode. 8. HCD ends Software Debug mode by setting SWDBG bit to 0. 9. HCD sets up normal command list and Frame List table. 10. HCD sets Run/Stop bit to 1 to resume normal schedule execution. qemu doesn't handle the R/S and hchalted bits yet. I'm just trying to clean up qemu's usb code and understand things along the way.