On 9/20/2016 1:29 AM, Felipe Balbi wrote:
> John Youn <john.y...@synopsys.com> 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
>> * 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.
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html