On Tue, 26 Jan 2016, Doug Anderson wrote: > > This probably indicates that the list of patches was incomplete (i.e., > > some other patches were applied before these). Also, the patches > > aren't listed in order of the patchwork IDs -- which order is correct? > > The order like 01, 02, 03, etc is correct. Patchwork numbers things > in a random order (depending on the vagaries of SMTP and which one > arrives to their server first). > > Ah, I had tried linux/master recently, but that has a patch that's not in v4.4: > > fbb9e22b15ad usb: dwc2: host: enable descriptor dma for fs devices > > > I'd bet that you don't have descriptor DMA turned on anyway, so the > descriptor DMA patches won't really matter (they'll just be noops). > ...but you could pick all the patches up to that one to avoid > conflicts. > > fbb9e22b15ad usb: dwc2: host: enable descriptor dma for fs devices > 762d3a1a9cd7 usb: dwc2: host: process all completed urbs > 3f808bdae75e usb: dwc2: host: always increment available host channel > during release > c17b337c1ea4 usb: dwc2: host: program descriptor for next frame > b9392d9920fd usb: dwc2: host: add function to compare frame index > 2b046bc5aaef usb: dwc2: host: spinlock release channel > 26a19ea69906 usb: dwc2: host: fix use of qtd after free in desc dma mode > c503b3815385 usb: dwc2: host: rework isochronous halt path > dde4c1bf5df0 usb: dwc2: host: set active bit in isochronous descriptors > 3ac38d260fa5 usb: dwc2: host: ensure filling of isoc desc is correctly done In the end I just used the contents of the dwc2 directory from Linus's current tree -- I don't think it has changed since 4.5-rc1. Your patches applied on top of that with no issues. They seem to work. Is there anything in particular you would like me to test? One problem I noticed: The controller does hub status polling to an external high-speed hub much too frequently. The interrupt endpoint's bInterval value is 12, meaning the polling interval should be 256 ms. But when data was available, the polls were issued every 2 microframes instead of every 2048. Could the driver be rescheduling the interrupt endpoint every time an URB completes and a new one is submitted? That's what it looks like. This might be related to the giving-URBs-back-in-a-tasklet change. Alan Stern -- 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
