Hi Felipe, On Tue, Mar 25, 2014 at 08:45:11PM -0500, Felipe Balbi wrote: > > + for (num = 0; num < dwc->num_in_eps; num++) { > > + struct dwc3_ep *dep = dwc->eps[(num << 1) | 1]; > > Just add a comment here stating that bit0 is the direction bit, just so > we don't forget in the future. Ok, will do. > One question, out of curiosity: > > do you *really* need to enable tx-fifo-resize ? I thought OMAP5 ES1.0 > was the only brainfart with FIFO setups which wouldn't even fit a single > USB3 packet :-p > > Sure your patch is correct, and will be applied soonish, but if you > don't need to resize fifos, you might want to avoid it. Just curious. Yes, although our FIFO RAM is certainly larger than a USB3 packet :-), we do have one use case of a high-bandwidth debugging trace function, which when enabled consumes at least half of that FIFO for its own buffer usage. If it's combined in a composite gadget with other functions (such as RNDIS) we found we had to enable tx-fifo-resize in order to get the core to conservatively allocate the remaining memory for the rest of the endpoints. The only way to avoid needing tx-fifo-resize is if this HW trace function gets its own memory instead of sharing the FIFO with USB but unfortunately our current SoCs have it sorta hardwired this way. > ps: can you guys, please, just send your dwc3 glue layer ? :-) Ivan Ivanov (cc'ed) had sent a number of patches for our "dwc3-msm" layer to the list for review, but I think they were still held up in the feedback process. Ivan, what is the status of this? Thanks, Jack -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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