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: Antonio Ospite <ospite@studenti.unina.it>
Tested-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch also sets to 0 the sequence of the first frame.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro 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: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro 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: Jason Wang <jason77.wang@gmail.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Cc: stable@kernel.org
Signed-off-by: Mauro 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: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro 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: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch fixes possible race conditions in queue management with SMP:
when a frame was completed, the irq function tried to use the next frame
buffer. At this time, it was possible that the application on an other
processor updated the frame pointer, making the image to point to a bad
buffer.
The patch contains two main changes:
- the image transfer uses the queue indexes which are protected against
simultaneous memory access,
- the image pointer which is used for image concatenation is only set at
interrupt level.
Some subdrivers which used the image pointer have been updated.
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The problem may occur with SMP:
- a frame is completed at interrupt level (in gspca_frame_add with
packet_type == LAST_PACKET,
- just after clearing the bit V4L2_BUF_FLAG_QUEUED and before setting
the bit V4L2_BUF_FLAG_DONE, on the other processor, the application
tries to requeue the same frame buffer,
- then, the qbuf function succeeds because ALL_FLAGS are not set.
The fix sets and resets the two flags in one instruction.
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The image pointer and its length are now in the main structure instead
of in the frame buffer. They are updated on application vidioc_qbuf and
in the URB interrupt function when ending an image.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This function is used when the USB video interface is checked by
the subdriver.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
For more clearance what the functions actually do,
usb_buffer_alloc() is renamed to usb_alloc_coherent()
usb_buffer_free() is renamed to usb_free_coherent()
They should only be used in code which really needs DMA coherency.
All call sites have been changed accordingly, except for staging
drivers.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Pedro Ribeiro <pedrib@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Handle case of GSPCA=m, INPUT=m when building gspca core;
also handle case of INPUT=n by using stubs.
drivers/media/video/gspca/gspca.c:662: error: implicit declaration of function 'gspca_input_destroy_urb'
drivers/media/video/gspca/gspca.c:668: error: implicit declaration of function 'gspca_input_create_urb'
drivers/media/video/gspca/gspca.c:2284: error: implicit declaration of function 'gspca_input_connect'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It seems that I merged a wrong version of the patch or that
changeset 4d770eeb926d0bc44c0bd68d051d3d2a5568ef41 got mangled somehow:
It were missed the #else to avoid compilation troubles.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca_main: Fix a compile error when CONFIG_INPUT is not set.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2 small changes to input device error handling:
1) Make it fatal when we fail to create an input device (it is either this
or add checks for gspca_dev->input_dev being NULL in a lot of places)
2) Since we allow gspca_input_create_urb() to fail everywhere we call it,
and thus never check its return value, make it void.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Allow use of the gspca core input device creation code by subdrivers which
have non interrupt driven camera buttons.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some sensors only allow controlling the exposure by changing the clockdiv,
which means that exposure takes pretty large jumps (for example when going
from a div of 1 to 2, the exposure doubles). Use 2 different entries in
the controls array for these 2 different types of exposure (always
disabling one), and;
Add a new autogain algorithm for the coarse exposure case, which normally
changes the gain setting, only touching the exposure setting if the desired
luminance cannot be reached with gain, and after an exposure change once more
first tries gain, etc. Thus avoiding exposure changes, and the resulting
oscilation because of the huge steps these exposure controls take.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some webcams have many interfaces with the same interface class, so the
previous interface check did not work.
The new code checks if the interface number is zero or the only one.
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The USB video interface was checked as having the number zero, but
some webcams have other values. The test is now done on the interface
class which may be either 255 (vendor spec) or 0 (class per interface).
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This flag permits subdrivers to create specific transfer URBs.
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When not set, some images could be lost.
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- gl860.c:332:15: warning: cast to restricted __le16
- gl860.c:333:15: warning: cast to restricted __le16
- gl860-mi1320.c:348:5: warning: symbol 'mi1320_camera_settings' was not declared. Should it be static?
- gl860-mi2020.c:772:5: warning: symbol 'mi2020_camera_settings' was not declared. Should it be static?
- m5602_ov9650.c:444:7: warning: symbol 'data' shadows an earlier one
- m5602_core.c:84:5: warning: symbol 'm5602_wait_for_i2c' was not declared. Should it be static?
- m5602_core.c:391:6: warning: symbol 'm5602_disconnect' was not declared. Should it be static?
- m5602_s5k4aa.c:530:23: warning: dubious: x | !y
- m5602_s5k4aa.c:575:23: warning: dubious: x | !y
- gspca.c:1196:13: warning: potentially expensive pointer subtraction
- mr97310a.c:70:5: warning: symbol 'force_sensor_type' was not declared. Should it be static?
- ov519.c:2025:4: warning: do-while statement is not a compound statement
- ov519.c:2063:4: warning: do-while statement is not a compound statement
- ov519.c:2089:4: warning: do-while statement is not a compound statement
- ov519.c:1985:34: warning: incorrect type in assignment (different base types)
- sn9c20x.c:1164:5: warning: symbol 'i2c_r1' was not declared. Should it be static?
- sn9c20x.c:1189:5: warning: symbol 'i2c_r2' was not declared. Should it be static?
- sn9c20x.c:2237:27: warning: right shift by bigger than source value
- sn9c20x.c:2237:27: warning: right shift by bigger than source value
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some drivers support multiple frameintervals (framerates), make gspca able to
enumerate them.
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now that the video_device registration is tested using
video_is_registered(), drivers don't need to initialize the
video_device::minor field to -1 anymore.
Remove those unneeded assignments.
[mchehab.redhat.com: removed tm6000 changes as tm6000 is not ready yet for submission even on staging]
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix all device drivers to use the new video_device_node_name function.
This also strips kernel log messages from the "/dev/" prefix, has the device
node location is a userspace policy decision unknown to the kernel.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
