Hi Laurent,
On 05/03/13 01:18, Laurent Pinchart wrote:
Hi Vladimir,
Thank you for the patch.
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?
Signed-off-by: Vladimir Zapolskiy<vladimir_zapolskiy@xxxxxxxxxx>
Cc: Laurent Pinchart<laurent.pinchart@xxxxxxxxxxxxxxxx>
---
drivers/usb/gadget/uvc_v4l2.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/usb/gadget/uvc_v4l2.c b/drivers/usb/gadget/uvc_v4l2.c
index ad48e81..e2b66e1 100644
--- a/drivers/usb/gadget/uvc_v4l2.c
+++ b/drivers/usb/gadget/uvc_v4l2.c
@@ -132,20 +132,15 @@ uvc_v4l2_open(struct file *file)
handle->device =&uvc->video;
file->private_data =&handle->vfh;
- uvc_function_connect(uvc);
return 0;
}
static int
uvc_v4l2_release(struct file *file)
{
- struct video_device *vdev = video_devdata(file);
- struct uvc_device *uvc = video_get_drvdata(vdev);
struct uvc_file_handle *handle = to_uvc_file_handle(file->private_data);
struct uvc_video *video = handle->device;
- uvc_function_disconnect(uvc);
-
uvc_video_enable(video, 0);
uvc_free_buffers(&video->queue);
--
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
