On 2/5/2016 6:30 AM, B, Ravi wrote: > Hi Felipe > > Sorry for delay in response. > >>> Yes, when there is on-going transfer on one endpoint in in/out >>> direction (say ep1-in), then trying to start transfer on another >>> endpoint in same direction (say ep2-in), leads to resource conflict. > >> that shouldn't be the case. Resources for EP1 are different than those of EP2. > > I agree, the issue was not seen when DEPSTARTCFG issued once to dwc3 core > while enabling single interface by host. The failing scenario is, in case of the composite gadget > with two interfaces (NCM + ACM) when each interface enabled by host, the DEPSTARTCFG is issued to core. > Finally the DEPSTARCFG is issued twice to dwc3, which leads to this behavior. > As per SNPS, the DESPARTCFG must be issued only once even if multiple interfaces are enabled, > Otherwise this leads to resource conflict. Hi Ravi, Felipe, Sorry, I didn't notice this in my backlog until Ravi's response this morning. I think I see the problem but I'm not sure how to solve it right now. How the resources should be allocated is that each endpoint of a configuration should be assigned a different transfer resource. This includes all endpoints for every interface in the configuration. How resources are assigned is that you do a DEPSTARTCFG for the configuration to reset the transfer resource index (TRI). Then you do DEPXFERCFG for each endpoint in the configuration and each DEPXFERCFG assigns it the resource indicated by the TRI and increments it. The previous bug came about because after a SET_CONFIGURATION you may want to do multiple SET_INTERFACE to a single interface to set different alt-settings. Then eventually you run out of resources because you never reset the resources between calls to SET_INTERFACE. The current bug is that you have a composite device with multiple interfaces and possibly alt-settings for one or more of them. But you don't neccessarily want to reset the resources between each SET_INTERFACE because each one is to a different interface within the same configuration. However if you don't, and there are again multiple SET_INTERFACE requests you can run out of resources. It might not be possible to solve both scenarios with the current way that it is programmed. One way I see to solve it is if we reallocate the resources more intelligently after each SET_CONFIG/SET_INTERFACE and control which resource is assigned to each endpoint. This requires assigning the TRI manually which might be possible by calling DEPSTARTCFG before every DEPXFERCFG. I'm not completely sure about that so I have to consult with an one of the RTL engineers but he is out of the office today. I'll get back to you on this. 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
