Messages in this thread | | | Date | Thu, 18 Dec 2003 14:32:36 +0000 | From | Richard Curnow <> | Subject | Re: Handling of bounce buffers by rh_call_control |
| |
Hi David,
* David Brownell <david-b@pacbell.net> [2003-12-17]: > > > > if (bufp) { > > if (urb->transfer_buffer_length < len) > > len = urb->transfer_buffer_length; > > urb->actual_length = len; > > // always USB_DIR_IN, toward host > > memcpy (ubuf, bufp, len); > > Which is why that particular patch is wrong: "ubuf" is a dma address, > not expected to work for memcpy().
Sure, I didn't expect the patch was general but it was enough to make things work on the platform I'm currently trying to port to, and it illustrated the problem I was hitting.
> >in the case where bounce buffers are being used to implement PCI DMA > >operations. Without the patch, the subsequent pci_unmap_single copies > >the contents of the bounce buffer over the top of urb->transfer_buffer, > >destroying what the memcpy() put there. > > A similar bug was fixed in 2.6 by a patch from Russell King. I think > the 2.4 version has lingered since it only affect EHCI, and most folk > using EHCI won't use bounce buffers.
I just happened to have EHCI compiled in and put a USB 2 card into the board. The problem meant that the EHCI initialisation wouldn't even complete, so I waded in to find out why.
IIRC, if I plug a USB2 device into a USB2 card but don't have the EHCI driver active, the device is just ignored, rather than falling back to using USB1.1 through OHCI? We certainly have some USB2 devices we'd like to use, even if the USB2 bandwidth might be throttled back by the bounce buffering overhead.
> Could you look at that patch (bk revtool or bkweb will show it, early > September 2002) and provide a 2.4 version?
I'll dig that out, if it's simple enough to backport I'll see if I can take a stab at it.
> What changed in 2.6 was that hcd_submit_urb() has a special case for > the root hub. That's always PIO, so the code now bypasses all the > DMA mapping code when an URB is destined for a root hub.
That seems like the right approach.
Cheers Richard
-- Richard \\\ SH-4/SH-5 Core & Debug Architect Curnow \\\ SuperH (UK) Ltd, Bristol - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |