Re: [RFC] xhci: Let completion handlers run before rings are restarted.
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Hi, On 06/07/2012 06:59 PM, Sarah Sharp wrote:
On Thu, Jun 07, 2012 at 11:29:27AM -0400, Alan Stern wrote:On Thu, 7 Jun 2012, Hans de Goede wrote:So that leaves the question whom is going to code up this solution, I see 3 possible candidates: Alan, Sarah or Hans (aka me). So any volunteers?I'm pretty busy with other things, so I prefer not to volunteer just now.I'm working on adding USB 3.0 Latency Tolerance Messaging support, so I don't have time to work on this until September (after the 3.6 merge window and Kernel Summit). If people want this fixed sooner, I guess Hans needs to volunteer to do it. I'm happy to review changes, of course.
Hmm, and here I was trying to follow the well known "never volunteer" advice, guess that didn't get me anywhere this time :) So I'll put this on my todo list then. One question about the imlementation though. I plan to first add a USBDEVFS_GET_CAP ioctl, I was planning on making the results of this ioctl device independent (iow only kernel version dependent), but with this new plan I think it may make sense to have the results be device dependent (well really hc dependent, but the user deals with a device). The reason for this is the question, what to do if the hc is not sg capable, in that case currently things will work fine when using libusb (which most userspace apps should be using), because libusb divides large bulk transfers into 16k urbs, using the USBDEVFS_URB_BULK_CONTINUATION flag. Once we move to a model where devio.c can handle large bulk transfers by dividing them into chunks itself and putting those on an sg list, and add a capability flag for this, then what is devio.c to do if a large bulk transfer gets submitted to a non sg capable hc? My pov on this is simple: "don't do that you silly". IOW userspace should not be sending large bulk transfers to a non sg capable hc. I don't think there are currently any use cases where that may already be happening, but some libusb users may be doing just that. So the easiest way to achieve this never happening (with libusb apps) is to make the capabilities per device, and not set the USBDEVFS_CAP_SG flag on devices which are connected to a non sg capable host. A note about the USBDEVFS_CAP_SG name, I plan to also add a USBDEVFS_CAP_UNLIMITED_URB_SIZE flag, which in essence will advertise the lifting of the urb size limits done in this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=add1aaeabe6b08ed26381a2a06e505b2f09c3ba5 But as discussed before just because there is no limit does not mean that submitting a 4 MB transfer in one urb is a good idea, now once we get the sg support into devio.c, it becomes a good idea, but only on devices which are attached to an sg capable hc. So the idea is for the logic in libusb to be: if (caps & (USBDEVFS_CAP_UNLIMITED_URB_SIZE|USBDEVFS_CAP_SG) == (USBDEVFS_CAP_UNLIMITED_URB_SIZE|USBDEVFS_CAP_SG)) /* do transfer in one urb */ else /* split transfer */ Before I start working on this it would be good to hear back from you on the sanity of these details as proposed. Thanks & Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
[Linux Media] [Video for Linux] [Linux Input] [Linux Audio Users] [Photo] [Yosemite News] [Yosemite Photos] [Free Online Dating] [Linux Kernel] [Linux SCSI] [Old Linux USB Devel Archive] [More Archives]