On Mon, 4 Feb 2008, Alan Nisota wrote: > I am trying to write a usb device driver for an R5000 modified > set-top-box. This just adds a USB interface to the decoded signal from > a satellite STB so you can save whatever is currently being watched on TV. > > I snooped the USB bus in Windows, and am able to upload the firmware and > communicate with the device just fine on endpoints 01 and 81. However, > retrieving the stream requires a high-bandwidth read on 82. If I do > this using blocking reads, the device never sends any data back It > appears to be waiting for multiple bulk request URBS in the queue.
You have phrased this badly. This device can't be waiting for multiple URBs in the queue because it has no way to be aware of individual URBs. All it knows about are the packets it receives. > This > apparently eliminates my ability to use libusb, so now I need to do the > same thing in kernel-space. Not at all. Even though libusb may not currently support it, the underlying usbfs ioctl calls allow you to do asynchronous I/O from userspace. > modifying usb-skeleton I've got a kernel module that does all of the > requests, however, now I keep getting babble errors when the > read-completion returns (EOVERFLOW) > > One thing I noticed is that endpoint 82 declares a max packet size of > 0x400 where I thought the largest allowed size for usb 2.0 is 0x200. That's the largest allowed size for bulk endpoints. However above you said that endpoint 0x82 uses high-bandwidth transfers, which implies it is either an interrupt or an isochronous endpoint. The maximum allowed packet size for isochronous endpoints is 1024, and for high-bandwidth transfers you can get an effective size up to three times bigger. > The requests from Windows also have a buffer size of 0x20000, but I > assume the driver is splitting that into smaller packets. > > I get the babble error regardless of the read-size I specify for the URB > request. > > Ok, so that is all the background info. > > I'm not sure whether I'm initializing something incorrectly, or if the > device is doing something odd. So I'm wondering if there is a way to > see the raw data that got returned for the URB even though it had a > babble error (I seem to always get a 0 len result, so I assume the > EOVERFLOW nukes whatever data might have been sent). this would help > determine where the problem lies. Just examine the URB's buffer. Any data you may have received should be stored there. The EOVERFLOW does not nuke any data. > Interestingly, the same libusb driver I did for linux (which can't read > the stream) works fine using win32-libusb on Windows. I'm assuming that > is a red-herring though, and has something to do with the Windows driver. > > > If it is useful, my read handler looks sort of like this: > urb = usb_alloc_urb(0, GFP_KERNEL); > buf = usb_buffer_alloc(dev->udev, readsize, GFP_KERNEL, > &urb->transfer_dma); > usb_fill_bulk_urb(urb, dev->udev, > usb_rcvbulkpipe(dev->udev, 0x82), > buf, readsize, skel_read_bulk_callback, dev); This implies that endpoint 0x82 is a bulk endpoint. So what type is it really? > urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP; > > retval = usb_submit_urb(urb, GFP_KERNEL); > usb_free_urb(urb); > > (there's a bunch of error checking and other stuff, but that's the guts > of it) I've tried all different values of readsize to no avail. Maybe the device really does try to send packets that are larger than the maximum allowed limit. That would explain your problems, especially if Windows doesn't bother to enforce the limit at all. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
