On 9/20/2016 1:29 AM, Felipe Balbi wrote: > > Hi, > > John Youn <John.Youn@xxxxxxxxxxxx> writes: >>>>>> There's also a TCM python tool somewhere which helps with this. I >>>>>> haven't used f_tcm in a long while, but Sebastian and I used it long >>>>>> back to test streams with dwc3. >>>>> >>>>> Have you tried it recently? Or do you know of anyone who has? >>>> >>>> Sebastian is the only one I know who has used this in the past. >>>> >>>>>>> Just from the code it seems there will be some fundamental issues with >>>>>>> it, such as the value of maxpacket size and some alt-interface >>>>>>> stuff. At least when used with DWC3. >>>>>> >>>>>> such as? >>>>> >>>>> I'll see if I can write up the exact issues later. I have to go back >>>>> to my notes to remind myself. >> >> Ok, coming back to this uas gadget stuff. >> >> I've finally had a chance to go back to my notes. Here are some of the >> concrete issues that I found, that I was able to workaround in some >> way. >> >> * EP's for UAS alt-interface cannot be configured correctly because >> the config_ep_for_speed() in composite.c does not take into account >> alt-interfaces. This results in incorrectly configured EP in the >> controller (no streaming enabled, wrong direction, etc). > > cool, that's a bug in composite.c which needs to be fixed. > >> * START_XFER command needs to enable streams > > bug in dwc3 which needs to be fixed. > >> * XFER_NOT_READY event needs to be enabled for streams > > bug in dwc3 which needs to be fixed :-) In any case, can you point me to > section in documention which states Streams *requires* XFER_NOT_READY? It should be the same as used for BULK. Maybe it's not needed with your recent enhancements? Not sure. I have to rebase and test. > >> * For OUT EPs, the TCM/target framework sets receive buffers size as >> 512 bytes. This cannot work in SUPERSPEED as you must always provide >> at least MPS-sized buffers. This causes all writes to fail. I'm not > > that's a good point. TCM gadget should be checking for ep out aligned > quirk flag. Is this an existing quirk? It's not just about alignment, but the size of the rx buffer, which it should know based on the MPS for the speed. > >> sure how to properly fix this as it should be fixed at the function >> driver level, and this size comes from the target framework. I put a >> workaround at the controller-level. >> >> After addressing these issues, UAS read/write works to some extent. >> But it is still unstable in ways that point to issues in the target >> framework, things to do with locking/race conditions there. > > Alright, those are all bugs which need to be fixed. Certainly we don't > need an entire new gadget just because you've found some bugs, right? > Sure. I was just curious if there was any interest in it since we have an existing driver we could port. > We'd be much better off fixing these problems because then more folks > would benefit from them. Agree if it was working and being used in the first place. But anyways I'll focus on TCM. Regards, John -- 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
