On 9/20/2016 11:35 AM, John Youn wrote: > 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. > Hi Sebastian, Andrzej, If possible, could you share how you are using it? Such as in what speed, mode, and with what controllers/platforms and hosts? If you have any other tips on usage I would appreciate it. I'm looking into getting it working with our dwc3 controller, maybe also dwc2. 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
