It is AF9015+AF9013+2xMXL5007T.
Tanks to Bernard Giannetti and DigitalNow for the help!
Signed-off-by: Antti Palosaari <crope@iki.fi>
Cc: Renura Enterprises Pty Ltd <renura@digitalnow.com.au>
Cc: Bernard Giannetti <thebernmeister@hotmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Read all remote controller registers at once to reduce USB remote polling traffic.
Use .rc_codes() to disable / enable remote polling instead of .rc_query().
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The Digital Everywhere firmware have the shortcoming that ca_info_enq and
ca_info are not supported. This means that we can never retrieve the correct
ca_system_id to present in the CI message CA_INFO. Currently the driver uses
the application id retrieved using app_info_req and app_info, but this id
only match the correct ca_system_id as given in ca_info in some cases.
This patch adds a parameter to the driver in order for the user to override
what will be returned in the CA_INFO CI message. Up to four ca_system_ids can
be specified.
This is needed for users with CAMs that have different manufacturer id and
ca_system_id and that uses applications that take this into account, like
MythTV.
Signed-off-by: Henrik Kurelid <henrik@kurelid.se>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds audio DMA capture and ALSA mixer elements for the line
input jack of the Hauppauge Nova-S-plus DVB-S PCI card. The Nova-S-plus
has a WM8775 ADC that is currently not detected. This patch enables
this chip and exports volume, balance mute and ALC elements for ALSA
mixer controls.
[mchehab@redhat.com: Fix CodingStyle issues]
Signed-off-by: Lawrence Rust <lawrence@softsystem.co.uk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- serialize the suspend and resume functions using the global lock.
- do not call usb_autopm_put_interface after a disconnect.
- fix a race when disconnecting the device.
Reported-by: David Ellingsworth <david@identd.dyndns.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: David Ellingsworth<david@identd.dyndns.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Indent the branch of an if.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r disable braces4@
position p1,p2;
statement S1,S2;
@@
(
if (...) { ... }
|
if (...) S1@p1 S2@p2
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
if (p1[0].column == p2[0].column):
cocci.print_main("branch",p1)
cocci.print_secs("after",p2)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
These include
-later kill of usb_buffer to avoid kernel crash on hot unplugging.
-DiSEqC functions.
-LNB Power switch
-Faster channel change.
-support for LG tuner on LME2510C.
-firmware switching for LG tuner.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> From: Dan Carpenter [mailto:error27@gmail.com]
>
> These are signed so instead of being 1 and 0 as intended they are -1 and
> 0. It doesn't cause a bug in the current code but Sparse warns about
> it:
>
> drivers/media/video/s5p-fimc/fimc-core.h:226:28:
> error: dubious one-bit signed bitfield
> struct fimc_scaler {
> - int scaleup_h:1;
> - int scaleup_v:1;
> - int copy_mode:1;
> - int enabled:1;
> + unsigned int scaleup_h:1;
> + unsigned int caleup_v:1;
> + unsigned int copy_mode:1;
> + unsigned int enabled:1;
In general I agree, however this patch would change scaleup_v:1
to caleup_v, so it cannot be applied in current form.
Here is the corrected patch:
Reported-by: Dan Carpenter <error27@gmail.com<
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There was an unlock missing if kzalloc() failed.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the v4l2_i2c_new_subdev* functions now supporting loading modules
based on modaliases, replace the hardcoded module name passed to those
functions by NULL.
The sub-devices without a listed module name don't result in and I2C
sub-device being created, as they either are IR devices or don't have an
I2C address listed. It's thus safe to rely on modaliases only.
All corresponding I2C modules have been checked, and all of them include
a module aliases table with names corresponding to what the cx18 driver
uses.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the v4l2_i2c_new_subdev* functions now supporting loading modules
based on modaliases, replace the hardcoded module name passed to those
functions by NULL.
The sub-devices without a listed module name don't result in and I2C
sub-device being created, as they either are IR devices or don't have an
I2C address listed. It's thus safe to rely on modaliases only.
All corresponding I2C modules have been checked, and all of them include
a module aliases table with names corresponding to what the ivtv driver
uses.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the v4l2_i2c_new_subdev* functions now supporting loading modules
based on modaliases, don't use the module names hardcoded in platform
data by passing a NULL module name to those functions.
The only platform using the VPIF capture device (DM646x EVM) hardcodes
the module names to invalid values (tvp514x-0 and tvp514x-1). As this is
already broken, there's no risk of breaking it more.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the v4l2_i2c_new_subdev* functions now supporting loading modules
based on modaliases, don't use the module names hardcoded in platform
data by passing a NULL module name to those functions.
All corresponding I2C modules have been checked, and all of them include
a module aliases table with names corresponding to what the vpif_display
platform data uses.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the v4l2_i2c_new_subdev* functions now supporting loading modules
based on modaliases, don't use the module names hardcoded in platform
data by passing a NULL module name to those functions.
All corresponding I2C modules have been checked, and all of them include
a module aliases table with names corresponding to what the vpfe_capture
platform data uses.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the v4l2_i2c_new_subdev* functions now supporting loading modules
based on modaliases, remove the module names hardcoded in platform data
and pass a NULL module name to those functions.
All corresponding I2C modules have been checked, and all of them include
a module aliases table with names corresponding to what the soc_camera
platform data uses.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the v4l2_i2c_new_subdev* functions now supporting loading modules
based on modaliases, replace the hardcoded module name passed to those
functions by NULL.
As no board seems to use this driver, no platform data has been checked.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the v4l2_i2c_new_subdev* functions now supporting loading modules
based on modaliases, remove the module names hardcoded in platform data
and pass a NULL module name to those functions.
All corresponding I2C modules have been checked, and all of them include
a module aliases table with names corresponding to what the sh_vou
platform data uses.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the v4l2_i2c_new_subdev* functions now supporting loading modules
based on modaliases, replace the hardcoded module name passed to those
functions by NULL.
All corresponding I2C modules have been checked, and all of them include
a module aliases table with names corresponding to what the pvrusb2
driver uses.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-By: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the v4l2_i2c_new_subdev* functions now supporting loading modules
based on modaliases, replace the hardcoded module name passed to those
functions by NULL.
All corresponding I2C modules have been checked, and all of them include
a module aliases table with names corresponding to what the zoran driver
uses.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the v4l2_i2c_new_subdev* functions now supporting loading modules
based on modaliases, replace the hardcoded module name passed to those
functions by NULL.
All corresponding I2C modules have been checked, and all of them include
a module aliases table with names corresponding to what the drivers
modified here use.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When creating a new sub-device, The V4L I2C subdev API has historically
required drivers to pass the name of the module that implements support
for the I2C device.
I2C modules can be loaded based on modaliases instead of the module
name. As the I2C device type name is already available to the
v4l2_i2c_new_subdev* functions, make the module name argument optional
and create a modalias based on the type name when no module name is
provided.
All in-tree drivers call those functions with a non-NULL module name
argument, this change is thus harmless.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This was supposed to be an unlock on the error path.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Cc: Palash Bandyopadhyay < palash.bandyopadhyay@conexant.com>
Cc: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fixes a gcc warning:
drivers/media/video/cx88/cx88-video.c:772:
warning: ‘core’ may be used uninitialized in this function
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch allows this device successfully to show video, at least from
its composite input.
I have no information about the true hardware contents of this device and so
this patch is based solely on fiddling with things until it worked. The
chip appears to be em2860, and the closest device with equivalent inputs
is the Typhoon DVD Maker. Copying the settings for that device appears
to do the trick. That's what this patch does.
[mchehab@redhat.com: update CARDLIST.em28xx accordingly, via script]
Signed-off-by: Adrian Taylor <adrian.taylor@realvnc.com>
Reviewed-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Provides more complete debug spew, parses individual commands and raw IR
data one chunk at a time.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
And replace usage of hex values w/symbolic names wherever possible
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It is better to use a per-model device name, especially on
multi-function devices like Polaris. So, allow overriding the
default name at the mceusb model table.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Especially when used with Polaris boards, devices may have different
types of remotes shipped. So, we need a per-model rc-map.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
The previous logic needed duplicate USB table structs, one to store
the list of the devices, and 3 sets of other structs, to store the
quirks list.
With this change, devices that require expecial quirks just need to
have a .driver_info = <quirk entry>.
It also allows adding some extra quirks, like per-model RC tables.
As a bonus, this patch reduced in 10% the data segment size:
text data bss dec hex filename
15487 5008 4 20499 5013 old/mceusb.ko
15438 4496 4 19938 4de2 new/mceusb.ko
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Switch to a state machine that properly handles all incoming urb data
packets, and reads much cleaner and corrects some minor parsing errors
that were hindering decode on cx231xx/Polaris integrated IR. Also tested
with four different mceusb variants, and works perfectly with all of
them (at least for the rc6a mce remotes).
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Fixes an oops when an lirc driver that doesn't provide its own fops is
unplugged while the lirc cdev is open. Tested with lirc_igorplugusb,
with a special thanks to Timo Boettcher for providing the test hardware.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Can't explain it (yet), but I've seen the 'get irctl via private_data'
setup fail for a number of people (ioctl called before its filled in?),
so lets go back to a variant of the old way, but one that still works
with unlocked_ioctl.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If an lirc device driver doesn't specify its own fops, we set set
ir->cdev.owner to THIS_MODULE. If it does specify its own fops, we
set ir->cdev.owner to ir->d.owner. Subsequent module_{get,put} calls
should be using ir->cdev.owner, not ir->d.owner.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use names that clearly identify functions as lirc functions.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The errors were found by checkpatch.pl. Most fixes are:
- remove spaces followed by TAB(s),
- split lines greater than 80 characters,
- move most '{'s from start of line to end of previous line.
(Some '{'s at start of line remain when the '}'s are on the same line)
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The PO2030N sensor chip found in hama AC-150 webcam supports horizontal
and vertical flipping the image by hardware.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The number 0xdd is used for marking delay init sequence steps.
Replace 0xdd values only if the meaning is delay.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bug was introduced by commit d5aa3856fd
removing the probe sequence of hv7131r with bridge sn9c120 and so, letting
the sensor inactive.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bug was introduced by commit 23a98274cc
applying values of sensor sp80708 to sensors hv7131r and mi0360.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add a driver for the video capture port on VIA integrated chipsets. This
version has a remaining OLPCism or two and expects to be talking to an
ov7670; those can be improved as the need arises.
This work was supported by the One Laptop Per Child project.
Thanks to Laurent Pinchart for a number of useful comments.
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The QVGA mode has a green horizontal line on the left hand side, and a red
(or sometimes blue) vertical line at the bottom. Tweak the visible area
to remove them.
Thanks to Mauro for explaining how to fix this.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>