Adds I2C registration of the Zilog Z8F0811 IR microcontroller for either
lirc_zilog or ir-kbd-i2c to use. This is a required step in removing
lirc_zilog's use of the deprecated struct i2c_adapter.id field.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The Zilog IR entries are already handled by IR new code. So,
remove its usage from the legacy IR support.
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
lirc-i2c implements a get key logic for the Adaptec Remote
Controller, at address 0x6b. The only driver that seems to have
an Adaptec device is ivtv:
$ git grep -i adaptec drivers/media
drivers/media/video/cs53l32a.c: * cs53l32a (Adaptec AVC-2010 and AVC-2410) i2c ivtv driver.
drivers/media/video/cs53l32a.c: * Audio source switching for Adaptec AVC-2410 added by Trev Jackson
drivers/media/video/cs53l32a.c: /* Set cs53l32a internal register for Adaptec 2010/2410 setup */
drivers/media/video/ivtv/ivtv-cards.c:/* Adaptec VideOh! AVC-2410 card */
drivers/media/video/ivtv/ivtv-cards.c: { PCI_DEVICE_ID_IVTV16, IVTV_PCI_ID_ADAPTEC, 0x0093 },
drivers/media/video/ivtv/ivtv-cards.c: .name = "Adaptec VideOh! AVC-2410",
drivers/media/video/ivtv/ivtv-cards.c:/* Adaptec VideOh! AVC-2010 card */
drivers/media/video/ivtv/ivtv-cards.c: { PCI_DEVICE_ID_IVTV16, IVTV_PCI_ID_ADAPTEC, 0x0092 },
drivers/media/video/ivtv/ivtv-cards.c: .name = "Adaptec VideOh! AVC-2010",
drivers/media/video/ivtv/ivtv-cards.h:#define IVTV_CARD_AVC2410 7 /* Adaptec AVC-2410 */
drivers/media/video/ivtv/ivtv-cards.h:#define IVTV_CARD_AVC2010 8 /* Adaptec AVD-2010 (No Tuner) */
drivers/media/video/ivtv/ivtv-cards.h:#define IVTV_PCI_ID_ADAPTEC 0x9005
drivers/media/video/ivtv/ivtv-driver.c: "\t\t\t 8 = Adaptec AVC-2410\n"
drivers/media/video/ivtv/ivtv-driver.c: "\t\t\t 9 = Adaptec AVC-2010\n"
drivers/media/video/ivtv/ivtv-i2c.c: 0x6b, /* Adaptec IR */
There are two Adaptec cards defined there, but AVC-2010 doesn't have a
remote controller. So, the logic at lirc_i2c seems to be for Adaptec AVC-2410.
As we'll remove lirc_i2c from kernel, move the getkey code to ivtv driver, and
use it for AVC-2410.
Reviewed-by: Andy Walls <awalls@md.metrocast.net>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently, lirc-i2c has a decoding logic for Leadtek Remote
Control. Move it to cx88, as we intend to remove lirc-i2c.
For now, initialize LIRC remote keytable with RC_MAP_EMPTY, as
we don't know its keymap yet. It would be nice to later check
if is there any file on LIRC userspace with that keytable.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When comparing lirc-i2c and ir-kbd-i2c/bttv-input logic, a difference
was noticed. As lirc-i2c will be removed soon, store the difference on
a comment inside ir-kbd-i2c, in order to preserve the knowledge we
have about that remote controller.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix 64-bit compile warning:
drivers/media/video/timblogiw.c: In function ‘timblogiw_dma_filter_fn’:
drivers/media/video/timblogiw.c:151: warning: cast from pointer to integer of different size
drivers/media/video/timblogiw.c: In function ‘timblogiw_open’:
drivers/media/video/timblogiw.c:670: warning: cast to pointer from integer of different size
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Richard Rojförs <richard.rojfors@pelagicore.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The v4l core sets the v4l2_input.capabilities field based on the supplied
v4l2_ioctl_ops. However, several drivers do a memset or memcpy of the v4l2_input
struct, thus overwriting that field incorrectly.
Either remove the memset (which is already done by the v4l core), or add the
proper capabilities field in case of a memcpy.
The same is also true for v4l2_output, but that only affected the ivtv driver.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Calling subdevs to handle s_ctrl returned a non-zero return code even if
everything went fine.
Calling STREAMOFF if no STREAMON happened earlier would hit a BUG_ON
in res_free.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The 'def' field is only valid for menus, integers and booleans.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This prevents checkpatch warnings generated when defining
'static const char *foo[]' arrays. It makes sense to use
const char * const * anyway since the pointers in the array
are indeed const.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Convert driver to use core-assisted locking.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The naming of the media/rds.h header suggested that it was a generic
RDS header, when in fact it is just a saa6588 module API that is
internal to the kernel.
Rename the header and the struct and defines in it to make this clear.
Also removed the header include in radio-si470x.h (not used anymore)
and from ioctl-number.txt (it's internal to the kernel and never called
from userspace).
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use put_device() instead of kfree() because of device name leak.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Acked-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some comments:
1. Everything initialize properly except radio.
2. All analog inputs (TV, composite, S-Video) are tested by myself in several
TV norms (SECAM-D, PAL, NTSC), everything work fine.
So the patch adds general support/detection of the card with working analog
part, DVB part is not supported for now.
Signed-off-by: Alexey Chernov <4ernov@gmail.com>
Reviewed-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
A Hauppauge HVR 4000 is used on a School On Internet Asia (SOI Asia)
project in order to carry IP traffic over ULE. However, there is an
issue with high latency jitter.
My boss, Husni, identified the problem and provided a patch for it.
The default buffer size of 32 TS frames on cx88 causes the high latency,
so our deployment changes that to 6 TS frames. This patch made the
buffer size tunable, while keeping the default buffer size of 32 TS
frames unchanged.
Signed-off-by: Achmad Husni Thamrin <husni@ai3.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The original code compared "saddr_len" with zero twice in a nonsensical
way. I asked the list, and Andy Walls and Sri Deevi say that the second
check should be if "saddr_len == 1".
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Srinivasa Deevi <Srinivasa.deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
VIDIOC_QUERYSTD and VIDIOC_G_STD ioctls are currently not
supported in the FSL VIU driver. The decoder subdevice
driver saa7115 extended by previous patch supports QUERYSTD
for saa711x, so we add the appropriate ioctls to the VIU
driver to be able to determine the video input's standard.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Autodetect input's standard using field frequency detection
feature (FIDT in status byte at 0x1F) of the chips saa7111/
saa7111a/saa7113/saa7114/saa7118.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
These devices do not return the full command+address, so set
scanmask accordingly.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
dabusb driver were conceived as an experimental driver for a test
device. The driver never supported any shipped product, and, while
there were some updates on it in 2003, for an ancient product,
those changes were never submitted upstream.
Also, there's no DocBook for its API, nor any upstream discussion.
So, better to remove it, on .39. If later needed, we may rescue it
from git logs. For now, let's move it to staging.
Acked-by: Deti Fliegl <deti@fliegl.de>
Cc: Deti Fliegl <deti@fliegl.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/rc/streamzap.c: In function ‘streamzap_probe’:
drivers/media/rc/streamzap.c:460:2: warning: statement with no effect
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/dvb/frontends/af9013.c: In function ‘af9013_update_signal_strength.clone.0’:
drivers/media/dvb/frontends/af9013.c:967:6: warning: ‘ret’ may be used uninitialized in this function
Cc: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
A few typos at the driver are causing the following warnings:
drivers/media/dvb/frontends/stv090x.c: In function ‘stv090x_start_search’:
drivers/media/dvb/frontends/stv090x.c:1486:27: warning: comparison between ‘enum stv090x_search’ and ‘enum stv090x_delsys’
drivers/media/dvb/frontends/stv090x.c:1487:24: warning: comparison between ‘enum stv090x_search’ and ‘enum stv090x_delsys’
drivers/media/dvb/frontends/stv090x.c: In function ‘stv090x_optimize_track’:
drivers/media/dvb/frontends/stv090x.c:2943:2: warning: case value ‘4’ not in enumerated type ‘enum stv090x_delsys’
The first two are due to the lack of using the delsys types
STV090x_DVBS1/STV090x_DSS
instead of
STV090x_SEARCH_DVBS1/STV090x_SEARCH_DSS
The second one is due to the usage of STV090x_UNKNOWN (enum stv090x_modulation)
instead of STV090x_ERROR (enum stv090x_delsys).
Cc: Manu Abraham <abraham.manu@gmail.com>
Signed-off-by: Mauro 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: Mauro Carvalho Chehab <mchehab@redhat.com>
Fixes several warnings:
drivers/media/dvb/frontends/dib7000m.c: In function ‘dib7000m_set_channel’:
drivers/media/dvb/frontends/dib7000m.c:808:3: warning: case value ‘255’ not in enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000m.c:869:3: warning: case value ‘255’ not in enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000m.c: In function ‘dib7000m_tune’:
drivers/media/dvb/frontends/dib7000m.c:1023:3: warning: case value ‘255’ not in enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000m.c:1033:3: warning: case value ‘255’ not in enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000m.c:1043:3: warning: case value ‘255’ not in enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000p.c: In function ‘dib7000p_set_channel’:
drivers/media/dvb/frontends/dib7000p.c:720:3: warning: case value ‘255’ not in enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000p.c:773:3: warning: case value ‘255’ not in enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000p.c: In function ‘dib7000p_tune’:
drivers/media/dvb/frontends/dib7000p.c:997:3: warning: case value ‘255’ not in enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000p.c:1007:3: warning: case value ‘255’ not in enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000p.c:1017:3: warning: case value ‘255’ not in enumerated type ‘fe_transmit_mode_t’
The drivers were prepared to support 4K carriers, but as the define were added
later, they were using a "magic" value of 255.
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/radio/radio-wl1273.c: In function ‘wl1273_fm_upload_firmware_patch’:
drivers/media/radio/radio-wl1273.c:675:2: warning: ‘n’ may be used uninitialized in this function
drivers/media/radio/radio-wl1273.c:675:2: warning: ‘i’ may be used uninitialized in this function
Those vars are never initialized, and the debug message makes no sense, as it
will show just two random values.
Cc: Matti J. Aaltonen <matti.j.aaltonen@nokia.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/dvb/dvb-core/dmxdev.c: In function ‘dvb_dmxdev_start_feed’:
drivers/media/dvb/dvb-core/dmxdev.c:583:13: warning: comparison between ‘enum dmx_ts_pes’ and ‘enum <anonymous>’
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This comment mentions a field that doesn't exist, and talks about
videodev.h that got removed. So, it doesn't make any sense to keep
it.
Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There's no sense on keeping it on 2.6.38, as nobody is using it
anymore, at the kernel tree, and installing it at the userspace
API.
As two deprecated drivers still need it, move it to their internal
directories.
Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There's no sense on keeping VIDEO_V4L1 Kconfig option just because of
two deprecated drivers moved to staging scheduled to die on 2.6.39.
Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If write() on a VBI device node fails due to a bad buffer pointer from
userspace, we should notify the application properly with EFAULT, per the
V4L2 API spec.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
ivtv_write_vbi() is used for both VBI data that came from the
driver internally and VBI data that came from the user. However,
it did not use copy_from_user() for reading the VBI data from the
user buffers.
This change adds a new version of the function,
ivtv_write_vbi_from_user(), that uses copy_from_user() to read the VBI
data provided via user buffers.
This should resolve a sparse build warning reported by Dave Gilbert.
Reported-by: Dr. David Alan Gilbert <linux at treblig.org>
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
