Both sides of these assignments actually have type "const struct
vb2_mem_ops *", so the casts are unnecessary and slightly confusing.
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

X-Patchwork-Delegate: m.chehab@samsung.com
Fixes the following sparse warnings:
	drivers/media/dvb-frontends/af9033.c:295 af9033_init() error: buffer overflow 'clock_adc_lut' 11 <= 11
	drivers/media/dvb-frontends/af9033.c:300 af9033_init() error: buffer overflow 'clock_adc_lut' 11 <= 11
	drivers/media/dvb-frontends/af9033.c:584 af9033_set_frontend() error: buffer overflow 'coeff_lut' 3 <= 3
	drivers/media/dvb-frontends/af9033.c:595 af9033_set_frontend() error: buffer overflow 'clock_adc_lut' 11 <= 11
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Userspace expects to see a long space before the first pulse is sent on
the lirc device.  Currently, if a long time has passed and a new packet
is started, the lirc codec just returns and doesn't send anything.  This
makes lircd ignore many perfectly valid signals unless they are sent in
quick sucession.  When a reset event is delivered, we cannot know
anything about the duration of the space.  But it should be safe to
assume it has been a long time and we just set the duration to maximum.
Signed-off-by: NAustin Lund <austin.lund@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

DVBSky S952 V3 card has a dual channels of dvb-s/s2.
1>Frontend: Integrated tuner and demod: M88RS6000
2>PCIe bridge: SMI PCIe
Signed-off-by: NNibble Max <nibble.max@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Add myself as maintainer for the CODA V4L2 mem2mem driver.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

That case is not IO error, so better to jump out now, but still
continue polling.

Cc: Bimow Chen <Bimow.Chen@ite.com.tw>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Previous patch changed both AF9030 and IT9130 SNR reporting from
dB to relative. Restore AF9030 to old behavior as it has been always
returning 0.1 dB value. Leave IT9130 relative as old IT9130 was
returning relative values.

Cc: Bimow Chen <Bimow.Chen@ite.com.tw>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Snr returns value not correct. Fix it.
Signed-off-by: NBimow Chen <Bimow.Chen@ite.com.tw>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Check return status after each register access routine and avoid
masking return status values.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Previous patch changes used signal strength firmware register from
0x800048 to 0x80004a in case of AF9033/AF9035 chip. In practice
reported values were running upside-down, when RR strength increases
reported value decreases and vice versa. That is because of 0x80004a
returns values that are dBm scale, but negative RF strength dBm
returned as positive number.

0x800048 returns 0-100, like percentage
0x80004a returns 0-255 dBm, without a negative sign

So restore old measurement now.

Cc: Bimow Chen <Bimow.Chen@ite.com.tw>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Register 0x800048 is not dB measure but relative scale. Fix it and conform to NorDig specifications.
Signed-off-by: NBimow Chen <Bimow.Chen@ite.com.tw>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

It repeated "found a 'Silicon Labs Si2168' in warm state" everytime
when device was opened. Message is aimed to point out firmware is
downloaded, up and running. So print it only in case firmware download
is performed.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Patch "[media] media: Print information on failed link validation" cause a
harmless compiler warning in printing a debug message. Fix this.

The type casting is done do ensure the type really is suitable for printing
as %u, as find_first_zero_bit() does return int on some architectures and
unsigned long on others.
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

As reported by kbuild test robot:
	drivers/media/usb/cx231xx/cx231xx-audio.c:445:16-20: ERROR: dev is NULL but dereferenced.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Reported-by: NJulia Lawall <julia.lawall@lip6.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

M88RS6000 is the integrated chip, which includes tuner and demod. Its
internal demod is similar with M88DS3103 except some registers
definition.

The main different part of this internal demod from others is its
clock/pll generation IP block sitting inside the tuner die. So clock/pll
functions should be configed through its tuner i2c bus, NOT its demod
i2c bus.

The demod of M88RS6000 need the firmware: dvb-demod-m88rs6000.fw
firmware download link:
	http://www.dvbsky.net/download/linux/dvbsky-firmware.tar.gzSigned-off-by: NNibble Max <nibble.max@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

M88RS6000 is the integrated chip, which includes tuner and demod.
Here splite its tuner as a standalone driver.
.set_config is used to config its demod clock, which sits inside tuner die.
Signed-off-by: NNibble Max <nibble.max@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Fix two small CodingStyle issues
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

There is a new PCIe bridge chip(from SMI) used in DVBSky V3 seris cards, include S950 V3 and S952 V3 cards.
SMI pcie bridge chip is PCIe 1.1 compliant, supports MSI feature.
Main interface blocks:
1>Two DVB transport stream input ports(ts0,ts1).
2>Two I2C master bus(i2c0, i2c1).
3>IR controller.
4>reset pins and other GPIOs.

DVBSky S950 V3 card has a single channel of dvb-s/s2.
1>Frontend: tuner: M88TS2022, demod: M88DS3103
2>PCIe bridge: SMI PCIe
The current driver does not support SMI IR function.

[mchehab@osg.samsung.com: fix Makefile to find m88ts2022.h]
Signed-off-by: NMax nibble <nibble.max@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

If alloc_workqueue() fails, we should go to the 'err_v4l2_register' label, which
will unregister the v4l2 device.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Instead of calling v4l2_device_unregister() in multiple locations within the
error paths, let's call it from a single location to make the error handling
simpler.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

X-Patchwork-Delegate: m.chehab@samsung.com
As pointed by smatch:
	drivers/media/pci/cx23885/cx23885-dvb.c:1066 dvb_register() error: we previously assumed 'fe0->dvb.frontend' could be null (see line 1060)
	drivers/media/pci/cx23885/cx23885-dvb.c:1990 cx23885_dvb_register() error: we previously assumed 'fe0' could be null (see line 1975)

What happens is that the error handling logic when a frontend
register fails sometimes keep doing the work, as if it didn't
fail.

This could potentially cause an OOPS. So, simplify the logic
a little bit and return an error if frontend fails before
trying to setup VB2 queue.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

TechnoTrend CT2-4500 CI is a PCIe device with DVB-T2/C tuner. It is
similar to DVBSky T980C, just with different PCI ID and remote controller.
Signed-off-by: NOlli Salonen <olli.salonen@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The update was supplied directly by PCTV.

Add tuner ids 182-188.
Add audproc ids 45-52.
Add decoder chip ids 43-53.
Use 32bits for the serial number.
Signed-off-by: NMatthias Schwarzott <zzam@gentoo.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Unfortunately, on devices that have multiple interfaces, udev->dev
points to the parent device (usb) instead of the cx231xx specific one.

Due to that the logs don't look too nice, as they'll print messages
as if they were produced by USB core:
  usb-1-2: New device Conexant Corporation Polaris AV Capturb @ 480 Mbps (1554:5010) with 7 interfaces

Instead of using the name of the parent device, let's use the name
of the first cx231xx interface for all cx231xx sub-modules.

With this path, the logs will be nicer:

  cx231xx 1-2:1.1: New device Conexant Corporation Polaris AV Capturb @ 480 Mbps (1554:5010) with 7 interfaces
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Don't need to show when it starts or stops. Just print lines
when devices are found.

After the changes, the output for i2c scan will be like:

	usb 1-2: i2c scan: found device @ port 0 addr 0x40  [???]
	usb 1-2: i2c scan: found device @ port 0 addr 0x60  [colibri]
	usb 1-2: i2c scan: found device @ port 0 addr 0x88  [hammerhead]
	usb 1-2: i2c scan: found device @ port 0 addr 0x98  [???]
	usb 1-2: i2c scan: found device @ port 3 addr 0xa0  [eeprom]
	usb 1-2: i2c scan: found device @ port 2 addr 0x60  [colibri]
	usb 1-2: i2c scan: found device @ port 2 addr 0xc0  [tuner]
	usb 1-2: i2c scan: found device @ port 4 addr 0x20  [demod]
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The I2C mux changes are significant. Bump version number.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Now that we're using dev_foo, the logs become like:

	usb 1-2: DVB: registering adapter 0 frontend 0 (Fujitsu mb86A20s)...
	usb 1-2: Successfully loaded cx231xx-dvb
	cx231xx: Cx231xx dvb Extension initialized

It is not clear, by the logs, that usb 1-2 name is an alias for
cx231xx. So, we also need to use dvb_info() at extension load/unload.

After the patch, it will print:
	usb 1-2: Cx231xx dvb Extension initialized

With is coherent with the other logs.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

I2C address 0x10 is the demod. While here, make the array const.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

There are several places at cx231xx that uses printk without
any special reason. Change all of them to use dev_foo().
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

There's just one debug level on cx231xx-audio. So, converting it
to dev_dbg() is easy.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Replace all pr_foo occurrences by dev_foo, as this is
the recommended way for drivers.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Otherwise, it would produce lots of useless messages like:
	cx231xx: cx231xx_send_usb_command: failed with status --32

After this patch, I2C scan will produce an useful report:

[ 9494.050807] cx231xx: i2c_scan: checking for I2C devices on port=0 ..
[ 9494.074928] cx231xx: i2c scan: Completed Checking for I2C devices on port=0.
[ 9494.074936] cx231xx: i2c_scan: checking for I2C devices on port=3 ..
[ 9494.098934] cx231xx: i2c scan: Completed Checking for I2C devices on port=3.
[ 9494.098942] cx231xx: i2c_scan: checking for I2C devices on port=2 ..
[ 9494.118440] cx231xx: i2c scan: Completed Checking for I2C devices on port=2.
[ 9494.118448] cx231xx: i2c_scan: checking for I2C devices on port=4 ..
[ 9494.141889] cx231xx: i2c scan: Completed Checking for I2C devices on port=4.

[ 9494.060182] cx231xx: i2c scan: found device @ 0x40  [???]
[ 9494.062953] cx231xx: i2c scan: found device @ 0x60  [colibri]
[ 9494.066071] cx231xx: i2c scan: found device @ 0x88  [hammerhead]
[ 9494.067383] cx231xx: i2c scan: found device @ 0x98  [???]
[ 9494.090113] cx231xx: i2c scan: found device @ 0xa0  [eeprom]
[ 9494.106463] cx231xx: i2c scan: found device @ 0x60  [colibri]
[ 9494.113762] cx231xx: i2c scan: found device @ 0xc0  [tuner]
[ 9494.121882] cx231xx: i2c scan: found device @ 0x20  [???]
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Now cx231xx_i2c_check_for_device works like i2c_check_for_device of em28xx driver.

For me this fixes scanning of all ports but port 2.
Signed-off-by: NMatthias Schwarzott <zzam@gentoo.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

CodingStyle fix: vars should be in lowercase.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

There's no reason to report:
	cx25840 7-0044:  Firmware download size changed to 16 bytes max length

If the driver needs to adjust the buffer's maximum size.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

There are lots of debug printks printed with pr_info. Also, the
printk's data are not too coherent:

- there are duplicated driver name at the print format;
- function name format string differs from function to function;
- long strings broken into multiple lines;
- some printks just produce ugly reports, being almost useless
  as-is.

Do a cleanup on that.

Still, there are much to be done in order to do a better printk
job on this driver, but, at least it will now be a way less
verbose, if debug printks are disabled, and some logs might
actually be useful.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

One of the identation blocks is wrong. Fix it.

While here, replace pr_info by pr_debug inside such block and
add the function name to the print messages, as otherwise they
will not help much.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

It currently does just like what pr_foo() macros do. So,
replace them.

A deeper cleanup is needed, as there are lots of debug macros
printed with pr_info.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

X-Patchwork-Delegate: m.chehab@samsung.com
on avr32 arch, those warnings happen:
	drivers/media/firewire/firedtv-fw.c: In function 'node_update':
	drivers/media/firewire/firedtv-fw.c:329: warning: comparison is always true due to limited range of data type

In this particular case, the signal is desired, as the isochannel
var can be initalized with -1 inside the driver.

So, change the type to s8, to avoid issues on archs where char
is unsigned.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Reviewed-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Similar to an earlier patch, fixing reading user-space data for the
VIDIOC_CREATE_BUFS ioctl() in 32-bit compatibility mode, this patch fixes
writing back of the possibly modified struct to the user. However, unlike
the former bug, this one is much less harmful, because it only results in
the kernel failing to write the .type field back to the user, but in fact
this is likely unneeded, because the kernel will hardly want to change
that field. Therefore this bug is more of a theoretical nature.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>