From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <0fea342da51a133c78f83c73175a64ee@terzarima.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] question on implementation of uhci host controller driver From: Charles Forsyth Date: Sat, 18 Mar 2006 07:50:45 +0000 In-Reply-To: <441B8AC8.3030904@austin.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 1721f2c8-ead1-11e9-9d60-3106f5b1d025 > 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 underst and? 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.