On Fri, Aug 29, 2014 at 11:14:23AM -0400, Alan Stern wrote: > On Fri, 29 Aug 2014, Peter Chen wrote: > > > Felipe & Alan, thanks for your comments for these patches, I think I may need > > to list these issues again to make things clearer. > > > > The purpose of these patchsets are to fix two issues: > > - Some udcs failures at USB-IF certification Back-Voltage test, it needs > > the dp is not pulled up when the vbus is not there, usb 2.0 spec 7.2.1 > > and 7.1.5 require it. > > - Some function drivers (f_uvc, f_obex, and android functions later) do > > not want to pull up dp at the udc_start, they want it on demand, like app > > has run. > > > > So, we can't pull up dp unconditionally at udc-core, I proposal the strategy > > for pulling up dp after below two conditions are satisfied [1]: > > - If the udc is ready to pull up dp > > - all functions at gadget driver want to pullup dp, it will pull up dp. > > > > The first condition depends on UDCs, Some UDCs(UDC-A) doesn't need to > > clear software pull up(run/stop) bit after vbus has disconnected, > > the possible reason may these kinds of UDC have hardware logic to disable > > pullup at dp when the vbus is not there, then it can pass back-voltage test, > > so for these kinds of UDCs, they are always ready to pull up dp. > > But for other UDCs(UDC-B, like chipidea), it needs to clear pullup bit after > > vbus has disconnected to pass back-voltage test, for these kinds of UDCs, they > > are only ready to pull up dp when the vbus is there. > > The second condition are the same for all UDCs, the function/gadget driver > > determine it. > > > > The patchset[1] has implemented above idea, UDC-A is always ready to pull up > > dp, it will set ready (connect) bit at the end of udc_start, and UDC-B will > > be ready when the vbus is there.[2], and the dp control strategy is decided by > > two conditions[3]. > > > > Alan concerns why the .connect API has **connect** argument, the reason > > is we need to call it at vbus handler to disable pullup bit when the vbus > > is not there. It is indeed strange we have **connect** argument at .connect, > > but current .disconnect API does not call usb_gadget_disconnect, so we have > > no way to pull down dp when the vbus is not there, that is the story > > we have this patchset and discussion. > > > > What's the next step for me? > > First, change the API so that the disconnect API _does_ call > usb_gadget_disconnect. > > Then change the gadget drivers so that they tell the UDC driver when to > turn the pullup on or off. This should happen whenever a function is > activated or deactivated or whenever a connect or disconnect occurs. > > (In theory the gadget driver does not need to tell the UDC driver to > turn off the pullup when a disconnect occurs; the UDC driver will turn > it off anyway. But the gadget driver still needs to know that there > was a disconnect. Otherwise it might tell the UDC driver to turn on > the pullup at a time when the device isn't connected.) > It is better gadget driver tells the UDC driver (with vbus handler) to turn off the pullup when a disconnect occurs, in that case, we can remove all pull up/down dp code from UDC drivers. -- Best Regards, Peter Chen -- 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
