The V4L2 core will warn if this is not done. Unfortunately this driver
wasn't updated.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Instead of .ioctl use unlocked_ioctl. This allows us to finally remove
the old .ioctl op.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Switch this driver over to the V4L2 core locking mechanism in preparation
for switching to unlocked_ioctl. Suggested by Laurent Pinchart.

This patch introduces a new mutex at the struct uvc_video level and
drops the old mutex at the queue level. The new lock is now used for all
ioctl locking and in the release file operation (the driver always has
to take care of locking in file operations, the core only serializes
ioctls).

Note that the mmap and get_unmapped_area file operations no longer take
a lock. Commit f035eb4e fixed a AB-BA
deadlock by moving all the locking down into vb2, so the mmap and
get_unmapped_area file operations should no longer do any locking before
calling into vb2.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Patch "usb: gadget: uvc: rename functions to avoid conflicts with host uvc"
renamed a lot of symbols but missed one references that was inside of
an #ifdef:

drivers/usb/gadget/function/uvc_v4l2.c:363:23: error: 'uvcg_v4l2_get_unmapped_area' undeclared here (not in a function)
  .get_unmapped_area = uvcg_v4l2_get_unmapped_area,
                       ^
drivers/usb/gadget/function/uvc_v4l2.c:344:22: warning: 'uvc_v4l2_get_unmapped_area' defined but not used [-Wunused-function]
 static unsigned long uvc_v4l2_get_unmapped_area(struct file *file,
                      ^

This renames the reference according the changed function name.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 7ea95b11 ("usb: gadget: uvc: rename functions to avoid conflicts with host uvc")
Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Compile uvc_queue, uvc_v4l2, uvc_video separately so that later they can
be all combined in a separately compiled f_uvc.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Tested-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
[Make uvc_v4l2_ioctl_ops non-static]
[Rename __UVC__V4L2__H__ and __UVC__VIDEO__H__]
[Update MAINTAINERS]
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Prepare for separate compilation of uvc function's components.
Some symbols will have to be exported, so rename to avoid
conflicts with functions of the same name in host uvc.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Tested-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
[Rename uvc_video_pump and uvc_queue_head as well]
[Rename forgotten uvc_queue_cancel instance in a comment]
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Simplify ioctl handling by using video_ioctl2.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

To handle class requests received on ep0, the driver needs to access the
length and direction of the request after the setup stage. It currently
stores them in a v4l2 event during the setup stage, and then copies them
from the event structure to the driver internal state structure when the
event is dequeued.

This two-steps approach isn't necessary. Simplify the driver by storing
the needed information in the driver internal state structure directly
during the setup stage.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

As the driver is in mainline we can remove the version numbers.
Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The drivers/usb/gadget directory contains many files.
Files which are related can be distributed into separate directories.
This patch moves the USB functions implementations into a separate directory.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch adds the support for 'get_unmapped_area' in UVC gadget
which is called when the 'mmap' system call is executed on MMUless
architectures.
Signed-off-by: NBhupesh Sharma <bhupesh.sharma@st.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

This patch reworks the videobuffer management logic present in the UVC
webcam gadget and ports it to use the "more apt" videobuf2 framework for
video buffer management.

To support routing video data captured from a real V4L2 video capture
device with a "zero copy" operation on videobuffers (as they pass from
the V4L2 domain to UVC domain via a user-space application), we need to
support USER_PTR IO method at the UVC gadget side.

So the V4L2 capture device driver can still continue to use MMAP IO
method and now the user-space application can just pass a pointer to the
video buffers being dequeued from the V4L2 device side while queueing
them at the UVC gadget end. This ensures that we have a "zero-copy"
design as the videobuffers pass from the V4L2 capture device to the UVC
gadget.

Note that there will still be a need to apply UVC specific payload
headers on top of each UVC payload data, which will still require a copy
operation to be performed in the 'encode' routines of the UVC gadget.

This patch also addresses one issue found out while porting the UVC
gadget to videobuf2 framework:
	- In case the usb requests queued by the gadget get completed
	  with a status of -ESHUTDOWN (disconnected from host),
	  the queue of videobuf2 should be cancelled to ensure that the
	  application space daemon is not left in a state waiting for
	  a vb2 to be successfully absorbed at the USB side.
Signed-off-by: NBhupesh Sharma <bhupesh.sharma@st.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

"req->length" is a capped version of "data->length".
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

For NULL terminated string, better notice '\0' in the end.
Signed-off-by: NChen Gang <gang.chen@asianux.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NBhupesh Sharma <bhupesh.sharma@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch adds the support in UVC webcam gadget design for providing
USB_GADGET_DELAYED_STATUS in response to a set_interface(alt setting 1)
command issue by the Host.

The current UVC webcam gadget design generates a STREAMON event
corresponding to a set_interface(alt setting 1) command from the Host.
This STREAMON event will eventually be routed to a real V4L2 device.

To start video streaming, it may be required to perform some register
writes to a camera sensor device over slow external busses like I2C or
SPI. So, it makes sense to ensure that we delay the STATUS stage of the
set_interface (alt setting 1) command.

Otherwise, a lot of ISOC IN tokens sent by the Host will be replied to
by zero-length packets by the webcam device. On certain Hosts this may
even lead to ISOC URBs been cancelled from the Host side.

So, as soon as we finish doing all the "streaming" related stuff on the
real V4L2 device, we call a STREAMON ioctl on the UVC side and from here
we call the 'usb_composite_setup_continue' function to complete the
status stage of the set_interface(alt setting 1) command.

Further, we need to ensure that we queue no video buffers on the UVC
webcam gadget, until we de-queue a video buffer from the V4L2 device.
So, the application should call the STREAMON on UVC side only when it
has dequeued sufficient buffers from the V4L2 side and queued them to
the UVC gadget.
Signed-off-by: NBhupesh Sharma <bhupesh.sharma@st.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NBhupesh Sharma <bhupesh.sharma@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

gadget drivers shouldn't touch req->dma at all,
since UDC drivers are the ones required to handle
mapping and unmapping of the request buffer.

Remove references to DMA_ADDR_INVALID so we don't
creat false expectations to gadget driver writers.
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Just like with ctrl events, drivers may want to get called back on
listener add / remove for other event types too. Rather then special
casing all of this in subscribe / unsubscribe event it is better to
use ops for this.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The field is used to pass the UVC request data length, but can also be
used to signal an error when setting it to a negative value. Switch from
unsigned int to __s32.
Reported-by: NFernandez Gonzalo <gfernandez@copreci.es>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It was pointed out by 'make versioncheck' that linux/version.h was not
always being included where needed and sometimes included needlessly
in drivers/usb/.
This patch fixes up the includes.

For the UVC gadget driver bits, this was ACK'ed by Laurent Pinchart.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

remove the following two paragraphs as they are not needed:

This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
License for more details.

You should have received a copy of the GNU General Public License along with
this program; if not, write to the Free Software Foundation, Inc.,59
Temple Place - Suite 330, Boston, MA  02111-1307, USA.
Signed-off-by: NKlaus Schwarzkopf <schwarzkopf@sensortherm.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The driver had to decide how many events to allocate when the v4l2_fh struct
was created. It was possible to add more events afterwards, but there was no
way to ensure that you wouldn't miss important events if the event queue
would fill up for that filehandle.

In addition, once there were no more free events, any new events were simply
dropped on the floor.

For the control event in particular this made life very difficult since
control status/value changes could just be missed if the number of allocated
events and the speed at which the application read events was too low to keep
up with the number of generated events. The application would have no idea
what the latest state was for a control since it could have missed the latest
control change.

So this patch makes some major changes in how events are allocated. Instead
of allocating events per-filehandle they are now allocated when subscribing an
event. So for that particular event type N events (determined by the driver)
are allocated. Those events are reserved for that particular event type.
This ensures that you will not miss events for a particular type altogether.

In addition, if there are N events in use and a new event is raised, then
the oldest event is dropped and the new one is added. So the latest event
is always available.

This can be further improved by adding the ability to merge the state of
two events together, ensuring that no data is lost at all. This will be
added in the next patch.

This also makes it possible to allow the user to determine the number of
events that will be allocated. This is not implemented at the moment, but
would be trivial.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Drivers that supported events used to be rare, but now that controls can also
raise events this will become much more common since almost all drivers have
controls.

This means that keeping struct v4l2_events as a separate struct make no more
sense. Merging it into struct v4l2_fh simplifies things substantially as it
is now an integral part of the filehandle struct.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We're trying to test for the the end of the loop here.  "format" is
never NULL.  We don't know what "format->fcc" is because we're past the
end of the loop and I think "fmt->fmt.pix.pixelformat" comes from the
user so we don't know what that is either.  It works, but it's cleaner
to just test to see if (i == ARRAY_SIZE(uvc_formats).
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The UVC gadget driver borrowed code from the UVC host driver without
changing the symbol names. This results in a namespace clash with
multiple definitions of several symbols when compiling both drivers in
the kernel.

Make all generic UVC functions and variables static in the UVC gadget
driver, as the symbols are not referenced outside of the gadget driver.
Rename the uvc_trace_param global variable to uvc_gadget_trace_param.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This USB video class function driver implements a video capture device from the
host's point of view. It creates a V4L2 output device on the gadget's side to
transfer data from a userspace application over USB.

The UVC-specific descriptors are passed by the gadget driver to the UVC
function driver, making them completely configurable without any modification
to the function's driver code.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>