Previously image transfer used to use the highest altsetting, which, most of
the time, took the whole USB bandwidth.
Now, the altsetting is chosen according to an estimation of the bandwidth
needed for image transfer.
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In vidioc_enum_fmt_vid_cap, the 'compressed' flag was set from the
pixelformat, and all pixelformats were not treated.
Now, images are told as compressed when the image size is smaller than
its number of pixels.
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

For USB speeds different of 'low', the bInterval value is logarithmic.
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add pr_fmt.
Convert usb style logging macros to pr_<level>.
Remove now unused old usb style logging macros.
Signed-off-by: NJoe Perches <joe@perches.com>
Acked-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Just like in userspace strncpy does not guarantee 0 termination. Use strlcpy
instead which does guarantee 0 termination.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Reset image and image_len to NULL/0 on LAST_PACKET when we're in discard
frame mode, just like we do when not discarding the current frame.

The new se401 driver uses image_len for SOF/EOF detection and thus depends on
this.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Instead of handling a per-driver driver version, use the
per-subsystem one.

As reviewed by Jean-Francois Moine <moinejf@free.fr>:
	- the 'info' may be simplified:
Reviewed-by: NJean-Francois Moine <moinejf@free.fr>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The USB traces are better done by usbmon which is enabled in most Linux/GNU
distributions and which permits easier comparison with the USB exchanges of
other drivers.
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

This patch fixes a bug in gspca, more precisely in alt_xfer().

This function looks for an input transfer endpoint in an alternate setting.
By default it returns the first endpoint corresponding to the transfer type
indicated in parameter.
But with some USB devices, the first endpoint corresponding to the transfer
type is not always an INPUT endpoint but an OUTPUT one.

This patch adds the endpoint direction test to be sure to return an INPUT endpoint
Signed-off-by: NPatrice CHOTARD <patricechotard@free.fr>
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

- change copyright and erroneous comment
- small code optimization
- have constant the device template
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We check for not streaming as a condition to abort waiting in dqbuf, so
when another thread does a streamoff we should wake the wq.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Some applications (xawtv, qv4l2) mix read and mmap calls. Allow switching
from read mode back to mmap mode (by doing a reqbufs).
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

gspca_dev->memory == GSPCA_MEMORY_NO implies gspca_dev->nframes == 0,
so there is no need to check for both in dev_poll. The check in
dev_read also is more complex then needed, as dqbuf which dev_read
calls already does all necessary checks. Moreover dqbuf is holding
the proper locks while checking where as dev_read itself is not.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Before this patch we were not setting the memory type to GSPCA_MEMORY_NO
when the buffers were released by the app doing a reqbufs 0. Nor would
the memory type be set to GSPCA_MEMORY_NO on device close, as capture_file
already is NULL on device close because of the reqbufs 0. This caused the
following problem:
-app1 does reqbufs USERPTR for 4 buffers
-app1 does reqbufs USERPTR for 0 buffers
-app2 tries to do reqbufs MMAP for 4 buffers
 fails because gspca_dev->memory still is USERPTR

Fixing this also allows an app to switch memory type's by unrequesting
the buffers and re-requesting them of a different type.

This patch also moves the setting of gspca_dev->frsz and gscpa_dev->memory
to after alloc_frame succeeding, so that they are not changed when allocating
fails.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Remove the no longer used / useful users variable, and with that gone
there also is no longer a need to take queue_lock in dev_open.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Before this patch dqbuf errors out on a failing user_copy (with user pointers)
before updating the buffer flags, causing a successsfully dequeued buffer
to still have the DONE flag, which means that it could no longer be
re-queueud (assuming the app somehow survives the segfault).
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Before this patch vidioc_dqbuf is using its own read_lock, where as
other queue related functions use queue_lock. This means that dqbuf is
accessing several variables in a racy manor. The most important one
being fr_o, which may be changed from underneath dqbuf by vidioc_reqbufs
or vidioc_streamoff. Other variables which it accesses unprotected
are gspca_dev->memory, gspca_dev->streaming and gspca_dev->capt_file.

This patch fixes this by changing vidioc_dqbuf to also use the queue_lock.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The gspca_dev->streaming boolean is protected against multiple access
through gspca_dev->queue_lock everywhere except for 2 places. This patch
fixes this by bringing it under the lock in vidioc_streamoff. And by
removing the check for gspca_dev->streaming in gspca_disconnect,
the destroy_urbs call may be called multiple times (and is protected
by the usb_lock) and calling wake_up_interruptible can also always be done
safely.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The check for status errors is now before the check for len. That's
ok. However, the error printk's for the status error prints the URB
length. This generates this error:

drivers/media/video/gspca/gspca.c: In function ‘fill_frame’:
drivers/media/video/gspca/gspca.c:305:9: warning: ‘len’ may be used uninitialized in this function

The fix is as simple as moving the len init to happen before the checks.

Cc: Jean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Also, in ov534, don't check the parm type.
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When an error is set for an isochronous packet, the length of the packet
may be null. In this case, the error was not detected and the image
was not discarded as it should be.
Reported-by: NFranck Bourdonnec <fbourdonnec@chez.com>
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Changeset 35680baa broke several devices:
	- Sony Playstation Eye (1415:2000);
	- Gigaware model 25-234 (0c45:628f);
	- Logitech Messenger Plus (046d:08f6).

Probably more devices were broken by this change.

What happens is that several devices don't need to save some bandwidth
for audio.

Also, as pointed by Hans de Goede <hdegoede@redhat.com>, the logic
that implements the bandwidth reservation for audio is broken, since
it will reduce the alt number twice, on devices with audio.

So, let's just revert the broken logic, and think on a better solution
for usb 1.1 devices with audio that can't use the maximum packetsize.
Acked-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently alloc_and_submit_int_urb() is setting gspca->int_urb
as soon as the allocation has succeeded, but if the subsequent
submit fails, the urb gets destroyed. And then later will
get destroyed again in gspca_input_destroy_urb() because
gspca->int_urb is set, leading to a double free.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently gspca supported usb-1.1 webcams for which we support the input
button through an interrupt endpoint won't stream (not enough bandwidth
error) when used through an USB-2.0 hub.

After much debugging I've found out that the cause for this is that the
ehci-sched.c schedeling code does not like it when there are already urb's
scheduled when (large) isoc urbs are queued. By moving the submission
of the interrupt urbs to after submitting the isoc urbs the camera
starts working again through usb-2.0 hubs.

Note that this does not fix isoc. streaming through a usb-hub while another
1.1 usb device (like the microphone of the same cam) is also active
at the same time :(

I've spend a long time analyzing the linux kernel ehci scheduler code,
resulting in this (long) mail:
http://www.spinics.net/lists/linux-usb/msg37982.html

The conclusion of the following mail thread is that yes there are several
issues when using usb-1.1 devices through a usb-2.0 hub, but these are not
easily fixable in the current code. Fixing this in ehci-sched.c requires
an almost full rewrite, which is not bound to happen anytime soon.

So with this patch gspca driven usb-1.1 webcams will atleast work when
connected through an usb-2.0 hub when the microphone is not used.

As an added bonus this patch avoids extra destroy/create input urb cycles
when we end up falling back to a lower speed alt setting because of bandwidth
limitations.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The errors were found by checkpatch.pl. Most fixes are:
- remove spaces followed by TAB(s),
- split lines greater than 80 characters,
- move most '{'s from start of line to end of previous line.
  (Some '{'s at start of line remain when the '}'s are on the same line)
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When audio is present, some alternate settings were skipped.
This prevented some webcams to work, especially when bulk transfer was used.
This patch permits to use the last or only alternate setting.
Reported-by: NAntonio Ospite <ospite@studenti.unina.it>
Tested-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch also sets to 0 the sequence of the first frame.
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The new control mechanism uses dynamic control values in the subdriver
descriptor. It simplifies standard control handling.
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When plugging some webcams on ARM, the system crashes.
This is because we alloc buffer for an urb through usb_buffer_alloc,
the alloced buffer is already in DMA coherent region, so we should
set the flag of this urb to URB_NO_TRANSFER_DMA_MAP, otherwise when
we submit this urb, the hcd core will handle this address as an
non-DMA address and call dma_map_single/sg to map it. On arm
architecture, dma_map_single a DMA coherent address will be catched
by a BUG_ON().
Signed-off-by: NJason Wang <jason77.wang@gmail.com>
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Cc: stable@kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Some webcams as ov511 may find many times an end of image.
In this case, with the last patch in image concatenation
(commit 799b1bd41f398054d46fd35f73abd01c4009f6ca),
the image pointer was NULL and the system crashed in memcpy().
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When there is an audio device, use a lower alternate setting.
This patch does not fix correctly all audio and bandwidth problems.
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>