This patch fixes a regression that crept into 2.6.36.

The volume control scale in the cx25840 driver has an unusual mapping
from register values to v4l2 volume control values.  Enforce the mapping
limits, so that the default volume control setting does not fall out of
bounds to prevent the cx25840 module device probe from failing.
Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

drivers/media/video/cx25840/cx25840-core.c: In function ‘cx25840_s_frequency’:
drivers/media/video/cx25840/cx25840-core.c:1563: warning: unused variable ‘state’
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This adds support for the AUX_PLL in cx2583x chips which is available in
those although the audio part of the chip is not.
The AUX_PLL is used at least by Terratec in their Grabster AV400 device.
Signed-off-by: NSven Barth <pascaldragon@googlemail.com>
Acked-by: NMike Isely <isely@pobox.com>
Reviewed-by: NAndy Walls <awalls@md.metrocast.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The wrong value for the volume control limit, 65335 vs. 65535,
prevents proper cx25840 v4l2_subdevice initialization.
Reported-by: NIgor M. liplianin <liplianin@me.by>
Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The cx25840 used a private control CX25840_CID_ENABLE_PVR150_WORKAROUND
to be told whether to enable a workaround for certain pvr150 cards.

This is really config data that it needs to get at load time.

Implemented this in cx25840 and ivtv.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch is primarily a port of the integrated IR controller code in
cx23885/cx23888-ir.c.  Right now, only the CX2388[57] AV core will
really try to set up IR. This IR support, by design, still requires the
bridge driver to do final IO pin mux configuration and setup of the IR
controller parameters.

For the CX2388[578] chips, enabling the AV Core for IR also starts
sending Audio and Video interrupts to the bridge driver.  For
CX2388[578] chips audio and video interrupts are ignored and
acknowledged when they happen.

IR interrupt handling and status logging is exluded for the CX23888
which does not have an IR controller on the AV core.

Note that experimentation reveals that the IR irq enables on the
CX23885 have an inverted logic sense.  The CX23887 likely suffers from
the same quirk.  For these chips, those irq enable bits are handled
as interrupt disables.
Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add s_io_pin_config core subdev op for the CX2388[578] AV cores.
This is complete for IR_RX, IR_TX, GPIOs 16,19-23, and IRQ_N.
It likely needs work for the I2S signal direction.
Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There was a small window between writing the cx25840 register
address over the i2c bus and reading the register contents back from the
cx25840 device that the i2c adapter lock was released.  This change ensures the
adapter lock is not released until the register read is done.
Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Now that s_fmt is no longer used for VBI format setup in subdevs, remove
the VBI support from s_fmt.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Also removed the bogus zeroing of fmt.sliced when setting up raw VBI.

Switching between raw and sliced VBI changed in 2.6.28 and this memset
should have been removed at that time. It was never noticed because
the bridge driver will fill in the fmt.vbi values anyway.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Only a relatively small number of video receivers and transmitters actually
support VBI. So start moving the vbi specific ops to an ops struct of their
own.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If CX25840_VIN1_CH1 and the like is used, input is not detected as composite.
Their value is 0x800000XX and CX25840_COMPONENT_ON is 0x80000200. So

   739			else if ((vid_input & CX25840_COMPONENT_ON) == 0)

this condition never be true.
Signed-off-by: NKusanagi Kouichi <slash@ac.auone-net.jp>
Reviewed-by: NAndy Walls <awalls@radix.net>
Acked-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This change attempts to fix the ivtv tinny audio problem by keeping digitizer
to encoder audio clocks running, while disabling the video clocks as needed to
avoid unpredictable PCI bus hangs.

To accomplish this, for the cx25840 module enabling of audio streaming had
to be separated from enabling video streaming, requiring an additional
v4l2_subdev_audio_op and calls to this new op in the pvrusb2 and ivtv drivers.

The cx231xx and cx23885 driver use the cx25840 module for affecting only
video on s_stream calls, so those drivers needed no change.

The CX23418 hardware does not exhibit either the tinny audio problem nor the PCI
bus hang, so the cx18 driver did not need corresponding changes.

CX2341[56] based cards that are not using the CX2584x family of chips
do not seem to be affected by the tinny audio problem, and this change should
not affect how they are configured. It will delay their first capture by
starting by another 300 msec though.

Many thanks go to Argus <pthorn-ivtvd@styx2002.no-ip.org> and
Martin Dauskardt <martin.dauskardt@gmx.de> whose persistent testing and
investigation of this problem will hopefully fix this problem once and for all
for many ivtv users.
Reported-by: NMartin Dauskardt <martin.dauskardt@gmx.de>
Reported-by: NArgus <pthorn-ivtvd@styx2002.no-ip.org>
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

cx25840:
Disable 6.5MHz carrier autodetection for PAL, always assume its DK.
Only try to autodetect 6.5MHz carrier for SECAM if user accepts both
system DK and L.
Signed-off-by: NAleksandr V. Piskunov <alexandr.v.piskunov@gmail.com>
Reviewed-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NDavid T.L. Wong <davidtlwong@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The prior mechanism wasn't reliable with the cx23887. This new mechanism
tests correctly against cx23885, 7 and 8 based products.
Signed-off-by: NSteven Toth <stoth@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The SYS and AUX PLLs need to be initialized to different values based on
the chip: CX23885, CX23887, CX23888, as each uses a different crystal
frequency: 28.6363 MHz, 25.0 MHz, 50.0 MHz.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Change logic to check for various chip or core families to inline functions.
Checks for specific chips should be made against the state->id field now.  This
is in preparation for chip/core specific code for setting up PLLs for the
CX2388[578] family of cores, that all run with different crystal frequencies.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add improved logic to detect the exact CX2388[578] A/V core that is being
probed.  Also cleaned up detection and logging for CX2310[12], CX2583[67],
and CX2584[0123] cores and chips.

Also added code to identify a CX2388[578] A/V decoder core that is not
responding properly.  Typical symptoms include registers 0x00-0xff
responding properly but all other registers returning the same value
(0x13 and 0x5 have been observed).  This state will cause proper detection of
'885 vs. '887 vs. '888 to fail and the chip won't respond to get configured
properly anyway.  I have no method of reseting the core to a working state at
this time; but I didn't try too hard to work one out either.  The problem
likely only occurs in development.  I suspect configuring the SYS PLL VCO to
oscillate too slowly (286.3 MHz?) before post divide may be the root cause,
when encountered.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

After the i2c subdev changes the ordering of initialization changed,
causing a total loss of previous GPIO settings and a loss of DTV.
The generic firmware loading routine has now changed to preserve
GPIO values if the device is cx23885 based (safety) and I've
moved the GPIO configuration from probe() into the cx23885 init
func which is a little clearer and fixes the bug.
Tested-by: NSohail Syyed <linuxtv@hubstar.net>
Reviewed-by: NMichael Krufky <mkrufky@kernellabs.com>
Signed-off-by: NSteven Toth <stoth@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It is no longer needed to use a struct pointer as argument, since v4l2_subdev
doesn't require that ioctl-like approach anymore. Instead just pass the input,
output and config (new!) arguments directly.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

s_std didn't belong in the tuner ops. Stricly speaking it should be part of
the video ops, but it is used by audio and tuner devices as well, so it is
more efficient to make it part of the core ops.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The init callback was used in several places to load firmware. Make a separate
load_fw callback for that. This makes the code a lot more understandable.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

An earlier commit accidentally broke the detection of the cx25837 part of
the cx23885. Reinstated the commented out code.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

cx231xx has a cx25840 inside the chip. However, some different
initializations are used for this variant.
Signed-off-by: NSrinivasa Deevi <srinivasa.deevi@conexant.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The audio and vbi functions where still called through an ioctl-like
interface, even though this is no longer needed with v4l2-subdev. Just
change each 'case' into a proper function and call that directly.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

All drivers that use cx25840 are now converted to v4l2_subdev, so I can remove
the support for the old-style i2c API.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The v4l2_ctrl_query_fill_std() function wasn't one the best idea I ever had.
It doesn't add anything valuable that cannot be expressed equally well with
v4l2_ctrl_query_fill and only adds overhead.

Replace it with v4l2_ctrl_query_fill() everywhere it is used and remove it
from v4l2_common.c.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A hue of -128 was rejected due to an incorrect range check, which was
faithfully copy-and-pasted into four drivers...
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

These days TUNER_SET_CONFIG is broadcast to the other i2c devices
and that triggers a fw load on the cx25840. Ignore this command
since cx25840 isn't a tuner and you really do not want to load
the firmware that early.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

With the conversion to v4l2_subdev one bit of code was accidentally dropped:
on receiving the first command the driver has to load the fw. A new init()
command was introduced to do that explicitly for bridge drivers that are
converted to use v4l2_subdev, but old drivers that are not yet converted
no longer worked.

This patch fixes this regression for these old drivers.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Since the i2c driver ID will be removed in the near future we have to
modify the v4l2 debugging API to use the driver name instead of driver ID.

Note that this API is not used in applications other than v4l2-dbg.cpp
as it is for debugging and testing only.

Should anyone use the old VIDIOC_G_CHIP_IDENT, then this will be logged
with a warning that it is deprecated and will be removed in 2.6.30.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>