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. that's not what the API was intended for, however. If we're going down that path, we need another of telling the gadget driver to reset all its buffers and teardown all its requests without disconnecting pullups, maybe that's what ->reset() would be for. -- balbi
Attachment:
signature.asc
Description: Digital signature
