On Wed, Aug 13, 2014 at 06:08:55PM +0200, Michael Grzeschik wrote:
> On Wed, Aug 13, 2014 at 09:19:31AM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Aug 13, 2014 at 10:02:08AM -0400, Alan Stern wrote:
> > > > > So here's what the UDC driver should do: If the pullup routine is called
> > > > > while Vbus is off, the driver should leave the D+ pullup disconnected but
> > > > > remember the call. Then when Vbus gets turned on, the driver should
> > > > > activate the pullup.
> > > > >
> > > > > In other words, the UDC driver should keep track of the pullup's
> > > > > "logical" state. When Vbus is off, the pullup must also be off. When
> > > > > Vbus is on, the pullup's physical state should be the same as the logical
> > > > > state.
> > > > >
> > > >
> > > > We had a similar discussion at last year, but Felipe " don't want to let UDC
> > > > drivers call usb_gadget_connect()/disconnect() directly."
> > >
> > > All right, let's see what Felipe says about my suggestion.
> >
> > Keeping track of the pullup's state like that will just add complexity
> > to the UDC drivers. There's really no problem in connecting pullups
> > before VBUS is above session valid threshold.
> >
> > The whole idea of udc-core was to handle those details generically so we
> > don't have to patch every single UDC driver. The best solution, IMO,
> > would be to teach every function about activate/deactivate and only
> > connect pullups based on that. So that functions, and only functions,
> > are responsible for managing pullups.
> >
> > Functions which don't need to wait for userspace can just call
> > usb_function_activate() from their bind() method, while functions
> > relying on userspace can do so when the devnode is opened or whatever.
>
>
> That will not solve the scenario where one composite device manage e.g.
> three different functions. Lets assume we have one acm, one uvc and one ncm
> (in that exact order). That will lead to one usb_function_activate,
> one usb_function_deactivate and one usb_function_activate.
something like this:
/* done automatically by composite layer */
for_each_function_bind() {
usb_function_deactivate();
}
so you know that you'll have 3 deactivations by default (per your
example). NCM calls activate without waiting for userland, you still
have 2 activations missing. Those will be called when the userland UVC
and ACM counterparts open the respective devnodes.
> Not even speaking of the complexity we gain, when using g_ffs. That
> is composing the composite gadget in userspace runtime.
right, we'd need an ioctl to let userspace call that when using g_ffs.
--
balbi
Attachment:
signature.asc
Description: Digital signature
