Re: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.)

Alan Stern

--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux