On Wed, 5 May 2004 [EMAIL PROTECTED] wrote: > Alan Stern <[EMAIL PROTECTED]>@lists.sourceforge.net wrote: > > > >No. The controller notifies the driver by an interrupt and the driver > >starts the controller. However, connection status detection works even > >when the controller is halted. In fact, it is connection status detection > >that _causes_ the controller to raise the interrupt request. > > Then can you point me to what routine in what file, is responsible for > receiving the interrupt and then starts the controller.
Sure. uhci_irq() in drivers/usb/host/uhci-hcd.c receives the interrupt and sets uhci->resume_detect to 1. Then hc_state_transitions() in the same file sees uhci->resume_detect and calls wakeup_hc() to restart the controller. > The first thing > to prove is that the interrupt never happens. Then to figure out why. I can tell you why. No interrupt happened because the controller didn't request one, because it never realized that anything was connected to the port. But if you want to investigate more closely, please do so. > Could this be related to acpi? If so, what can we look at? > I tried booting the kernel with acpi=off, but again... no effect. If the controller doesn't generate an interrupt, it doesn't matter what the ACPI settings are. And even if it does generate an interrupt and the driver restarts it, if it can't detect the new connection you won't be able to communicate with the device. > I was reading a little last night in the Intel ICH4 chip manual, about the > 'halt' state and that the controller needs to be 'reset' and given a > timeout before continuing. > Where is this code (what routine/file)? Because I'd like > to fix it/get it fixed, but I need help/direction from the USB driver > gurus. :-) You must be simplifying what the manual says. But anyway, the routines you're interested in are reset_hc(), suspend_hc(), wakeup_hc(), start_hc(), and uhci_reset(). You might also want to look at a couple of other routines in the same region of the source file. > What is the relationship between?: > uhci-hub.c, uhci-hcd.c, > ehci-hub.c, ehci-hcd.c > hub.c and hcd.c The first two are parts of the UHCI controller driver. The second two are parts of the EHCI controller driver. The last two are the hub driver and part of a "glue" layer that goes between the controller drivers and the rest of the USB core. There's no direct relation between hub.c and the others. The controller drivers are managed by hcd-pci.c, which is closely tied to hcd.c. Requests from other software components filter in to the controller drivers through either hcd.c or hcd-pci.c. That reminds me of something I wanted to ask you about: Do you have an EHCI controller on your computer as well as UHCI? If you do, you could try loading the ehci_hcd driver (if it's not already loaded) or unloading it (if it is). It's possible that the EHCI controller is causing your problem. The way it works is, a new device is connected first to the EHCI controller, which only works at high speed. If the controller determines that the device is full speed or low speed, it hands the device over to a "companion" UHCI controller. If the handoff failed for some reason, your symptoms would be the expected result. > I know its a big thing to ask, but ?is? there a high level flow diagram > of how the Linux USB driver thing/family is supposed to work and what > software/sobroutines performs what part of that flow? Not really. There is _some_ documentation available through http://www.linux-usb.org. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
