Re: Handling of bounce buffers by rh_call_control

[Richard Curnow]

Hi David,

* David Brownell <david-b@xxxxxxxxxxx> [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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/