1
Commit Graph

10678 Commits

Author SHA1 Message Date
Jesper Juhl
fd01ad9894 [media] media, tlg2300: Fix memory leak in alloc_bulk_urbs_generic()
Hi,

While reading
drivers/media/video/tlg2300/pd-video.c::alloc_bulk_urbs_generic() I
noticed that

 - We don't free the memory allocated to 'urb' if the call to
   usb_alloc_coherent() fails.
 - If the 'num' argument to the function is ever <= 0 we'll return an
   uninitialized variable 'i' to the caller.

The following patch addresses both of the above by a) calling
usb_free_urb() when usb_alloc_coherent() fails and by explicitly
initializing 'i' to zero.
I also moved the variables 'mem' and 'urb' inside the for loop. This does
not actually make any difference, it just seemed more correct to me to let
variables exist only in the innermost scope they are used.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Huang Shijie <shijie8@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:45 -02:00
Jesper Juhl
36fd97884d [media] frontends/ix2505v: Remember to free allocated memory in failure path
We may leak the storage allocated to 'state' in
drivers/media/dvb/frontends/ix2505v.c::ix2505v_attach() on error, as
it is too early to be able to call ix2505v_release().

This patch makes sure we free the allocated memory in the failure case.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:44 -02:00
Jean-François Moine
a63d601803 [media] gspca - sonixj: Add LED (illuminator) control to the webcam 0c45:614a
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:43 -02:00
Jean-François Moine
3afef85bfe [media] gspca - sonixj: Infrared bug fix and enhancement
The infrared was set by sensor write instead of bridge GPIO.
It is now settable by the standard control ILLUMINATOR_1.
A module parameter permits to set the right GPIO bit according
to the StarCam model.

Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:42 -02:00
Jean-François Moine
14b67c2969 [media] gspca - ov534: Propagate errors to higher level
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:41 -02:00
Jean-François Moine
ddffa49e25 [media] gspca - ov534: Clearer debug messages
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:39 -02:00
Jean-François Moine
fc63de88e0 [media] gspca - ov519: Cleanup source and add a comment
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:38 -02:00
Jean-François Moine
ded5e903b7 [media] gspca: Remove useless instructions
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:37 -02:00
Jean-François Moine
95c967c167 [media] gspca: Remove __devinit, __devinitconst and __devinitdata
__devinit* must not be used in USB drivers.

Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:35 -02:00
Jean-François Moine
0beb6714e7 [media] gspca: Version change
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:33 -02:00
Hans Verkuil
2a863793be [media] v4l2-ctrls: v4l2_ctrl_handler_setup must set is_new to 1
Renamed has_new to is_new.

Drivers can use the is_new field to determine if a new value was specified
for a control. The v4l2_ctrl_handler_setup() must always set this to 1 since
the setup has to force a full update of all controls.

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:32 -02:00
Hans Verkuil
45f6f84af3 [media] v4l2-subdev: add (un)register internal ops
Some subdevs need to call into the board code after they are registered
and have a valid struct v4l2_device pointer. The s_config op was abused
for this, but now that it is removed we need a cleaner way of solving this.

So this patch adds a struct with internal ops that the v4l2 core can call.

Currently only two ops exist: register and unregister. Subdevs can implement
these to call the board code and pass it the v4l2_device pointer, which the
board code can then use to get access to the struct that embeds the
v4l2_device.

It is expected that in the future open and close ops will also be added.

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:31 -02:00
Hans Verkuil
3c7c9370fb [media] v4l2-subdev: remove core.s_config and v4l2_i2c_new_subdev_cfg()
The core.s_config op was meant for legacy drivers that needed to work with old
pre-2.6.26 kernels. This is no longer relevant. Unfortunately, this op was
incorrectly called from several drivers.

Replace those occurences with proper i2c_board_info structs and call
v4l2_i2c_new_subdev_board.

After these changes v4l2_i2c_new_subdev_cfg() was no longer used, so remove
that function as well.

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:30 -02:00
Mauro Carvalho Chehab
ecb71d262b [media] saa7134: Kworld SBTVD: make both analog and digital to work
There are some weird bugs at tda8290/tda18271 initialization, as it
insits do do analog initialization during DVB frontend attach:

DVB: registering new adapter (saa7133[0])
DVB: registering adapter 0 frontend 0 (Fujitsu mb86A20s)...
mb86a20s: mb86a20s_initfe
tda18271_write_regs: [2-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5
tda18271_init: [2-0060|M] error -5 on line 830
tda18271_tune: [2-0060|M] error -5 on line 908
tda18271_write_regs
tda18271_write_regs: [2-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5
tda18271c2_rf_tracking_filters_correction: [2-0060|M] error -5 on line 265
tda18271_write_regs
tda18271_write_regs: [2-0060|M] ERROR: idx = 0x25, len = 1, i2c_transfer returned: -5
tda18271_channel_configuration: [2-0060|M] error -5 on line 119
tda18271_set_analog_params: [2-0060|M] error -5 on line 1045
tda18271_set_analog_params: [2-0060|M] error -5 on line 1045
tda829x 2-004b: tda8295 not locked, no signal?
tda829x 2-004b: tda8295_i2c_bridge: disable i2c gate
tda829x 2-004b: tda8295 not locked, no signal?
tda829x 2-004b: tda8295_i2c_bridge: disable i2c gate
mb86a20s_i2c_writereg: writereg error (rc == -5, reg == 0x29, data == 0x33)
mb86a20s: Init failed. Will try again later

The problem is that mb86a20s is only visible if the analog part is disabled.

However, due to a trick at mb86a20s, it will later initialize properly:

mb86a20s: mb86a20s_initfe: Initialization succeded.

This is hacky and ugly. However, I coldn't find any easy way to fix it.
A proper fix would be to have a resource locking schema, used by both
V4L and DVB parts that would block access to analog registers while
digital registers are in use, but this will probably put tda829x into
a dead lock.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:28 -02:00
Mauro Carvalho Chehab
6a58bc0f50 [media] saa7134: Fix digital mode on Kworld SBTVD
This patch fixes digital mode on Kworld SBTVD. Unfortunately, it disables
analog mode.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:27 -02:00
Mauro Carvalho Chehab
6183040680 [media] saa7134: Fix analog mode for Kworld SBTVD
There were some issues at tda8290 that were preventing this device
to work. Now that those fixes were fixed, we can enable analog
mode.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:26 -02:00
Mauro Carvalho Chehab
c736a5f28e [media] mb86a20s: Be sure that device is initialized before starting DVB
Due to a hard to track bug between tda829x/tda18271/saa7134, tda829x
wants to go to analog mode during DVB initialization, causing some
I2C errors.

The analog failure doesn't cause any harm, as the device were already
properly initialized in analog mode. However, the failure at the digital
mode causes the frontend mb86a20s to not initialize. Fortunately, at
least on my tests, it was possible to detect that the device is a
mb86a20s before the failure.

What happens is that tda8290 is a very bad boy: during DVB setup, it
keeps insisting to call tda18271 analog_set_params, that calls
tune_agc code. The tune_agc code calls saa7134 driver, changing the
value of GPIO 27, switching from digital to analog mode and disabling
the access to mb86a20s, as, on Kworld SBTVD, the same GPIO used
to switch the hardware AGC mode seems to be used to enable the I2C
switch that allows access to the frontend (mb86a20s).

So, a call to analog_set_params ultimately disables the access to
the frontend, and causes a failure at the init frontend logic.

This patch is a workaround for this issue: it simply checks if the
frontend init had any failure. If so, it will init the frontend when
some DTV application will try to set DVB mode.

Even being a hack for Kworld SBTVD to work, and assumning that we could
teach tda8290 to be a good boy, this is actually an improvement at the
frontend driver, as it will be more reliable to initialization failures.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:25 -02:00
Mauro Carvalho Chehab
7570800c9d [media] mb86a20s: Fix i2c read/write error messages
A script replaced err var to rc. Howerver, this script gambled
"error" string, changing it to "rcor". Revert that bad change.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:24 -02:00
Mauro Carvalho Chehab
9d700a0696 [media] tda8290: Turn tda829x on before touching at the I2C gate
On Kworld SBTVD, tda8295-c1 starts in power off mode. It needs
to be powered, otherwise, the I2C gate control command won't work.

Cc: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:23 -02:00
Mauro Carvalho Chehab
47ab285a96 [media] tda8290: Fix a bug if no tuner is detected
If tda8290 is detected, but no tuner is found, the driver will do bad
things:

tuner 2-0060: chip found @ 0xc0 (saa7133[0])
tda829x 2-0060: could not clearly identify tuner address, defaulting to 60
tda829x 2-0060: tuner access failed!
BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
IP: [<ffffffffa048c267>] set_audio+0x47/0x170 [tda8290]
PGD 1187b0067 PUD 11771e067 PMD 0
Oops: 0002 [#1] SMP
last sysfs file: /sys/module/i2c_core/initstate
CPU 0
Modules linked in: tda8290(U) tea5767(U) tuner(U) ir_lirc_codec(U) lirc_dev(U) ir_sony_decoder(U) ir_jvc_decoder(U) ir_rc6_decoder(U) ir_rc5_decoder(U) saa7134(+)(U) v4l2_common(U) ir_nec_decoder(U) videodev(U) v4l2_compat_ioctl32(U) rc_core(U) videobuf_dma_sg(U) videobuf_core(U) tveeprom(U) ebtable_nat ebtables xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT bridge stp llc autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table xt_physdev iptable_filter ip_tables ip6t_REJECT ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log parport kvm_intel kvm uinput floppy tpm_infineon wmi sg serio_raw iTCO_wdt iTCO_vendor_support tg3 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc i7core_edac edac_core nouveau
Modules linked in: tda8290(U) tea5767(U) tuner(U) ir_lirc_codec(U) lirc_dev(U) ir_sony_decoder(U) ir_jvc_decoder(U) ir_rc6_decoder(U) ir_rc5_decoder(U) saa7134(+)(U) v4l2_common(U) ir_nec_decoder(U) videodev(U) v4l2_compat_ioctl32(U) rc_core(U) videobuf_dma_sg(U) videobuf_core(U) tveeprom(U) ebtable_nat ebtables xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT bridge stp llc autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table xt_physdev iptable_filter ip_tables ip6t_REJECT ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log parport kvm_intel kvm uinput floppy tpm_infineon wmi sg serio_raw iTCO_wdt iTCO_vendor_support tg3 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc i7core_edac edac_core nouveau ttm drm_kms_helper drm i2c_algo_bit video output i2c_core ext3 jbd mbcache firewire_ohci firewire_core crc_itu_t sr_mod cdrom sd_mod crc_t10dif ahci dm_mod [last unloaded: microcode]
Pid: 9497, comm: modprobe Not tainted 2.6.32-72.el6.x86_64 #1 HP Z400 Workstation
RIP: 0010:[<ffffffffa048c267>]  [<ffffffffa048c267>] set_audio+0x47/0x170 [tda8290]
RSP: 0018:ffff88010ba01b28  EFLAGS: 00010206
RAX: 00000000000000ff RBX: ffff880119522800 RCX: 0000000000000002
RDX: 0000000000003be0 RSI: ffff88010ba01bb8 RDI: 0000000000000000
RBP: ffff88010ba01b28 R08: 0000000000000002 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88010ba01bb8 R14: 0000000000001900 R15: 0000000000001900
FS:  00007f4b96b3d700(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000020 CR3: 000000011866c000 CR4: 00000000000026f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 9497, threadinfo ffff88010ba00000, task ffff880100708a70)
Stack:
 ffff88010ba01b98 ffffffffa048c95b ffff88010ba01b78 0000000000000060
<0> 0000000000000000 0000000e00000000 000000000000001d ffffffffa03ec838
<0> ffff88010abac240 ffff880119522800 ffff880119522800 ffff880119522bc0
Call Trace:
 [<ffffffffa048c95b>] tda8295_set_params+0x3b/0x210 [tda8290]
 [<ffffffffa03ec838>] ? v4l2_i2c_new_subdev_cfg+0x88/0xc0 [v4l2_common]
 [<ffffffffa0484418>] set_freq+0x128/0x2f0 [tuner]
 [<ffffffffa0486464>] tuner_s_std+0xc4/0x740 [tuner]
 [<ffffffffa04b9ae6>] saa7134_set_tvnorm_hw+0x2d6/0x3d0 [saa7134]
 [<ffffffffa04ba455>] set_tvnorm+0xd5/0x100 [saa7134]
 [<ffffffffa04bc9fd>] saa7134_video_init2+0x1d/0x50 [saa7134]
 [<ffffffffa04bf57e>] saa7134_initdev+0x6e1/0xb1d [saa7134]
 [<ffffffff8125afea>] ? kobject_get+0x1a/0x30
 [<ffffffff812765f7>] local_pci_probe+0x17/0x20
 [<ffffffff812777e1>] pci_device_probe+0x101/0x120
 [<ffffffff8132ec72>] ? driver_sysfs_add+0x62/0x90
 [<ffffffff8132ee10>] driver_probe_device+0xa0/0x2a0
 [<ffffffff8132f0bb>] __driver_attach+0xab/0xb0
 [<ffffffff8132f010>] ? __driver_attach+0x0/0xb0
 [<ffffffff8132e074>] bus_for_each_dev+0x64/0x90
 [<ffffffff8132ebae>] driver_attach+0x1e/0x20
 [<ffffffff8132e4b0>] bus_add_driver+0x200/0x300
 [<ffffffff8132f3e6>] driver_register+0x76/0x140
 [<ffffffff814c7c43>] ? printk+0x41/0x46
 [<ffffffff81277a46>] __pci_register_driver+0x56/0xd0
 [<ffffffffa04de000>] ? saa7134_init+0x0/0x4f [saa7134]
 [<ffffffffa04de04d>] saa7134_init+0x4d/0x4f [saa7134]
 [<ffffffff8100a04c>] do_one_initcall+0x3c/0x1d0
 [<ffffffff810af5ef>] sys_init_module+0xdf/0x250
 [<ffffffff81013172>] system_call_fastpath+0x16/0x1b
Code: 20 01 49 c7 c0 c9 ec 48 a0 83 7e 04 01 74 2d 8b 0d 3f 2f 00 00 85 c9 0f 85 d7 00 00 00 c9 c3 0f 1f 44 00 00 a9 03 00 01 00 74 61 <c6> 47 20 02 83 7e 04 01 49 c7 c0 cc ec 48 a0 75 d3 0f b6 47 22
RIP  [<ffffffffa048c267>] set_audio+0x47/0x170 [tda8290]
 RSP <ffff88010ba01b28>
CR2: 0000000000000020

This happens because some I2C callbacks actually depend on having the
driver entirely initialized. To avoid this OOPS, just clean the I2C
callbacks, as if no device were detected.

Cc: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:22 -02:00
Mauro Carvalho Chehab
567aba0b79 [media] tda8290: Make all read operations atomic
Read operations should be preceeded by a write operation. However,
nothing prevents that an I2C operation could happen between the two
transactions.

To avoid that problem, use an unique I2C transfer for both parts of
the I2C transaction.

Cc: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:20 -02:00
Mauro Carvalho Chehab
5a85025f7d [media] em28xx: Fix IR support for WinTV USB2
Due to a lack of a break inside the switch, it were getting the
wrong keytable and get_key function.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:19 -02:00
Mauro Carvalho Chehab
e6bcb2f324 [media] ir-kbd-i2c: Make IR debug messages more useful
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:18 -02:00
Mauro Carvalho Chehab
59aa346009 [media] dib0700: Fix IR keycode handling
Fixes Fedora 14 bug: https://bugzilla.redhat.com/show_bug.cgi?id=667157

There are a few bugs at the code that generates the scancode at dib0700:
	- RC keycode is wrong (it outputs a 24 bits keycode);
	- NEC extended outputs a keycode that have endiannes issues;
	- keycode tables for NEC extended remotes need to be updated.

The last issue need to be done as we get reports, as we don't have
the complete NEC-extended keycodes at the dibcom table.

This patch fixes the first two issues.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:17 -02:00
Mauro Carvalho Chehab
312d63e4b0 [media] rc-dib0700-nec: Fix keytable for Pixelview SBTVD
dib0700 now outputs NEC extended keycodes. Fix the keytable to reflect that.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:16 -02:00
Tobias Lorenz
186a21cb77 [media] radio-si470x: Always report support for RDS
The si470x i2c and usb driver support the RDS, so this ifdef statement
doesn't need more.

[mchehab@redhat.com: Fix a conflict on it]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Acked-by: Tobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:15 -02:00
Tobias Lorenz
131ddd1a30 [media] radio-si470x: de-emphasis should be set if requested by module parameter
instead of always setting de-emphasis.

Reported-by: Tobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Acked-by: Tobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:14 -02:00
Hans Verkuil
a1198ccf9c [media] v4l2-ioctl: fix incorrect error code if VIDIOC_DBG_G/S_REGISTER are unsupported
The ioctls VIDIOC_DBG_S_REGISTER and VIDIOC_DBG_G_REGISTER should return -EINVAL
if the driver didn't implement them. Currently they return -EPERM if called as
non-root user. However, this check should only be done if the driver actually
implemented these ioctls. Otherwise, just return -EINVAL as we do with all
unimplemented ioctls.

This bug make the v4l2-compliance test suite fail.

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:13 -02:00
Hans de Goede
4c77590225 [media] gspca_sonixb: Fix mirrored image with ov7630
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:12 -02:00
Hans de Goede
e48d38f7f1 [media] gspca_sonixj: Add one more commented out usb-id
While going through windows inf file I found more usb-id, add a comment
with this id for future reference.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:11 -02:00
Hans de Goede
e530a5e3cf [media] gspca_sonixj: Probe sensor type independent of bridge type
Looking at the windows inf file, for usb ids with a sensor type where probing
is needed to determine the type (for example ov7630 or soi768), this is
needed for all bridge variants with a usb id indicating this sensor type.

So do the probing to determine the actual sensor type for types where the
usb-id info is not 100% deterministic, independent of the bridge type.

If you look through the list of currently active usb ids in sonixj, this
effectively only changes the code path for 0c45:60fe (sn9c105 + ov7630) and
0c45:612e (sn9c110 + ov7630), which according to the inf file can have a
soi768 instead of a ov7630 just like the sn9c120 + ov7630 models where we
already probe for a soi7630.

The main reason for this code change is to keep the code paths as bridge
variant independent as possible, so that we don't need a lot of special
per bridge cases, as we enable more usb-ids in the future.

This change makes the 0c45:60fe code path identical to the successfully
tested 0c45:613e, so also make sonixj the default driver for 0c45:60fe.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:10 -02:00
Hans de Goede
4944e27d85 [media] gspca_sonixj: Enable more usb ids when sn9c102 gets compiled too
Both we and the windows driver make no sensor specific differences
(with some exceptions) for different sonixj bridge types. Thus if a
sn9c105 bridge has been successfully tested with a sensor, the same
sensor can be successfully used with a sn9c120 bridge too.

Using this knowledge we can move over most usb-ids too the sonixj
driver when both are compiled.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:08 -02:00
Hans de Goede
69ffd25457 [media] gspca_sonixb: Add usb ids for known sn9c103 cameras
Now that our bridge code is unified for sn9c101/102 and sn9c103 models,
the sn9c103 models should simply work, given that the only difference
in the sn9c103 is audio support and a gamma correction table.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:07 -02:00
Hans de Goede
4e17cd2eac [media] gspca_sonixb: TAS5130C brightness control really is a gain control
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:07 -02:00
Hans de Goede
0d0d7ef71e [media] gspca_sonixb: Fix TAS5110D sensor gain control
Also fix the issue of the image being mirrored.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:06 -02:00
Hans de Goede
f913c001cd [media] gspca_sonixb: Adjust autoexposure window for vga cams so that it is centered
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:05 -02:00
Hans de Goede
0a76cb8cef [media] gspca_sonixb: Refactor to unify bridge handling
Refactor the code to unify how the sn9c101/102 and the sn9c103 bridge
are handled. Also move code which is the same for all sensors from
the per sensor init register settings to a central place.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:03 -02:00
Hans de Goede
a24f0c5c47 [media] sn9c102: Remove not supported and non existing usb ids
The sn9c102 driver claims a number of usb-ids which are for cameras
with sensor types which it does not support. Also it claims a number
of usb-ids which do not exist at all (not present in the windows
drivers .inf files, not known by google).

This patch also fixes the conflict with the gspca_sonixj driver for the
0c45:60c0 and 0c45:60fb usb ids.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:02 -02:00
Hans de Goede
8b064ee19d [media] et61x251: remove wrongly claimed usb ids
The et61x251 driver claims a whole list of usb id's, but it only has
one sensor "module" which does sensor detection based on usb id and that
only supports devices with the 102c:6251 usb id. Remove the usb-ids for
other devices as for those the driver will fail with an unable to determine
sensor type message anyways.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:01 -02:00
Hans de Goede
0d0ae15dde [media] gspca_main: wake wq on streamoff
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: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:45:00 -02:00
Hans de Goede
ce5610bca7 [media] gspca_main: Allow switching from read to mmap / userptr mode
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: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:44:59 -02:00
Hans de Goede
ee3629914b [media] gspca_main: Simplify read mode memory type checks
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: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:44:58 -02:00
Hans de Goede
d642de2ed4 [media] gspca_main: Set memory type to GSPCA_MEMORY_NO on buffer release
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: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:44:57 -02:00
Hans de Goede
7f6eb118df [media] gspca_main: Remove no longer used users variable
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: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:44:56 -02:00
Hans de Goede
4a82bc60a9 [media] gspca_main: Update buffer flags even when user_copy fails
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: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:44:55 -02:00
Hans de Goede
27074efa2e [media] gspca_main: Locking fixes 2
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: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:44:54 -02:00
Hans de Goede
4e770f7602 [media] gspca_main: Locking fixes 1
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: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:44:53 -02:00
Antti Palosaari
82f4b5b67e [media] af9013: fix AF9013 TDA18271 IF config
IF freq	for DVB-T 7 MHz	and 8 MHz was set slightly wrong. Due to that it
didn't worked at all (?) for 7 MHz channels and most likely performance
was dropped for 8 MHz channels.

That bug was pointed by few people during last two months. Thank you.

Trivial fix. Compile tested only due to lack of proper HW and signal.

Signed-off-by: Antti Palosaari <crope@iki.fi>
Cc: Romolo Manfredini <romoloman@hotmail.com>
Cc: Alireza Moini <alireza.moini@silverbrookresearch.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:44:52 -02:00
Hans Verkuil
424852f437 [media] radio-gemtek-pci: remove duplicate driver
The radio-gemtek-pci driver is for the same hardware as the radio-maxiradio
driver which uses the same GemTek PR103 and tea5757 combination and the two
drivers are identical. I chose the maxiradio over the gemtek-pci driver since
the maxiradio has support for mono/stereo detection.

Tested with my gemtek-pci card.

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:28:23 -02:00
Hans Verkuil
90d873a7f9 [media] radio-maxiradio.c: use sensible frequency range
Use the standard USA/Europe frequency range of 87-108 MHz instead of the
arbitrary 50-150 MHz.

Copied from the radio-gemtek-pci driver which supports the same hardware.

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-19 11:28:22 -02:00