EHCI refuses to own ports

[madeofstaples]

And did you check for EECP and if you need to negotiate control over the EHCI controller away from the BIOS?

Edit: I would also disable all USB interrupts for now, if your code is only polling for right now, so you can rule out any interrupt-related issues for certain...

Hah, polling? As I want to get a fully working async+interrupt transactions system, that'd be a downgrade .

What? Didn't you say you weren't working on the interrupt handlers yet?

Also, I'm trying now to get rid of BIOS(or whatever is keeping it from sending an IRQ) from UHCI, so I can make it work in VMware.

From UHCI?? I thought you wanted to use EHCI?

[eddyb]

And did you check for EECP and if you need to negotiate control over the EHCI controller away from the BIOS?

Edit: I would also disable all USB interrupts for now, if your code is only polling for right now, so you can rule out any interrupt-related issues for certain...

Hah, polling? As I want to get a fully working async+interrupt transactions system, that'd be a downgrade .

What? Didn't you say you weren't working on the interrupt handlers yet?

Also, I'm trying now to get rid of BIOS(or whatever is keeping it from sending an IRQ) from UHCI, so I can make it work in VMware.

From UHCI?? I thought you wanted to use EHCI?

To clarify it: interrupt transactions got absolutely nothing to do with interrupts. You don't get a IRQ if device "wants" to send data. Is simply an IN transaction which is in the periodic list(and most of the time it gives NAK).
Also, I was trying to get EHCI work, but I've found out that the UHCI driver doesn't work with VMware(I get no IRQ), so I want to fix it. How, beats me .

[neato]

Looks like interrupts are used, but for mainly errors, right? You wouldn't wait for an interrupt to know if your transaction is complete or anything right? You poll the STATUS register for that. You should take a look at UHCI11D again, mainly at Interrupts section. They give a few reasons why you might not be getting the interrupt. Furthermore, whats with all the determination to make it work perfectly in a VM? OCD or Likes Pain?

[madeofstaples]

Oh, ok I think I probably read something about interrupts, referring to the transfer type, and I thought it was referring to hardware interrupts to the CPU (i.e, IRQs). Yes, the USB subsystem would create the queue heads and transfer descriptors as per the device configuration so that the host controller expects/sends packets with the correct frequency. Software (device drivers) could set the Interrupt On Complete bit if it did want the host controller to issue an IRQ when a specific USB transaction has completed successfully. Note that the host controller driver should ensure that the PCI configuration space's Command register does not disable the host controller from asserting a hardware interrupt (bit 10 of the Command register should be 0).

Now, I'm not sure about UHCI, but I'm a little confused--I originally asked if EHCI was initialized before UHCI and I was told that you are only working with EHCI, now you're saying "I found out the UHCI driver was broken"--how? Unless the UHCI driver is, in fact, loaded, and possibly initializing the UHCI controller before EHCI?

If you're negotiating control from the BIOS, you may have to negotiate with the EHCI controller, as I described in this post.

[neato]

Software (device drivers) could set the Interrupt On Complete bit if it did want the host controller to issue an IRQ when a specific USB transaction has completed successfully.

You can't actually hook this interrupt, you poll for it. Is that correct?

Note that the host controller driver should ensure that the PCI configuration space's Command register does not disable the host controller from asserting a hardware interrupt (bit 10 of the Command register should be 0).

What hardware interrupt? Usage?

[madeofstaples]

Software (device drivers) could set the Interrupt On Complete bit if it did want the host controller to issue an IRQ when a specific USB transaction has completed successfully.

You can't actually hook this interrupt, you poll for it. Is that correct?

? No... eddyb has enabled all interrupts according to the OP:

...I coded the restart and basic register initialization (0x3f for USBINTR - meaning all interrupts enabled, even if get none - and 1 for CONFIGFLAG)...

If a transaction whose Interrupt On Complete bit was set is completed (or a short packet is received), EHCI's USBSTS register's least-significant bit reflects this fact (the USBINT field). On the next interrupt threshold, if the USBINTR register enables USB interrupts (as eddyb has set), and the USBINT field is set (as a result of completing the transaction or receiving a short packet, which is often a sign of the completion of a transaction, by the way), then the host controller issues a hardware interrupt on the PCI bus. The EHCI documentation covers all the events which may cause a hardware interrupt (if enabled) in section 4.15.

At first I (think I) misunderstood that eddyb didn't actually intend to handle interrupts (just yet), but is instead just trying to get some basic code working by polling the state of the USBSTS register for the same changes that would cause the host controller to issue an interrupt, if the corresponding interrupt is enabled by the uSBINTR register. So you can certainly implement EHCI support by polling these events, but the host controller certainly can raise interrupts for you, if you want.

Note that the host controller driver should ensure that the PCI configuration space's Command register does not disable the host controller from asserting a hardware interrupt (bit 10 of the Command register should be 0).

What hardware interrupt? Usage?

See the PCI Local Bus Specification, revision 2.3; you may specifically notice (physical) page 14, which contains an implementation note regarding interrupt routing.

[neato]

The spec says it is optional just as I suspected, so you can still set IOC and poll for it without the need for the hardware interrupt and basically come up with the same result as if you were waiting for the interrupt, correct? I just want to make this crystal clear so that I can understand exactly why I am not doing it that way. lol

Finally, please correct me if I am wrong again, but you would not want to set the Interrupts in general unless you are interfacing with HID.

[madeofstaples]

The spec says it is optional just as I suspected

Please be a little more specific. It's hard to tell if you're thinking about things correctly--I assume from context that you are looking at the EHCI specifications, but what, exactly are you looking at when you say "it is optional"?

so you can still set IOC and poll for it without the need for the hardware interrupt and basically come up with the same result as if you were waiting for the interrupt, correct?

Y.. yes, I think you have it right in that you do not need to use hardware interrupts. By disabling the host controller from issuing hardware interrupts via the USBINTR register (and for good measures, in the PCI configuration space's Command register), it will still update the fields of the USBSTS register, which you can poll and simply wait for a certain change--this lends itself to a more procedural style implementation than an object-oriented or just modular implementation. Depending on how much your OS has configured (and how much it has left with the BIOS's original configuration), you may need to pay attention to how/if the CPU will cache access to the EHCI's memory-mapped registers. You don't want your code to read the same (cached) value indefinitely!

I just want to make this crystal clear so that I can understand exactly why I am not doing it that way. lol

I can't tell if you're saying that you already have a pretty good idea, but you just want to be sure why polling wouldn't be the greatest implementation, or if you're saying that the two methods seem equivalent so you're confused as to why one would want to use and interrupt-based implementation over a polling-based one?

Finally, please correct me if I am wrong again, but you would not want to set the Interrupts in general unless you are interfacing with HID.

This is wrong... Why are you under this impression? I hope it's not just because of the common use of the word "interrupt" (e.g, "interrupt transaction" and "interrupt request" doesn't mean these two things go hand-in-hand!).

[neato]

The spec says it is optional just as I suspected

Please be a little more specific. It's hard to tell if you're thinking about things correctly--I assume from context that you are looking at the EHCI specifications, but what, exactly are you looking at when you say "it is optional"?

Well, the OP is going back and forth between UHCI and EHCI and he seems stuck now on UHCI and that's where I am at, so I am speaking of UHCI 1.1. In that specification, it says that IRQs are optional.

This is wrong... Why are you under this impression? I hope it's not just because of the common use of the word "interrupt" (e.g, "interrupt transaction" and "interrupt request" doesn't mean these two things go hand-in-hand!).

When I am talking about "interrupt", I am talking about polling for the IOC bit to get set after a transaction completes. This thread is getting confusing for us all.

[eddyb]

The spec says it is optional just as I suspected

Please be a little more specific. It's hard to tell if you're thinking about things correctly--I assume from context that you are looking at the EHCI specifications, but what, exactly are you looking at when you say "it is optional"?

Well, the OP is going back and forth between UHCI and EHCI and he seems stuck now on UHCI and that's where I am at, so I am speaking of UHCI 1.1. In that specification, it says that IRQs are optional.

This is wrong... Why are you under this impression? I hope it's not just because of the common use of the word "interrupt" (e.g, "interrupt transaction" and "interrupt request" doesn't mean these two things go hand-in-hand!).

When I am talking about "interrupt", I am talking about polling for the IOC bit to get set after a transaction completes. This thread is getting confusing for us all.

1. Because I can't get neither of them to touch my transfer descriptors(i managed to get error IRQs if i write wrong pointers to TDs)
2. HC doesn't touch IOC. *You* set it if you want to get an IRQ. You can poll the active bit, it gets unset if the transaction was successful(and no, it wasn't in my case, the HC is blind).

[neato]

USB Interrupt (USBINT). The Host Controller sets this bit to 1 when the cause of an interrupt is a
completion of a USB transaction whose Transfer Descriptor had its IOC bit set.

That is IOBASE+0x02 or STATUS register. You poll bit0 to get set to know when the transaction is complete. If you enabled IOC interrupts and set the IOC bit in the STATUS TD.

[eddyb]

USB Interrupt (USBINT). The Host Controller sets this bit to 1 when the cause of an interrupt is a
completion of a USB transaction whose Transfer Descriptor had its IOC bit set.

That is IOBASE+0x02 or STATUS register. You poll bit0 to get set to know when the transaction is complete. If you enabled IOC interrupts and set the IOC bit in the STATUS TD.

That bit is USBINT. And it's pretty dumb to poll it, because if it gets set, you'll get an IRQ.
My problem now is that I can't get the HC to touch the (q)TDs... the link to it exists, but the HC ignores it... if I set a wrong link, I get an error(with UHCI). About the same thing on realHW with UHCI, just that instead of passing by, it gives a Host System Error.

[neato]

That bit is USBINT. And it's pretty dumb to poll it, because if it gets set, you'll get an IRQ.

Not if you do not hook the IRQ. It's a better way to know when the transaction is complete, rather than your suggested solution which was to poll the "active" bit which I guess is supposed to mean b0 of the COMMAND register. How is that any smarter? That bit is cleared on errors too, it doesn't mean the transaction was a success.

The HC Halted bit in the status register indicates when the Host Controller has finished the transaction and has entered the
stopped state.

USBINT gets set and then HC Halted gets set. Read STATUS for errors, if none then it should have worked.

My problem now is that I can't get the HC to touch the (q)TDs... the link to it exists, but the HC ignores it... if I set a wrong link, I get an error(with UHCI). About the same thing on realHW with UHCI, just that instead of passing by, it gives a Host System Error.

The Host Controller sets this bit to 1 when a serious error occurs during a host
system access involving the Host Controller module. In a PCI system, conditions that set this bit to 1
include PCI Parity error, PCI Master Abort, and PCI Target Abort. When this error occurs, the Host
Controller clears the Run/Stop bit in the Command register to prevent further execution of the
scheduled TDs. A hardware interrupt is generated to the system.

You're getting that error, that's probably why.

[eddyb]

That bit is USBINT. And it's pretty dumb to poll it, because if it gets set, you'll get an IRQ.

Not if you do not hook the IRQ. It's a better way to know when the transaction is complete, rather than your suggested solution which was to poll the "active" bit which I guess is supposed to mean b0 of the COMMAND register. How is that any smarter? That bit is cleared on errors too, it doesn't mean the transaction was a success.

The HC Halted bit in the status register indicates when the Host Controller has finished the transaction and has entered the
stopped state.

USBINT gets set and then HC Halted gets set. Read STATUS for errors, if none then it should have worked.

My problem now is that I can't get the HC to touch the (q)TDs... the link to it exists, but the HC ignores it... if I set a wrong link, I get an error(with UHCI). About the same thing on realHW with UHCI, just that instead of passing by, it gives a Host System Error.

The Host Controller sets this bit to 1 when a serious error occurs during a host
system access involving the Host Controller module. In a PCI system, conditions that set this bit to 1
include PCI Parity error, PCI Master Abort, and PCI Target Abort. When this error occurs, the Host
Controller clears the Run/Stop bit in the Command register to prevent further execution of the
scheduled TDs. A hardware interrupt is generated to the system.

You're getting that error, that's probably why.

First, don't come to me with quotes, I know to read myself and i always have the UHCI pdf open.
Second, if you like your UHCI11D.PDF so much, active is a bit in TD.... You were talking about RUN in the command register. And wasn't a suggestion, i just gave you the correct bit in TD( ).
Third, ....(you know it...).

What I need now is to know how linux manages to get over the things *unmentioned* in the specs(I didn't try to check if there's some white on white writing, but I doubt so).
If that's not enough:

And as for hardware, usually the developers take shortcuts to reduce cost of production

[XanClic]

That bit is USBINT. And it's pretty dumb to poll it, because if it gets set, you'll get an IRQ.

Not if you do not hook the IRQ. It's a better way to know when the transaction is complete, rather than your suggested solution which was to poll the "active" bit which I guess is supposed to mean b0 of the COMMAND register. How is that any smarter? That bit is cleared on errors too, it doesn't mean the transaction was a success.

What do you mean with "hooking an IRQ"? Having an IDT entry? An ISR? A correctly cofigured interrupt controller, be it the PIC, be it LAPIC and I/O-APIC?
I once got a UHCI driver which was at least capable of stalling an endpoint on real hardware and it made use of the IOC. And, no, I didn't "hook" anything explicitly. I simply setup an ISR and activated all interrupts.

But I have to add that I never tested this driver on VMware.


But all in all, I agree to eddyb: Polling is a really bad idea on USB, because it's not hard to setup an ISR (I think it's even harder to simply poll).