Hi Vladimir, On Monday 06 May 2013 13:42:45 Vladimir Zapolskiy wrote: > On 05/04/13 21:22, Bhupesh SHARMA wrote: > > On 5/3/2013 6:00 PM, Vladimir Zapolskiy wrote: > >> On 05/03/13 02:05, Laurent Pinchart wrote: > >>> On Friday 03 May 2013 02:00:29 Vladimir Zapolskiy wrote: > >>>> On 05/03/13 01:18, Laurent Pinchart wrote: > >>>>> On Friday 03 May 2013 01:13:48 Vladimir Zapolskiy wrote: > >>>>>> This change removes redundant calls to uvc_function_connect() and > >>>>>> uvc_function_disconnect() on V4L2 device node open and release. > >>>>>> > >>>>>> These two functions attemp to control pull-up on D+ line directly, > >>>>>> however such an action should be performed by an UDC iteself, and > >>>>>> within the gadget there is no information about current mode of the > >>>>>> controller. > >>>>>> > >>>>>> The UDC may be in suspended state, or an OTG controller may be in > >>>>>> host mode, therefore it seems better not to try to forcibly pull-up > >>>>>> D+ line on open() syscall. > >>>>> > >>>>> OK, but we then need to fix the problem properly. The UVC gadget must > >>>>> not appear connected until an application opens the corresponding > >>>>> device. Likewise, it must disconnect from the bus when the application > >>>>> closes the device. How can this be guaranteed properly ? > >>>> > >>>> For better understanding of the issue, could you explain briefly why > >>>> do you prefer to have the gadget not connected to the bus, if device > >>>> node is not opened? > >>> > >>> As soon as the gadget will connect to the bus the device will be > >>> enumerated by the host and bound to a host driver that will query the > >>> device using UVC-specific requests. The userspace application is > >>> involved in replying to those requests, so it needs to be bound to the > >>> device on the gadget side or the initialization process on the host side > >>> will fail. > >> > >> It might be a flaw in design, if a kernel space component depends on a > >> user space application to be operable. Also the same scenario seems to be > >> invalid, if an application unawared of specific to UVC features of > >> /dev/videoX opens the device node, e.g. > >> http://git.kernel.org/cgit/linux/hotplug/udev.git/tree/src/v4l_id/v4l_id. > >> c or yavta etc. I presume a host should dictate behaviour of device and > >> gadget in particular, and not a target's user space application, please > >> correct me. As Bhupesh already explained, the complexity of handling video streaming requires a userspace component. Port of the uvc-gadget application could be moved to the kernel driver, but we will always need a userspace component to supply video data and reply to control requests. > >> About this particular change, as I mentioned in a cover letter an > >> alternative approach may be to add sanity checks to .pullup operations > >> for every UDC driver (or probably to usb_gadget_connect()), but in this > >> case it is not clear how UVC gadget is going to be notified about changes > >> of UDC state, e.g. assume a test that /dev/videoX is opened, when OTG is > >> in Host mode, device registration doesn't happen on open(), and then USB > >> B cable is inserted to the port. > >> > >> I would appreciate your thoughts. > > > > The whole point of having a user-space application governing the > > behavior of UVC webcam gadget as per commands from a UVC host is to plug > > the same with a real video capture source driver to provide the video > > frames captured from say a camera sensor and route the UVC specific > > control requests to a real video capture device by converting the same > > to equivalent V4L2 commands. > > thank you for the explanation, however my original question is about > avoiding critical hardware errors attended to the current gadget's design. > If you think that UDC should be controlled every time on open()/close() > syscalls, how do you see an optimal way to mitigate problems described > above? I think the issue is on the UDC side. A function driver should be allowed to tell when it's ready to be connected and when it needs to be disconnected. The UDC of course isn't required to connect the device to the bus as soon as the function request the connection, it can delay that until it's ready (switched from host mode to device mode in case of OTG, resumed if it has been suspended, ...). The API offered to function drivers should handle this, either in the gadget core or in the UDC themselves (or possibly a combination of the two). -- Regards, Laurent Pinchart -- 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
