Hans Verkuil [Sat, 9 Mar 2013 12:25:47 +0000 (09:25 -0300)]
[media] go7007: switch to standard tuner/i2c subdevs
Instead of using the wis-* drivers we now use the standard 'proper' subdev
drivers.
The board configuration tables now also list the possible audio inputs,
this will be used later to implement audio inputs.
Special mention deserves a little change in set_capture_size() where the
height passed to s_mbus_fmt is doubled: that is because the saa7115 driver
expects to see the frame height, not the field height as the wis_saa7115
driver did.
Another change is that the tuner input is moved from last to the first
input, which is consistent with the common practice in other video drivers.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sat, 9 Mar 2013 11:06:07 +0000 (08:06 -0300)]
[media] tw2804: add support for the Techwell tw2804
This is based on the wis-tw2804.c driver that's part of the go7007 driver.
It has been converted to a v4l subdev driver by Volokh Konstantin, and I
made additional cleanups.
Based on work by: Volokh Konstantin <volokh84@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Mon, 18 Mar 2013 07:10:56 +0000 (04:10 -0300)]
[media] tw9903: add new tw9903 video decoder
This based on the wis-tw9903.c driver that's part of the go7007 driver.
It has been converted to a v4l subdev driver by Pete Eberlein, and I made
additional cleanups.
Based on work by: Pete Eberlein <pete@sensoray.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sat, 9 Mar 2013 10:20:12 +0000 (07:20 -0300)]
[media] uda1342: add new uda1342 audio codec driver
This based on the wis-uda1342.c driver that's part of the go7007 driver.
It has been converted to a v4l subdev driver by Pete Eberlein, and I made
additional cleanups.
Based on work by: Pete Eberlein <pete@sensoray.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sat, 9 Mar 2013 10:09:18 +0000 (07:09 -0300)]
[media] ov7640: add new ov7640 driver
This based on the wis-ov7640.c driver that's part of the go7007 driver.
It has been converted to a v4l subdev driver by Pete Eberlein, and I made
additional cleanups.
Based on work by: Pete Eberlein <pete@sensoray.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Fri, 22 Mar 2013 14:13:58 +0000 (11:13 -0300)]
[media] sony-btf-mpx: the MPX driver for the sony BTF PAL/SECAM tuner
The Sony BTF PG472Z has an internal MPX to deal with mono/stereo/bilingual
audio. This is split off from the wis-sony-tuner driver that is part of
the go7007 driver as it should be a separate i2c sub-device driver.
The wis-sony-tuner is really three i2c devices: a standard tuner, a tda9887
compatible demodulator and this mpx. After this patch the wis-sony-tuner
can be replaced by this driver and the standard tuner driver.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sat, 9 Mar 2013 16:14:32 +0000 (13:14 -0300)]
[media] tuner: add Sony BTF tuners
This adds support for three Sony BTF tuners:
TUNER_SONY_BTF_PG472Z: PAL+SECAM
TUNER_SONY_BTF_PK467Z: NTSC-M-JP
TUNER_SONY_BTF_PB463Z: NTSC-M
These come from the go7007 staging driver where they were implemented in
the wis-sony-tuner i2c driver.
Adding support for these tuners to tuner-types.c is the first step towards
removing the wis-sony-tuner driver.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sat, 9 Mar 2013 09:18:03 +0000 (06:18 -0300)]
[media] go7007: fix i2c_xfer return codes
The i2c_xfer functions didn't return the proper error codes and (especially
important) on success they returned 0 instead of the number of transferred
messages.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sun, 10 Mar 2013 16:12:25 +0000 (13:12 -0300)]
[media] v4l2-ioctl: check if an ioctl is valid
Just checking if the op exists isn't correct, you should check if the ioctl
is valid (which implies that the op exists as well).
One exception is g_std: if current_norm is non-zero, then the g_std op may be
absent. This sort of weird behavior is one of the reasons why I am trying to
get rid of current_norm.
This patch fixes the case where the g/s_std op is set, but these ioctls are
disabled. This can happen in drivers supporting multiple models, some that
have TV input (and support the STD API) and some that have a sensor (and do
not support the STD API). In the latter case qv4l2 would still show the
Standards combobox.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sun, 3 Mar 2013 23:12:31 +0000 (20:12 -0300)]
[media] v4l2-core: add code to check for specific ops
This patch adds a v4l2_subdev_has_op() macro and a v4l2_device_has_op macro to
quickly check if a specific subdev or any subdev supports a particular subdev
operation.
This makes it easy for drivers to disable certain ioctls if none of the subdevs
supports the necessary functionality.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Andy Walls [Sat, 9 Mar 2013 08:55:11 +0000 (05:55 -0300)]
[media] v4l2-ctrls: eliminate lockdep false alarms for struct v4l2_ctrl_handler.lock
When calling v4l2_ctrl_add_handler(), lockdep would detect a potential
recursive locking problem on a situation that is by design intended and
not a recursive lock. This happened because all struct
v4l2_ctrl_handler.lock mutexes were created as members of the same lock
class in v4l2_ctrl_handler_init(), and v4l2_ctrl_add_handler() takes the
hdl->lock on two different v4l2_ctrl_handler instances.
This change breaks the large lockdep lock class for struct
v4l2_ctrl_handler.lock and breaks it into v4l2_ctrl_handler
instantiation specific lock classes with meaningful class names.
This will validly eliminate lockdep alarms for v4l2_ctrl_handler locking
validation, as long as the relationships between drivers adding v4l2
controls to their own handler from other v4l2 drivers' control handlers
remains straightforward.
struct v4l2_ctrl_handler.lock lock classes are created with names such
that the output of cat /proc/lockdep indicates where in the v4l2 driver
code v4l2_ctrl_handle_init() is being called on instantiations: ffffffffa045f490 FD: 10 BD: 8 +.+...: cx2341x:1534:(hdl)->lock ffffffffa0497d20 FD: 12 BD: 2 +.+.+.: saa7115:1581:(hdl)->lock ffffffffa04ac660 FD: 14 BD: 2 +.+.+.: msp3400_driver:756:(hdl)->lock ffffffffa0484b90 FD: 12 BD: 1 +.+.+.: ivtv_gpio:366:(&itv->hdl_gpio)->lock ffffffffa04eb530 FD: 11 BD: 2 +.+.+.: cx25840_core:1982:(&state->hdl)->lock ffffffffa04fbc80 FD: 11 BD: 3 +.+.+.: wm8775:246:(&state->hdl)->lock
Some lock chains, that were previously causing the recursion alarms, are
now visible in the output of cat /proc/lockdep_chains:
irq_context: 0
[ffffffffa0497d20] saa7115:1581:(hdl)->lock
[ffffffffa045f490] cx2341x:1534:(hdl)->lock
irq_context: 0
[ffffffffa04ac660] msp3400_driver:756:(hdl)->lock
[ffffffffa045f490] cx2341x:1534:(hdl)->lock
irq_context: 0
[ffffffffa0484b90] ivtv_gpio:366:(&itv->hdl_gpio)->lock
[ffffffffa045f490] cx2341x:1534:(hdl)->lock
irq_context: 0
[ffffffffa04eb530] cx25840_core:1982:(&state->hdl)->lock
[ffffffffa045f490] cx2341x:1534:(hdl)->lock
irq_context: 0
[ffffffffa04fbc80] wm8775:246:(&state->hdl)->lock
[ffffffffa045f490] cx2341x:1534:(hdl)->lock
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
[hans.verkuil@cisco.com: keep mutex_init in v4l2_ctrl_handler_init_class] Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Thu, 14 Mar 2013 10:40:45 +0000 (07:40 -0300)]
[media] v4l2-ioctl: simplify debug code
The core debug code can now be simplified since all the write-only ioctls are
now const and will not modify the data they pass to the drivers.
So instead of logging write-only ioctls before the driver is called this can
now be done afterwards, which is cleaner when it comes to error reporting as
well.
This also fixes a logic error in the debugging code where there was one 'else'
too many.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sun, 24 Mar 2013 11:24:19 +0000 (08:24 -0300)]
[media] ivtv: prepare ivtv for adding const to s_register
The ivtv_itvc function receives a pointer to v4l2_dbg_register. When we
add const to that pointer in the s_register case we will run into a problem
here since this common function would discard const in that case. So
change this function so it receives the address and a pointer to a value.
In addition we now set the size field in the g_register function which is
where it belongs.
This will simplify the next patch where const will be added to s_register.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Fri, 15 Mar 2013 09:10:40 +0000 (06:10 -0300)]
[media] v4l2: pass std by value to the write-only s_std ioctl
This ioctl is defined as IOW, so pass the argument by value instead of by
reference. I could have chosen to add const instead, but this is 1) easier
to handle in drivers and 2) consistent with the s_std subdev operation.
Frank Schaefer [Thu, 21 Mar 2013 16:51:20 +0000 (13:51 -0300)]
[media] bttv: apply mute settings on open
Previously, this has been done implicitly for video device nodes by calling
set_input() (which calls audio_input() and also modified the mute
setting).
Since input and mute setting are now untangled (as much as possible), we need to
apply the mute setting with an explicit call to audio_mute().
Also apply the mute setting when the radio device node gets opened.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Frank Schaefer [Thu, 21 Mar 2013 16:51:17 +0000 (13:51 -0300)]
[media] bttv: separate GPIO part from function audio_mux()
Move the GPIO part of function audio_mux() to a separate function
audio_mux_gpio().
This prepares the code for the next patch which will separate mute and input
setting.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Frank Schaefer [Thu, 21 Mar 2013 16:51:14 +0000 (13:51 -0300)]
[media] bttv: audio_mux(): do not change the value of the v4l2 mute control
There are cases where we want to call audio_mux() without changing the value of
the v4l2 mute control, for example
- mute mute on last close
- mute on device probing
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Frank Schaefer [Thu, 21 Mar 2013 16:51:13 +0000 (13:51 -0300)]
[media] bttv: audio_mux(): use a local variable "gpio_mute" instead of modifying the function parameter "mute"
Function audio_mux() actually deals with two types of mute: gpio mute and
subdevice muting.
This patch claryfies the meaning of these values, but mainly prepares the code for
the next patch.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Wei Yongjun [Mon, 11 Mar 2013 12:57:22 +0000 (09:57 -0300)]
[media] davinci: vpfe: fix return value check in vpfe_enable_clock()
In case of error, the function clk_get() returns ERR_PTR()
and never returns NULL. The NULL test in the return value
check should be replaced with IS_ERR().
David Härdeman [Wed, 6 Mar 2013 19:52:05 +0000 (16:52 -0300)]
[media] rc-core: don't treat dev->rc_map.rc_type as a bitmap
store_protocols() treats dev->rc_map.rc_type as a bitmap which is wrong for
two reasons. First of all, it is pretty bogus to change the protocol type of
the keymap just because the hardware has been asked to decode a different
protocol.
Second, dev->rc_map.rc_type is an enum (i.e. a single protocol) as pointed
out by James Hogan <james.hogan@imgtec.com>.
Fix both issues by introducing a separate enabled_protocols member to
struct rc_dev.
Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Fri, 15 Feb 2013 18:00:20 +0000 (15:00 -0300)]
[media] s5p-tv: remove the dv_preset API from hdmiphy
The dv_preset API is deprecated and is replaced by the much improved dv_timings
API. Remove the dv_preset support from this driver as this will allow us to
remove the dv_preset API altogether (s5p-tv being the last user of this code).
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Tomasz Stanislawski <t.stanislaws@samsung.com> Acked-by: Tomasz Stanislawski <t.stanislaws@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Fri, 15 Feb 2013 17:59:48 +0000 (14:59 -0300)]
[media] s5p-tv: remove the dv_preset API from hdmi
The dv_preset API is deprecated and is replaced by the much improved dv_timings
API. Remove the dv_preset support from this driver as this will allow us to
remove the dv_preset API altogether (s5p-tv being the last user of this code).
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Tomasz Stanislawski <t.stanislaws@samsung.com> Acked-by: Tomasz Stanislawski <t.stanislaws@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Mon, 4 Mar 2013 12:32:00 +0000 (09:32 -0300)]
[media] s5p-tv: remove dv_preset support from mixer_video
The dv_preset API is deprecated and is replaced by the much improved dv_timings
API. Remove the dv_preset support from this driver as this will allow us to
remove the dv_preset API altogether (s5p-tv being the last user of this code).
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Tomasz Stanislawski <t.stanislaws@samsung.com> Acked-by: Tomasz Stanislawski <t.stanislaws@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Mon, 4 Mar 2013 12:28:57 +0000 (09:28 -0300)]
[media] s5p-tv: add dv_timings support for hdmiphy
This just adds dv_timings support without modifying existing dv_preset
support, although I had to refactor a little bit in order to share
hdmiphy_find_conf() between the preset and timings code.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Tomasz Stanislawski <t.stanislaws@samsung.com> Acked-by: Tomasz Stanislawski <t.stanislaws@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Lad, Prabhakar [Wed, 20 Mar 2013 04:28:27 +0000 (01:28 -0300)]
[media] davinci: vpif: Fix module build for capture and display
export the symbols which are used by two modules vpif_capture and
vpif_display. renamed "ch_params" to "vpif_ch_params" so as to avoid
name collision.
This patch fixes following error:
ERROR: "ch_params" [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: "vpif_ch_params_count" [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: "vpif_base" [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: "ch_params" [drivers/media/platform/davinci/vpif_capture.ko] undefined!
ERROR: "vpif_ch_params_count" [drivers/media/platform/davinci/vpif_capture.ko] undefined!
ERROR: "vpif_base" [drivers/media/platform/davinci/vpif_capture.ko] undefined!
make[1]: *** [__modpost] Error 1
Antti Palosaari [Sun, 10 Mar 2013 00:10:14 +0000 (21:10 -0300)]
[media] it913x: fix pid filter
I just made commit: "dvb_usb_v2: rework USB streaming logic" that
breaks that driver PID filter.
it913x driver checks use of PID filter directly from DVB USB v2 core
internal variable "adap->pid_filtering" and stores it to own state.
Calling order of .pid_filter_ctrl() and .pid_filter() was changed
and due to that state was updated too late. Update state earlier.
TODO: checking PID filter usage from DVB USB v2 is not very good idea
as PID filter callbacks are called only when PID filter is enabled.
Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Antti Palosaari [Sat, 9 Mar 2013 19:10:55 +0000 (16:10 -0300)]
[media] dvb_usb_v2: rework USB streaming logic
Control flow order changed a little bit. HW PID filter is now
disabled also when streaming is stopped - earlier it was just
set only when streaming was started.
Control flow is now:
* set streaming status bit
* submit USB streaming packets
* enable HW PID filter
* ask device to start streaming
* N x add PID to device HW PID filter
... streaming video ...
* N x remove PID from device HW PID filter
* ask device to stop streaming
* disable HW PID filter
* kill USB streaming packets
* clear streaming status bit
Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Antti Palosaari [Sat, 9 Mar 2013 03:16:32 +0000 (00:16 -0300)]
[media] dvb_usb_v2: replace Kernel userspace lock with wait queue
There was sync mutex which was held over userspace. That is very
wrong and could cause deadlock if different userspace process is
used to "unlock". Wait queue seems to be correct solution for
that kind of synchronizing issue so use it instead.
lock debug gives following bug report:
================================================
[ BUG: lock held when returning to user space! ]
3.9.0-rc1+ #38 Tainted: G O
------------------------------------------------
tzap/4614 is leaving the kernel with locks still held!
1 lock held by tzap/4614:
Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Fri, 22 Mar 2013 12:54:00 +0000 (09:54 -0300)]
[media] em28xx: tuner setup is broken after algo_data change
Commit aab3125c43d8fecc7134e5f1e729fabf4dd196da broke em28xx. I traced
this eventually to the change in what algo_data points to. This pointer
is also passed to em28xx_tuner_callback() through several hidden tuner
layers (yuck!) and that callback was not updated.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As complained by gcc:
drivers/media/usb/gspca/m5602/m5602_ov7660.c: In function 'ov7660_init':
drivers/media/usb/gspca/m5602/m5602_ov7660.c:99:9: warning: variable 'err' set but not used [-Wunused-but-set-variable]
It should be noticed that the original error code was crappy, as it wasn't
returning any error if sensor init fails.
Fix it by returning an error if the sensor can't be initialized.
Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Changeset 8f3741e accidentally broke the CNR estimation. It should
be calculated as "a + b - c". However, previously, the subtraction
by c only occurred if SNR would be positive, due to a bad binding
to DVBv3 API.
This also fixes the following warning:
drivers/media/dvb-frontends/drxk_hard.c:2556:6: warning: variable 'c' set but not used [-Wunused-but-set-variable]
Those are demodulator init tables according to used tuner tuner
config. af9033 demod driver does those inits currently and due
to that these duplicate inits could be removed.
Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Antti Palosaari [Thu, 7 Mar 2013 22:22:52 +0000 (19:22 -0300)]
[media] af9035: change dual mode boolean to bit field
For some reason there seems to be value 0x03 in eeprom for dual mode
(and 0x00 for single mode). Boolean is not always 1 bit wide - it
could be 8 bit wide too. Storing number 0x03 to boolean causes driver
to thing there is 4 tuners in some cases :o
Add also some comments regarding to eeprom.
Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>