On 8/29/2016 11:26 AM, John Youn wrote:
> On 8/29/2016 12:33 AM, Felipe Balbi wrote:
>> John Youn <john.y...@synopsys.com> writes:
>>> On 8/26/2016 12:48 AM, Felipe Balbi wrote:
>>>> John Youn <john.y...@synopsys.com> writes:
>>>>> I was wondering if anyone is using the f_tcm function? Specifically
>>>>> for UAS in superspeed with streams? Any idea if it is being using in
>>>>> production for this anywhere?
>>>>> I've been trying to get the tcm gadget running without success. It
>>>>> seems I need to configure the target system via configfs and somehow
>>>>> interface it to this gadget. But I have not found any documentation or
>>>>> examples on how to get it working. Anyone have ideas or pointers?
>>>> Sebastian has posted his scripts here several times, it's in the
>>>> archives :-)
>>> I found some scripts before but none of them resulted in a working
>>> system. Though I did manage to get something semi-working
>>> eventually. It would still be nice to have some documentation about
>>> this part especially as I have no knowledge of the target side and no
>>> idea what those scripts are doing.
>> What do you mean by "semi-working"? How far did you get? Can you capture
>> tracepoints so we figure out what's wrong?
>> # mkdir -p /t
>> # mount -t tracefs none /t
>> # echo 8192 > /t/buffer_size_kb
>> # echo 1 > /t/events/dwc3/enable
>> (trigger issue)
>> # cp /t/trace ~/trace.txt
>> Send me trace.txt ;-)
>>>> 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).
* START_XFER command needs to enable streams
* XFER_NOT_READY event needs to be enabled for streams
* 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
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.
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.
>>> 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.
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