On Wed, 24 Mar 2004, Malcolm Blaney wrote: > Alan Stern wrote: > > Interesting. This weighs against the hypothesis of a hardware problem > > (device monopolizing the PCI bus, for example). Even 3 ms after FSBR was > > turned on the system was still operational. > > This might be a stupid question, but what else can happen during this > time? Now that you've set this in the uhci, do other threads/processes > have access to it? Is it that other URB's are being processed and so see > the newly updated state of the uhci?
According to the log that you sent, _nothing_ else happened during this time or later as far as the UHCI driver was concerned. The patch added printk() statements to all the important entry points in the driver and none of them was triggered after FSBR got turned on. > > You need more than code documentation; you need to understand how UHCI > > controllers work! It doesn't change how the code runs at all -- it > > changes how the controller behaves. > > Isn't the controller just code, so changing how it behaves means the > code is running differently with fsbr set? Your questions show that you don't really understand. No, the controller _isn't_ just code. It's a real, physical chip (or part of a chipset). It's a piece of hardware, separate from the CPU. To learn more about how UHCI devices work, go to this page: http://developer.intel.com/design/USB/UHCI11D.htm > > If it helps, I can tell you that uhci_urb_enqueue() is called through a > > function pointer from within hcd_submit_urb() in drivers/usb/core/hcd.c. > > It's the line just before the "done:" label in that routine. In turn, > > hcd_submit_urb() is called through a function pointer from the last line > > of usb_submit_urb() in drivers/usb/core/urb.c. > > I got that far, but working out where usb_submit_urb() gets called seems > a bit harder, and I don't think I need to find that out? I can't be certain, but in all likelihood the URB you're looking at was submitted by the usb_start_wait_urb() routine in drivers/usb/core/message.c. > It seems to me > that the urb that got me to uhci_urb_enqueue() has been finished with, > since the only thing it can't do is return from spin_unlock_irqrestore. > So I am trying to find what happens next. No, the URB hasn't been finished with. In fact, it's just starting. The part you traced through is where the driver accepts the URB and gives it to the controller. After that the controller has to send it out over the USB bus and get the device's reply back. The the driver has to complete processing the URB and hand the completed URB back over to the original submitter. > > When FSBR is turned on, we want the controller not to stop when it reaches > > the end of the schedule, but instead to go back to the point in the > > schedule where the full-speed control queues are stored and continue > > running from there. > > Is this schedule contolled at a software level? The schedule is controlled partly through software (the UHCI driver) and partly through hardware (the UHCI controller). The document on the web page I mentioned above contains the details. > Does the URB that was > queued above get processed at this point? Also, do the queues get > processed in response to the various USBINTR_* interrupts turned on in > start_hc()? I'm trying to find how queueing a urb and processing a urb > are connected. The interrupts generally get sent to indicate that the controller has finished doing its work on the URB. When that happens it's time for the driver to take over. The general outline is this: Some program or driver submits an URB through uhci_urb_enqueue(). The UHCI driver takes the URB and adds it into the schedule, then returns. The UHCI controller, seeing the URB now in the schedule, follows the commands listed in the schedule. It sends the URB out to the USB device and receives a response in return. The response is stored in the URB's transfer buffer. The UHCI controller signals an interrupt request when the schedule tells it to do so (when the response to the URB has been received and stored). The UHCI driver fields the interrupt (uhci_irq()), sees that the controller is done with the URB, tidies everything up, and gives the URB back to the original submitter by calling the URB's completion routine. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
