Hi,
On 5/7/2013 12:35 PM, Laurent Pinchart wrote:
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).
I agree with Laurent here. There is no point in connecting function
driver with the UDC unless we are sure that the control
requests/STREAMON event can be handled at the real video capture device.
Remember that the real video capture sensor can be controlled by some
slow external bus like I2C, SPI.
So, we should not connect to the UDC unless we actually have the real
video streaming device up and configured. Note that a number of real
camera sensors require a large no of registers to be written via I2C
commands to put them into a "good" default state.
As the V4L2 subsystem is designed to work on basis of IOCTLs from
user-space, it is possible but not that easy, to move a part of what is
now handled in user-space for interaction b/w UVC and V4L2 subsystems
into kernel-space, but still a user-space entity will be required to
handle most of the processing (if any required before passing the data
to UVC subsytem) and V4L2 buffer queue/dequeue operations.
This (gadget design) seems more like a feature that must be either
handled by the UDCs or by the Gadget core and not the function drivers.
Regards,
Bhupesh
--
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
