On Tue, 23 Mar 2004, Malcolm Blaney wrote:
> FWIW, the new patch gives:
> uhci irq status: 0x24
> usb 1-1: new full speed USB device using address 2
> uhci enqueue: cdb1a2a0
> Before enabling uhci fsbr
> Immediately after enabling uhci fsbr
> 3 ms after enabling uhci fsbr
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.
> I've been trying to follow how far the code runs from the previous patch
> you sent. As far as I can tell, the first time uhci_inc_fsbr() is called
> is in uhci_submit_control(), and it returns quite happily here. It then
> returns to uhci_urb_enqueue() as well. Here, I can't get past the
> spin_unlock_irqrestore() at the end of this function. I figure this is
> when it gives up control of the cpu, so something else gets control and
> then it all locks up. I can't event step past the line using kgdb.
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.
> So I'm trying to find out how setting uhci->skel_term_qh->link to the
> dma_handle changes how the code runs, but am struggling to find good
> documentation? I'm sure someone's just going to say the code is the best
> place to look though... :)
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.
What's going on is this. uhci->skel_term_qh is the last QH (Queue Header)
in the schedule set up by the driver for use by the controller hardware.
Normally the ->link field is set to UHCI_PTR_TERM, which indicates this is
the end of the schedule.
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. Setting ->link to
cpu_to_le32(uhci->skel_hs_control_qh->dma_handle) | UHCI_PTR_QH
accomplishes that. It stores the full-speed control QH's DMA address
(whoops, I need to rename skel_hs_control_qh to skel_fs_control_qh),
converted to little-endian format, together with a flag bit indicating
that the link field points to another QH rather than a TD.
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
