Re: [RFC PATCH] uvc_v4l2: reset connection on uvc open

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

 



Hi Felipe,

On Thursday 24 January 2013 16:42:50 Felipe Balbi wrote:
> On Thu, Jan 24, 2013 at 03:35:58PM +0100, Michael Grzeschik wrote:
> > On Thu, Jan 24, 2013 at 03:21:37PM +0100, Laurent Pinchart wrote:
> > > On Thursday 24 January 2013 14:54:01 Michael Grzeschik wrote:
> > > > On Thu, Jan 24, 2013 at 12:02:12PM +0100, Laurent Pinchart wrote:
> > > > > On Thursday 24 January 2013 11:22:02 Michael Grzeschik wrote:
> > > > > > The current implementation of the composite framework connects the
> > > > > > gadget function to the device-controller at kernel boottime.
> > > > > > 
> > > > > > It's possible that the userspace application, which handles the
> > > > > > enumeration requests of the gadget, starts with high latency when
> > > > > > the host did already gave up to detect the gadget. In that case
> > > > > > the gadget-application will not work in the first case.
> > > > > 
> > > > > This shouldn't happen, as the UVC gadget driver should start
> > > > > disconnected (it calls usb_function_deactive() in
> > > > > uvc_function_bind()). If the host can enumerate the gadget before
> > > > > the application starts it would then likely be a device controller
> > > > > driver bug, not a UVC gadget driver bug.
> > > > 
> > > > Unlikely this is not the case, as usb_gadget_probe_driver triggers an
> > > > usb_gadget_connect() right after driver->bind() was called.
> > > 
> > > Indeed, for new-style UDC that's correct.
> > > 
> > > Isn't that an issue with the framework ? I would expect gadget drivers
> > > to be able to start disconnected.
> > 
> > That probably is. But it might only be a problem for gadgets with
> > userspace components which handle ep0 requests. For other gadgets, which
> > are not as dynamic as an webcam, it might be enough to have its
> > enumeration handled in kernel and start right on.
> > 
> > That needs further discussion. Therefore my patch is an RFC and a simple
> > solution to ship arround that issue. Should we take it though?
> 
> Framework will take care of it, but other controllers need to be fixed
> up first so they don't connect their pullup directly.
> 
> We're getting close to that, though. Give me another merge window and
> gadget drivers will be required to manage pullup.

Thanks :-)

-- 
Regards,

Laurent Pinchart

Attachment: signature.asc
Description: This is a digitally signed message part.


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

  Powered by Linux