Signed-off-by: NJose Alberto Reguero <jareguero@telefonica.net>
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch reduces the number of available choices for the notch filter type control
so that the standard-specific filter types cannot be selected. It is now limited to
being either 0 (4xFsc, the default) or 1 (square pixel optimized).
The patch also removes the initialization of this control from cx88_reset(), since
that is already done by init_controls(), which is called by cx8800_initdev().
Signed-off-by: NIstvan Varga <istvan_v@mailbox.hu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Use the more current logging styles with pr_fmt.
Remove now unnecessary private include.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Deduplicate printk formats to save ~20KB text.

$ size drivers/media/common/tuners/tda18271*o.*
   text	   data	    bss	    dec	    hex	filename
  10747	     56	   1920	  12723	   31b3	drivers/media/common/tuners/tda18271-common.o.new
  18889	     56	   3112	  22057	   5629	drivers/media/common/tuners/tda18271-common.o.old
  20561	    204	   4264	  25029	   61c5	drivers/media/common/tuners/tda18271-fe.o.new
  31093	    204	   6000	  37297	   91b1	drivers/media/common/tuners/tda18271-fe.o.old
   3681	   6760	    440	  10881	   2a81	drivers/media/common/tuners/tda18271-maps.o.new
   5631	   6760	    680	  13071	   330f	drivers/media/common/tuners/tda18271-maps.o.old
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Style issue.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Thanks to Thomas Gutzler for reporting this.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Cc: Thomas Gutzler <thomas.gutzler@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Convert array index from the loop bound to the loop index.

A simplified version of the semantic patch that fixes this problem is as

// <smpl>
@@
expression e1,e2,ar;
@@

for(e1 = 0; e1 < e2; e1++) { <...
  ar[
- e2
+ e1
  ]
  ...> }
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

[media] Add support for new revision of KNC 1 DVB-C cards. Using tda10024 instead of tda10023, which is compatible to tda10023 driver
Signed-off-by: NJulian Scheel <julian@jusst.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NBenjamin Larsson <benjamin@southpole.se>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Driver for Kworld UB499-2T (id 1b80:e409)

The device driver has been named it913x, so that support for other family members
can be added later.

TODOs
Firmware support for other it913x devices.
Remote control support, there are two known types.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
[mchehab@redhat.com: Fix a merge conflict]
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Firmware information for Kworld UB499-2T T09 based on IT913x series. This device
uses file dvb-usb-it9137-01.fw.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fronted and Tuner Driver for ITE IT913x Series with inital support for
IT9137 integrated demodulator and tuner device.

The driver is loosely based on AF9035 series. However, support is not intended for
this device specificity.

The IT9137 tuner has been tested on UHF bands, but VHF has only been simulated.

Possible TODO the tuner sections may be separated from the main driver. All future devices
should use the it913x_fe_script_loader for other tuner devices.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
[mchehab@redhat.com: Fix an issue at the Kconfig help]
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Siano modules already had sms_dbg flag which is a module parameter which
sets the debug mode so module prints messages to dmesg for debugging.
The variable was static therefore apply only to the file which defines
the module. In modules as smsmdtv.ko that contain a few files, the debug
flag applied only for functions in that main file.
flag was changed to be non-static and therefore can be accessed by all
module files (although it is still not exported out of the module).
Signed-off-by: NDoron Cohen <doronc@siano-ms.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add note about recent updates coming from Microsoft's publicly available
specs on Windows Media Center remotes and receivers/transmitters.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Rather than dumping out hex values, lets print the actual calculated
frequency and period the hardware has been configured for. After this

[ 2643.276215] mceusb 3-1:1.0: tx data: 9f 07 (length=2)
[ 2643.276218] mceusb 3-1:1.0: Get carrier mode and freq
[ 2643.277206] mceusb 3-1:1.0: rx data: 9f 06 01 42 (length=4)
[ 2643.277209] mceusb 3-1:1.0: Got carrier of 37037 Hz (period 27us)

Matches up perfectly with the table in Microsoft's docs.

Of course, I've noticed on one of my devices that the MS-recommended
default value of 1 for carrier pre-scaler and 66 for carrier period was
butchered, and instead of converting 66 to hex (0x42 like above), they
put in 0x66, so the hardware reports a default carrier of 24390Hz.
Fortunately, I guess, this particular device is rx-only, but I wouldn't
put it past other hw to screw up here too.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

According to the specs, you can read the number of tx ports, number of
rx sensors, which tx ports have cables plugged into them, and which rx
sensors are active. In practice, most of my devices do seem to report
sane values for tx ports and rx sensors (but not all -- one without any
tx ports reports having them), and most report the active sensor
correctly, but only one of eight reports cabled tx ports correctly. So
for the most part, this is just for informational purposes.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Supposedly, there are essentially three different classes of devices
that are compatible with Microsoft's specs. First are the "legacy"
devices, which are built using Microsoft-provided hardware specs and
firmware. Second are "emulator" devices, which are built using custom
hardware and firmware, written to emulate Microsoft's firmware. Third
are "port" devices, which have their own device driver and firmware,
which provides compatible data to higher levels of the stack.

>From what I can tell, things like nuvoton-cir and fintek-cir are
essentially "port" devices -- their raw IR buffer format is very similar
to that of the mceusb devices. Now, within the mceusb driver, we have
three different "generations", which at first, seemed like maybe they
mapped to emulator versions. Unfortuantely, every single device I have
responds "illegal command" to the query to get firmware emulator version
from the hardware, which means they're either all emulator version 1, or
they're legacy devices, and our different "generations" aren't at all
related here. Though in theory, its possible the gen1 devices are
"legacy" devices and the rest are emulator v1. There are some useful
features of the v2 interface I was hoping to play with, but alas...
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

According to MS docs, the device firmware may halt after receiving an
unknown instruction, but that it should be possible to tell the firmware
to continue running by simply sending a device resume command. So lets
do that.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Its not uncommon for folks to force these bits enabled, because people
do want to wake their htpc kit via their remote. Lets just set the bits
for 'em.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Sometimes the init routine is blasting commands out to the hardware
faster than it can reply. Throw a brief delay in there to give the
hardware a chance to reply before we send the next command.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

I was recently pointed to the document titled
Windows-Media-Center-RC-IR-Collection-Green-Button-Specification-03-08-2011-V2.pdf
which as of this writing, is publicly available from
download.microsoft.com. It covers a LOT of the gaps in the mceusb
driver, which to this point, was written almost entirely by
reverse-engineering. First up, I'm updating the defines for all the MCE
commands and responses to match their names in the spec. More to come...
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

tda827x is currently taking the demod IF frequency into account while
seeking for the proper tuner range. This is wrong, as the demod IF
frequency has nothing to do with the tuner PLL.
Signed-off-by: NJose Alberto Reguero <jareguero@telefonica.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Hello,

When migrating from Slackware 13.1 to 13.37 (kernel 2.6.33.x to
2.6.37.6), there was some sort of regression with the external webcam
installed at the notebook (0x45:6128, SN9C325+OM6802).

In the version 2.6.37.6, the images got *very* dark, making the webcam
almost unusable, unless if used with direct sunlight.

Tracing back what happened, I concluded that changeset 0e4d413a
caused some sort of odd effects - including this - to this specific model.
Signed-off-by: NLuiz Carlos Ramos <lramos.prof@yahoo.com.br>
Acked-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There are folks with flaky imon hardware out there that doesn't always
respond to requests to write to their displays for some reason, which
can flood logs quickly when something like lcdproc is trying to
constantly update the display, so lets rate-limit all that error spew.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If the bus has been reset on resume, set the alternate setting to 0.
This should be the default value, but some devices crash or otherwise
misbehave if they don't receive a SET_INTERFACE request before any other
video control request.

Microdia's 0c45:6437 camera has been found to require this change or it
will stop sending video data after resume.

uvc_video.c]
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: stable@kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This device is not using the proper demod IF. Instead of using the
IF macro, it is specifying a IF frequency. This doesn't work, as xc3028
needs to load an specific SCODE for the tuner. In this case, there's
no IF table for 5 MHz.

Cc: stable@kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Move documentation of structures used in DQEVENT from SUBSCRIBE_EVENT to
DQEVENT.
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Potentially the adp1653_init_controls could return an error. In our case the
error was ignored, meanwhile it means incorrect initialization of V4L2
controls. Additionally we have to free control handler structures in case of
apd1653_init_controls or media_entity_init failure.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The driver requires platform_data to be present. That's why we need to check
and fail in case of the absence of necessary data.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The goal of this patch is to correct a previous patch. In case of error,
the err() function should be used instead of dprintk() function.

[mchehab@redhat.com: as I've replaced dprintk by deb_info, on the the
 previous patch, to avoid breaking bisect, I had to fix a merge conflict
 on this one]
Signed-off-by: NOlivier Grenie <olivier.grenie@dibcom.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch protects the common buffer access inside the dib0700 in order
to manage concurrent access. This protection is done using mutex.

Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Florian Mickler <florian@mickler.org>
Cc: stable@kernel.org
Signed-off-by: NJavier Marcet <javier@marcet.info>
Signed-off-by: NOlivier Grenie <olivier.grenie@dibcom.fr>
Signed-off-by: NPatrick Boettcher <patrick.boettcher@dibcom.fr>
[mchehab@redhat.com: dprint requires 3 arguments. Replaced by dib_info]
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch protects the I2C buffer access in order to manage concurrent
access. This protection is done using mutex.
Furthermore, for the dib9000, if a pid filtering command is
received during the tuning, this pid filtering command is delayed to
avoid any concurrent access issue.

Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Florian Mickler <florian@mickler.org>
Cc: stable@kernel.org
Signed-off-by: NOlivier Grenie <olivier.grenie@dibcom.fr>
Signed-off-by: NPatrick Boettcher <Patrick.Boettcher@dibcom.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Whan an ioctl is implemented, but the parameters are invalid,
the error code should be -EINVAL. However, if the ioctl is
not defined, it should return -ENOTTY instead.
Reported-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Change adapter FE pointer as array of FE pointers.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The input stop() callback already calls the em28xx_ir_stop method.
Calling it again causes an oops.
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

rc unregister logic were deadly broken, preventing some drivers to
be removed. Among the broken things, rc_dev_uevent() is being called
during device_del(), causing a data filling on an area that it is
not ready anymore.

Also, some drivers have a stop callback defined, that needs to be called
before data removal, as it stops data polling.
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>