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

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

There is no difference towards AF9035 remote controller, so enable it.
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>

eeprom memory mapped base address is detected at the very first.
Use it everywhere.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

AF9035 and IT9135 supports two different firmware format. Select
correct loader according to first byte of firmware file.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We don't need it. Tuner ID and device address are enough.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Now it supports IT9135 based dual tuner devices.
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>

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>

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

That same USB ID is used both AF9015 and AF9035 driver.
iManufacturer is only thing we can select correct driver without a I/O.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

That same USB ID is used both AF9015 and AF9035 driver.
iManufacturer is only thing we can select correct driver without a I/O.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

ADC needs to be also multiplied to 2 as it9135.
Fixes bug I introduced few commits ago.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Detect automatically multiple chip versions and select configuration
according to that.
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>

Remove the remaining CamelCase checkpatch.pl compliants.
There are still a few left, but those are due to USB and
DVB APIs.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It is almost impossible to see a compliant with checkpatch.pl
on those Siano drivers, as there are simply too much violations
on it. So, now that a big change was done, the better is to
cleanup the checkpatch compliants.

Let's first replace all CammelCase symbols found at smscoreapi.h
using camel_case namespace. That removed 144 checkpatch.pl
compliants on this file. Of course, the other files need to be
fixed accordingly.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The logic that detects the types of sms devices is bogus. It returns
	[ 4645.187790] smsusb_init_device: line: 372: Unspecified sms device type!
For several devices, including the one I have (SMS_RIO). In a matter
of fact, the right thing to do there is to print an error only if
the device is really unknown (SMS_UNKNOWN_TYPE).
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

To avoid mixing two different things at the same place, move the
debugfs code into a separate file.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently, every time a message is sent or received, the endiannes
need to be fixed on big endian machines. This is currently done
on every call to the send API, and on every msg reception logic.
Instead of doing that, move it to the send/receive functions.
That simplifies the logic and avoids the risk of forgetting to
fix it somewhere.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch is based on Doron Cohen's patches:
	http://patchwork.linuxtv.org/patch/7881/
	http://patchwork.linuxtv.org/patch/7888/
	http://patchwork.linuxtv.org/patch/7883/
It basically merges the above patches, rebasing them to
the macro definitions used upstream, with are different
 than the ones used by them internally.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Instead of using hardcoded descriptors, detect them from the
USB descriptors.
This patch is rebased form Doron Cohen's patch:
	http://patchwork.linuxtv.org/patch/7883/Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Instead of printing a message for some random messages, print
it for all sent/received ones. That helps a lot to debug
what's going on.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Added support for the GOTVIEW SatelliteHD card which is based on
Montage M88DS3000 and works very well with this driver.
Signed-off-by: NAndrey Pavlenko <andrey.a.pavlenko@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

kfree on NULL pointer is a no-op.
Signed-off-by: NSyam Sidhardhan <s.syam@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is an hybrid board. However, for analog, it requires
a new driver for saa7136. So, for now, let's just add
support for Digital TV.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It turned out that some devices return less bytes then requested via i2c when
ALL of the following 3 conditions are met:
- i2c bus B is used
- there was no attempt to write to the specified slave address before
- no device present at the specified slave address
With the current code, this triggers an -EIO error and prints a message to the
system log.
Because it can happen very often during device probing, it is better to ignore
this error and bail out silently after the follwing i2c transaction success
check with -ENODEV.

[mchehab@redhat.com: a small CodingStyle fix]
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The em28xx driver obtains the timestamps using function v4l2_get_timestamp(),
which produces a montonic timestamp.
Fixes the warnings appearing in the system log since commit 6aa69f99
"[media] vb2: Add support for non monotonic timestamps"
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Register both buses 0 and 1 via I2C API. For now, bus 0 is used
only by eeprom on all known devices. Later patches will be needed
if this changes in the future.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Prepare to register a separate bus for the second bus.
For now, just add a new field. A latter patch will add the
bits to make it work.
This patch was generated by this script:
perl -e 'while (<>) { if (s/EM2874_I2C_SECONDARY_BUS_SELECT.*\n//) {
	printf "\t\t.def_i2c_bus  = 1,\n"; $found = 1; print $_ } else { if ($found) { s/^\s+// }; $found = 0; print $_; } }' \
drivers/media/usb/em28xx/em28xx-cards.c >a && mv a drivers/media/usb/em28xx/em28xx-cards.c
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Newer em28xx devices have 2 buses. Change the logic to allow
using both buses.
This patch was generated by this small script:
for i in drivers/media/usb/em28xx/*.c; do
	sed 's,->i2c_adap,->i2c_adap[dev->def_i2c_bus],g;s,->i2c_client,->i2c_client[dev->def_i2c_bus],'
done
Of course, em28xx.h needed manual edit.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Since commit 7543f344 ("[media] m920x:
factor out a m920x_write_seq() function") building m920x.o triggers this
GCC warning:
    drivers/media/usb/dvb-usb/m920x.c: In function ‘m920x_probe’:
    drivers/media/usb/dvb-usb/m920x.c:91:6: warning: ‘ret’ may be used uninitialized in this function [-Wuninitialized]
This warning is caused by m920x_write_seq(), which is apparently inlined
into m920x_probe(). It is clear why GCC thinks 'ret' may be used
uninitialized. But in practice the first seq->address will always be
non-zero when this function is called. That means we can change the
while()-do{} loop into a do{}-while() loop. And that suffices to make
GCC see that 'ret' will not be used uninitialized.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Thanks for the response, I have done as you suggested.
Below is an updated patch for the OTG102 device against http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cx231xx, kernel version 3.8.
With further testing it appears the extra clauses in cx231xx-cards.c were not necessary (in static in cx231xx_init_dev and static int cx231xx_usb_probe), so those have been also been removed.
Signed-off-by: NMatt Gomboc <gomboc0@gmail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

kfree on NULL pointer is a no-op.
Signed-off-by: NSyam Sidhardhan <s.syam@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

I did what I liked to do. Also corrected two long log writings
as checkpatch.pl was complaining about those.
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>

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

WARNING: at lib/dma-debug.c:947 check_for_stack+0xa7/0xf0()
ehci-pci 0000:00:04.1: DMA-API: device driver maps memory fromstack
Reported-by: Npoma <pomidorabelisima@gmail.com>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>