[9fans] question on implementation of uhci host controller driver

[9fans] question on implementation of uhci host controller driver

[Lonnie Mendez]

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?

Re: [9fans] question on implementation of uhci host controller driver

[Charles Forsyth]

> 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.

Re: [9fans] question on implementation of uhci host controller driver

[Lonnie Mendez]

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.

Re: [9fans] question on implementation of uhci host controller driver

[Charles Forsyth]

> being set.  Of course this doesn't explain why it works on physical
> hardware.

probably because the bit reflects the state of the frame processor,
so that the bit is set iff it is halted, regardless how it came to be that way
(which is what i'd expected, and indeed  i believe that bit is set after reset).
it's a reasonable way to do the hardware, but software probably just
memsets an emulated register to 0 and doesn't set the bit initially.

Re: [9fans] question on implementation of uhci host controller driver

[Lonnie Mendez]

Charles Forsyth wrote:

>>being set.  Of course this doesn't explain why it works on physical
>>hardware.
>>
>>
>
>probably because the bit reflects the state of the frame processor,
>so that the bit is set iff it is halted, regardless how it came to be that way
>(which is what i'd expected, and indeed  i believe that bit is set after reset).
>it's a reasonable way to do the hardware, but software probably just
>memsets an emulated register to 0 and doesn't set the bit initially.
>
   Hm.  The initial (default) value for USBSTS register is 0.  Looking
at HCRESET it states that "the Host Controller module resets its
internal timers, counters, state machines, etc to their initial value."
GRESET does something similar.  If the initial value isn't the default
value then I'll be understanding this a whole lot better.  For
comparison, here is the initial take from windows xp's uhci driver:

uhci readw port=0x0000 val=0x0000
uhci writew port=0x0000 val=0x0004
uhci writew port=0x0000 val=0x0000
uhci writew port=0x0004 val=0x0000
uhci readw port=0x0000 val=0x0000
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

Re: [9fans] question on implementation of uhci host controller driver

[Charles Forsyth]

>  If the initial value isn't the default
> value then I'll be understanding this a whole lot better.

yes, having checked the spec again i see what you mean.
i'm not sure, then.  if i have a spare moment when working on the ohci
i'll see what is in the uhci registers after a reset.

Re: [9fans] question on implementation of uhci host controller driver

[Lonnie Mendez]

Charles Forsyth wrote:

>> If the initial value isn't the default
>>value then I'll be understanding this a whole lot better.
>>
>>
>
>yes, having checked the spec again i see what you mean.
>i'm not sure, then.  if i have a spare moment when working on the ohci
>i'll see what is in the uhci registers after a reset.
>
    I added a debug statement to show the initial value set in the uhci
probe function under linux.  This is displayed before the hcd ever
touches the registers:

uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: detected 2 ports
uhci_hcd 0000:00:1d.0: uhci_check_and_reset_hc: sts = 0x0020
uhci_hcd 0000:00:1d.0: uhci_check_and_reset_hc: cmd = 0x0000

   Sure enough the status register has hchalted bit set.  I'm not sure
if the bios does this or the firmware on the uhci controller.  I'll
submit a patch for qemu to make it more realistic (and so plan9 boots
with -usb parameter).

Most of my patches for qemu are linked here:
http://gnome.dnsalias.net/patches/

Re: [9fans] question on implementation of uhci host controller driver

[Charles Forsyth]

> 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.

i discovered when i resumed work yesterday that
it might have been better to continue the displacement activity.
it turned out to be cardbus not OHCI that was misbehaving.
it's the usual problem with the pc architecture:
``due to the miracles of the bus, it's possible to get [so]
far and still be talking to a slot full of nothing''.
just amazing.