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? > * 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. > 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? We'd be much better off fixing these problems because then more folks would benefit from them. > Even the BOT interface does not work reliably. > > When I get a chance, I'll try to get everything running again rebased > on latest, then submit patches and bug reports. cool, thanks a lot. That'll help >>>> But just in trying to get it to work, these issues make me suspect no >>>> one is using this driver in superspeed, or at least regularly testing >>>> it, let alone using it in production. >>> >>> that's probably true, but it's not enough argument to have a duplicate >>> implementation of it :-) Rather, we should be figuring out what's broken >>> and fixing it. I have a ton of other stuff to be done, but I'll add this >>> to my queue, no issues. >>> > > Let me know if you make any progress on this. sure thing :-) If you got some notes on how, exactly, you got TCM running, I'd be happy to re-use them and try things out here. -- balbi
Attachment:
signature.asc
Description: PGP signature
