On Thu, Aug 28, 2014 at 09:56:06AM -0500, Felipe Balbi wrote: > Hi, > > > > > For other three stages (no need to control at bus_reset), we can control dp > > > > at two gadget driver's API relies on flag pullup_on_vbus. > > > > > > I also can't get what you mean here. > > > > If the UDC driver doesn't want to pull up dp at insmod gadget driver, it > > can pull up dp when the cable is connected. > > how will UDC know that cable was connected if its pullups aren't > connected ? > Through vbus handler, these kinds of udc has flag pullup_on_vbus. > > > > Do you agree above? > > > > > > > > If you agree, the first patchset for adding reset API at usb_gadget_driver may > > > > do less thing, and the reset API implementation at each gadget driver is the > > > > same with disconnect. > > > > > > that's why we never had a ->reset() callback so far. From a gadget > > > driver perspective, it's the same as disconnect followed by a connect. > > > > Yes, it is the current design, but if we want to call usb_gadget_disconnect > > at ->disconnect callback, things will be different, besides, the kernel > > doc says it is invoked when "when the host is disconnected". > > you shouldn't call usb_gadget_disconnect() from ->disconnect(). It's the > other way around. You get a disconnect IRQ, then you call gadget > driver's ->disconnect(), but gadget driver doesn't need to ask UDC to > remove pullup at that time. Not every UDC driver has disconnect IRQ. > > This has been getting more and more confusing of a problem. I'll go curl > down in a corner and think about it :-) > 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? [1] http://www.spinics.net/lists/linux-usb/msg111969.html [2] http://www.spinics.net/lists/linux-usb/msg111973.html [3] http://www.spinics.net/lists/linux-usb/msg111976.html -- 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
