A recent patch didn't take into account that frontends can be compiled into
the kernel.  Or that frontends compiled as modules can't be used by the
b2c2 driver if it is not a module itself.

Some frontends require multiple drivers, e.g. a demod driver and a tuner
driver.  The code for the frontend support was getting added if the demod
driver was available.  Change this to also require any needed tuner or SEC
drivers as well.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is not just pure cosmetic, since the order affects the out-of-tree
module build at the -hg development tree.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NBrian Johnson <brijohn@gmail.com>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NBrian Johnson <brijohn@gmail.com>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Request demodulator auto-detect transmission parameters in case of
garbage parameters provided by application for compatibility.
That's needed at least for MPlayer compatibility currently.

Thanks to Jelle de Jong for reporting issue and providing SSH access to
Devin for debugging.

Thanks to Devin Heitmueller for hard debug work he did to find that bug.

Cc: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Jelle de Jong <jelledejong@powercraft.nl>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The bug was introduced when adding the light frequency control
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When the change was introduced in the zl10353 for the i2c gate behavior, this
broke the HVR-900 which was not behind a gate.  Use a version of the zl10353
config profile that indicates the tuner is not behind such a gate.

Without this patch the first tune succeeds, but subsequent tuning attempts
will fail.

The change also renames the terratec zl10353 profile I wrote to be more
generic, since it is shared by the non-terratec device.

Thanks to Michael Krufky for providing a HVR-900 and DVB-T environment to test
with.

Cc: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The Pinnacle Hybrid Pro 320e was missing a demod config for the xc3028, which
is required for digital tuning to work properly.  Add the missing profile.

Thanks to Andreas Lunderhage for testing patches and providing a remote debug
environment.

Cc: Andreas Lunderhage <lunderhage@home.se>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In cases where the device has a generic Empia USB ID, the call in the
precard setup phase did not set the tuner GPIO.  As a result, the tuner may
not be taken out of reset before attempting initialization in the analog
driver.

This problem was not seen before with the EVGA inDtube, since that particular
board has the analog GPIO setup to include taking the tuner out of reset.

Thanks to Andreas Lunderhage for testing patches and providing a remote debug
environment for the Pinnacle 320e.

Cc: Andreas Lunderhage <lunderhage@home.se>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Set the GPIO properly for the analog side of the Pinnacle Hybrid Pro, or else
the emp202 doesn't get detected properly.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Setup the GPIOs properly and enable support for the DVB side of the Pinnacle
Hybrid Pro USB stick.

Thanks to Andreas Lunderhage for testing patches and providing a remote debug
environment.

Cc: Andreas Lunderhage <lunderhage@home.se>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Andy walls pointed out that we were passing 0x5d to the TUNER_GO register,
instead of 0x01.  Set the register properly (note the code did still work with
the incorrect value, so this does not address a regression).

Thanks to Andy Walls for noticing the issue.

Cc: Andy Walls <awalls@radix.net>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The Terratec Cinergy T XS USB can have either a zl10353 or an mt352.  Add
support for the MT352 variant.

Thanks to Jelle de Jong for providing a unit to test/debug with.

Cc: Jelle de Jong <jelledejong@powercraft.nl>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Thanks to Wally <wally@voosen.eu> for bringing the issue and helping
with the tests.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Depending on the video input format, vinmode/vinctl needs adjustments.
For TV, this is not relevant, since the supported decoders output data
at the same format. However, webcam sensors may have different formats,
so, this needs to be adjusted based on the device.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In order to properly estimate fps, mt9v011 sensor driver needs to know
what is the used frequency on the sensor cristal. Adds the proper fields
and initialization code for specifying the cristal frequency.

Also, based on experimentation, it was noticed that the Silvercrest is
outputing data at 7 fps. This means that it should be using a 6.3 MHz
cristal. This information needs to be double checked later, by opening
the device. Anyway, by using this value for xtal, at least now we have
the correct fps report.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Since frames per second is a function of cristal frequency, and this is
device-specific, add a function that allows adjusting it, via
subdev->core->s_config callback.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

vstart calculus were wrong. Fix it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It is possible to adjust the fps rate by changing some register values.
This is function of the connected Xtal at the camera sensor, being a 27
MHz cristal needed, in order to support 640x480 at 30 fps.

For now, it will only calculate the values for fps. Later patches may
introduce V4L2 ioctls, to allow frequency rate adjustments.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

While trying to fix an mt9v001 webcam, I noticed that HSCALE/VSCALE do
work with em28xx + webcam. The issue is that the scaling setup depends
on the number of visible rows/cols of the input image.

With mt9v011 (Silvercrest), the resolution is 640x480. So, the scaling
is different from a normal TV image (720x480 on NTSC). This were causing
a wrong scaling and a previous patch disabled scaling.

As each sensor have their different resolution setting, the xres/yres
should be adjusted accordingly with the input sensor.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

With the previous approach, autodetection were working only for the two
generic entries (em275x and em2820 unknown ones). So, if someone would
try to force probing an specific device, the code would not properly run
the autodetection code.

With the new approach, the sensor autodetection will be run not only for
the two generic entries, but also do webcam specific ones.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

Instead of using em28xx board decoder field for storing sensor information,
let's use instead a separate field for it.

Also, as sensors are currently autodetected, there's no need of having
it at the boards description. So, move it to the main em28xx struct.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Webcams in general don't have eeprom. So, the sensor hint code should be
called to properly detect what sensor is inside.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

By having the webcam devices marked as such, it will help the em28xx
driver to do the right thing on those devices.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Just renames the flag, to use a clearer name. Later patches will use
this flag to properly set some drivers behaviors for webcams.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A couple of erroneous register writes snuck in that made the image go haywire. Remove these.
Many thanks to Grégory Lardière for finding this out
Signed-off-by: NErik Andrén <erik.andren@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NErik Andrén <erik.andren@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

All hdcs registers use bit 0 as a read/write flag and needs to be shifted one bit to the left. This wasn't accounted for when doing a sequence of writes.
Signed-off-by: NErik Andrén <erik.andren@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NErik Andrén <erik.andren@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

* Remove smp_lock.h from files which don't need it (including some headers!)
* Add smp_lock.h to files which do need it
* Make smp_lock.h include conditional in hardirq.h
  It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPT

  This will make hardirq.h inclusion cheaper for every PREEMPT=n config
  (which includes allmodconfig/allyesconfig, BTW)
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There is one path with omitted unlock in si470x_fops_release. Fix that.

Cc: Tobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There is one omitted unlock in em28xx_usb_probe. Fix that.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

Discovered the bug that were limiting the output format to just RGB565.
Now, it is possible to output image at Bayer format (the original one,
as generated by Silvercrest sensor, and two others), and also on YUY.

Adds Bayer formats also to the driver.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Webcams have different constraints than other v4l devices. This patch
makes the format ioctls to behave better. It also fixes a bug at open()
handler, that were always reseting resolution to the maximum available
one.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix the code so that the zl10353 version of the Terratec Cinergy T XS USB
starts working again.  This includes fixing what must have been a typo in the
GPIO definition for the digital side of the board, and setting of the
disable_i2c_gate_ctrl property for the zl10353 config, so that the i2c bus
doesn't get wedged the first time something tries to close the gate.

Also, add a printk() making clear that the mt352 version still isn't
supported.  This issue is still being actively debugged, but in the meantime
at least the dmesg output will show a very clear error...

Thanks to Jelle de Jong for providing sample hardware to test with.

Thanks to Simon Kenyon for testing various patches and providing SSH access to
his environment so I could debug with access to a valid signal source.

Cc: Jelle de Jong <jelledejong@powercraft.nl>
Cc: Simon Kenyon <simon@koala.ie>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add suppport for the teste RGB565 format (16 bits/pixel).
Currently, webcam support works only at RGB565, at 640x480.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This webcam uses a em2710 chipset, that identifies itself as em2820,
plus a mt9v011 sensor, and a DY-301P lens.

It needs a few different initializations than a normal em28xx device.

Thanks to Hans de Goede <hdegoede@redhat.com> and Douglas Landgraf
<dougsland@redhat.com> for providing the acces for the webcam during
this weekend, I could make a patch for it while returning back from
FISL/Fudcom LATAM 2009.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>