The AMD ATI TV Wonder 600 has an XC3028L and *not* an XC3028, so we need to
load the proper firmware to prevent the device from overheating.
Signed-off-by: NDevin Heitmueller <devin.heitmueller@gmail.com>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fixes videobuf field_count
Signed-off-by: NDean Anderson <dean@sensoray.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The zr36067 driver is improperly declaring pixel format RGBP twice,
once as "16-bit RGB LE" and once as "16-bit RGB BE". The latter is
actually RGBR. Fix the code to properly map both pixel formats.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

sparc32 allmodconfig:

drivers/media/video/cafe_ccic.c: In function 'cafe_setup_siobuf':
drivers/media/video/cafe_ccic.c:1192: error: implicit declaration of function 'PAGE_ALIGN'
drivers/media/video/cafe_ccic.c: At top level:
drivers/media/video/cafe_ccic.c:1430: error: variable 'cafe_v4l_vm_ops' has initializer but incomplete type
drivers/media/video/cafe_ccic.c:1431: error: unknown field 'open' specified in initializer
drivers/media/video/cafe_ccic.c:1431: warning: excess elements in struct initializer
drivers/media/video/cafe_ccic.c:1431: warning: (near initialization for 'cafe_v4l_vm_ops')
drivers/media/video/cafe_ccic.c:1432: error: unknown field 'close' specified in initializer
drivers/media/video/cafe_ccic.c:1433: warning: excess elements in struct initializer
drivers/media/video/cafe_ccic.c:1433: warning: (near initialization for 'cafe_v4l_vm_ops')
drivers/media/video/cafe_ccic.c: In function 'cafe_v4l_mmap':
drivers/media/video/cafe_ccic.c:1444: error: 'VM_WRITE' undeclared (first use in this function)
drivers/media/video/cafe_ccic.c:1444: error: (Each undeclared identifier is reported only once
drivers/media/video/cafe_ccic.c:1444: error: for each function it appears in.)
drivers/media/video/cafe_ccic.c:1444: error: 'VM_SHARED' undeclared (first use in this function)
drivers/media/video/cafe_ccic.c:1461: error: 'VM_DONTEXPAND' undeclared (first use in this function)

This build breakage is caused by some header file shuffle in linux-next.  But
I suggest that this patch be merged ahead of linux-next to avoid bisection
breakage.
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The zr36067 driver should return the actual bytes-per-line value when
queried with ioctl VIDIOC_G_FMT, instead of 0. Otherwise user-space
applications can get confused.

Likewise, with ioctl VIDIOC_S_FMT, we are supposed to fill the
bytes-per-line value. And we shouldn't fail if the caller sets the
initial value to something different from 0. This is perfectly valid
for applications to pre-fill this field with the value they expect.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Restore the default pixel format to YUYV as it used to be before
kernel 2.6.23. It was accidentally changed to BGR3 by commit
603d6f2c.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix the following crash in the bttv driver:

BUG: unable to handle kernel NULL pointer dereference at 000000000000036c
IP: [<ffffffffa037860a>] radio_open+0x3a/0x170 [bttv]

This happens because radio_open assumes that all present bttv devices
have a radio function. If a bttv device without radio and one with
radio are installed on the same system, and the one without radio is
registered first, then radio_open checks for the radio device number
of a bttv device that has no radio function, and this breaks. All we
have to do to fix it is to skip bttv devices without a radio function.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Removed duplicated entry for EM2800_BOARD_KWORLD_USB2800
Signed-off-by: NDouglas Schilling Landgraf <dougsland@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

CS2102K stop streaming on setlightfreq (50Hz & 60Hz).
Disable it for now until a correct solution is found.
Signed-off-by: NCostantino Leandro <le_costantino@pixartargentina.com.ar>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

Earlier fixes to get the tuner audio working correctly broke the audio
on the Compro VideoMate H900 cards. This is now fixed.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Exposure was always 0. Thanks to sparse for finding this.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

sparse found an unbalanced BKL usage.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The device 2040:2950 is a really old variant of the PVR USB2 hardware.
I have just learned of its existence.  For the purposes of the pvrusb2
driver, it is functionally identical to the well known 29xxx series
(2040:2900).  Amazing that this went undetected for 3+ years.
Signed-off-by: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Free allocated memory

Cc: Jean-Francois Moine <moinejf@free.fr>
Cc: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Free allocated memory

Cc: Luca Risolia <luca.risolia@studio.unibo.it>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Free allocated memory
Signed-off-by: NDouglas Schilling Landgraf <dougsland@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Free allocated memory
Signed-off-by: NDouglas Schilling Landgraf <dougsland@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fixed order of usb_alloc_urb pointer validation.

Cc: Luca Risolia <luca.risolia@studio.unibo.it>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

i2c_client is allocated for us, we should never free it ourselves.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

While doing some testing using Luca Risolia's sonix driver I noticed that
the video device did not get ACL's set to allow access by locally logged in
users, nor does it show up as a video device in lshal, causing cheese to not
see it.

This turns out to be caused by all of Luca Risolia's drivers not setting
the parent member of the video_device struct. This patch fixes this.

Cc: Luca Risolia <luca.risolia@studio.unibo.it>
Signed-off-by: NHans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

b2c2-flexcop, dvb/bt8xx and video/bt8xx fails to build on ARM with:

__bad_udelay is specifically designed on ARM to fail when udelay is
called in a bad way.  arch/arm/include/asm/delay.h has this to say
about __bad_udelay:

/*
 * This function intentionally does not exist; if you see references to
 * it, it means that you're calling udelay() with an out of range value.
 *
 * With currently imposed limits, this means that we support a max delay
 * of 2000us. Further limits: HZ<=1000 and bogomips<=3355
 */
extern void __bad_udelay(void);

Solution is to replace udelay by a mdelay and udelay with value less than 2000
Signed-off-by: NThierry MERLE <thierry.merle@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

- Adjust hstart in ov7630 on sn9c103 initdata to shift bayer pattern, this is
 the same change as done for the other initdata tables in a previous patch.
- Assign usb-id's for the ov7630 + sn9c103 to gspca if gspca and sn9c102
  drivers are both enabled.
Signed-off-by: NHans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

-Make raw bayer header size change from 20 to 16 affect rev072a only, my 2
 rev012a cams both have a header size of 20
-While testing this I also tested the new exposure setting (good work on
 finding the register JF), and after quite a bit of testing have found out the
 exact meaning of the register, this patch modifies setexposure to control
 the exposure over a much wider range.
Signed-off-by: NHans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

- have 2 pixfmt tables
- offset of Bayer frames at 16 instead of 20.
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When using the sonixb driver in a dark room and given that the autoexposure
algorithm starts with a setting most suitable for daylight, the picture
produced by the cam may actually be 100% black leading to a avg_lum value of 0,
so an avg_lum value of 0 does not always signal an exposure settings change
(which it normally does). This patch adds a check for the really black image
case and stops dropping all frames as invalid in this case.
Signed-off-by: NHans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch makes gspca claim the USB-ID for sn9c101/2 cams with a TAS5110C1B
sensor even if both gspca and sn9c102 are enabled, as these cams are much
better supported under gspca (and extensively tested with gspca).
It also removes an usb-id from sn9c102 for one more unsupported bridge
sensor combo.
Signed-off-by: NHans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

- Add documentation for some known registers
- Add support for vga modes (320x240, 160x120) for sif sensors
- Remove F_RAW sensor flag raw mode should work on any sensor as its a bridge
   only thing and keeping the flag was becoming awkward.
- Fixup ov6650 and pas106 auto exposure window settings
Signed-off-by: NHans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch fixes a memory leak in an error path.
Reported-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

video_device_release() does kfree(), which made the following printk()
doing a use-after-free.

printk() first and release then.
Reported-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

1) Lower the hstart setting for all sensor by 1 so that we generate
   (compressed) BGGR data just like sn9c102 does (instead of GBRG data)
2) Add support for raw bayer output in the lowest resolutions (not enough
   bandwidth for higher resolutions), this should work with all sensors but
   to be sure only enable it for sensors where it has been tested.
Signed-off-by: NHans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Under certain conditions sonixb compressed frame size can get bigger then
the uncompressed size (seen with 0c45:6028), so make the buffers slightly
bigger.
Signed-off-by: NHans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

-the usb-id table caried several flags which were not usb-id specific but
 sensor specific, add a sensor_data array and move these flag there
-fr_h_sz was being abused to store and check which bridge was being used
 instead add a bridge member to the sd struct
-now that we have a sensor_data table use that to store pointers to
 init_sequences instead of using switch cases on sd->sensor
Signed-off-by: NHans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

-remove USB-id's from zc0301 for cams for which zc0301.c does not support
  the sensor
-remove USB-id's from sn9c102 for cams where sn9c102 does not support the
  bridge sensor combination
-no longer make inclusion of usb id's removed from zc0301 and sn9c102
  conditional in gspca
-fix conditional inclusion of USB-id's in gspca to also work when the
  conflicting drivers are build as a module
-add a number of USB-id's to gspca from various windows .inf files:
0c45:608f from generic sonix sn9c103 inf file (+ ov7630 which we support)
041e:4022 from creative webcam nx pro, same as already supported 041e:401e
0ac8:0301 from generic zc0301 driver which supports many sensors
10fd:804d from typhoon webshot driver (also FlyCAM-USB 300 plus)
Signed-off-by: NHans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The USB buffer may be used for DMA and there may be a caching problem
if the buffer is part of the device structure.
Thanks to Alan Stern.
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>