The cx23418 appears to send Raw VBI buffers with a PTS on a per frame
basis, not per field, so process Raw VBI on a whole frame basis and reduce
some complexity.  Fix VBI buffer size computation to handle a whole
frame of Raw VBI for a 625 line system, which is the worst case and will
work for 525 lines systems as well.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fixed an endianess problem with the collection of the PTS from
the VBI buffer given to us by the encoder.  Also extrapolated the
last 12 bytes of the last line of each field, to remove artifacts
created by removing the first 12 bytes of each field for raw VBI.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The driver was incorrectly setting 0 line counts in a firmware
API call to set the maximum amount of lines per field.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The Encoder will only allow the Raw VBI parameters, along with a number of
other API parameters, to take effect when no analog captures are in
progress.  These parameters must be set before the first analog capture starts,
be it MPEG, VBI, YUV, etc., and cannot be changed until the last one stops.  It
is not obvious to me what capture channel API parameters are shared and which
ones must be set per capture channel, so set them all for every analog
capture channel start up.  This fixes the driver so that VBI capture can be
started up after the MPEG capture is going.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

More sliced VBI fixes to bring the cx18 driver closer to full V4L2 spec
compliance for VBI and to get sliced VBI working better.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The old code from ivtv used a CX23415/6 PTS, which was simply left at 0 in the
cx18 driver.  Since the CX23418 gives us what I think is a PTS (or some other
90 kHz clock count) with each VBI buffer, this change has the cx18 driver use
that as a PTS.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Removed legacy ivtv state variables, added comments, and cleaned
up sliced VBI related code.  Enabled sliced VBI.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The CX18_AUDIO_ENABLE register usually never reads back what was just written
under normal circumstances.  Perform better checking that a write went to the
register as expected with a specification of what bits to verify.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAndy Walls <awalls@radix.net>
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>

Card report provided by Patryk on the ivtv-devel list:
http://ivtvdriver.org/pipermail/ivtv-devel/2009-January/005922.htmlReported-by: NPat <tatyrza@mm.pl>
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

request_module() needs to be called with a string literal for a
format string or with 1 or more variable arguments to avoid
compiler warnings and possible exploits, if someone could cause
us to get a format string with a '%' code in the format string
when we make the call.
Reported-by: NBrandon Jenkins <bcjenkins@tvwhere.com>
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

First step in conversion to the new V4L2 framework.  Added per cx18 device
instance of the v4l2_device and its registration.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Renamed structure member name to be more specific to type in anticipation
of updating to the v4l2_device/v4l2_subdev framework.  Too many objects named
"dev" and /v4l2_\{0,1\}dev/ would be to confusing.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Make sure v4l2-ctl --log-status outputs the driver version.
Reported-by: NDavid Dombroski <davedom@optonline.net>
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Normalize the APU state before the second firmware load so that audio
for the first analog capture is correct.

Many thanks to Conexant for supporting me in finding a solution for this
problem.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix bugs in the cx18 AC3 control implementation that would have affected
ivtv and other drivers via the cx2341x module.  Bring AC3 controls
behavior into comliance with V4L2 specification.  Thanks to Hans Verkuil
for reviewing the previous patch and pointing out the problems.
Reported-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Initial addition of controls to set AC-3 audio encoding for the CX23418 - it
does not work yet due to firmware or cx18 driver issues.  This change affects
the common cx2341x and ivtv modules due to shared structures and
common functions.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Added debug display of outgoing mailbox arguments.  Fixed a minor problem
with display of stale incoming mailbox contents, when user was not looking for
debug warnings.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A redundant PLL divisior update for the I2S master clock after AV core
firmware load was missed in earlier PLL parameter changes.  This one really
doesn't matter because it's redundant and gets overwritten, but the driver
should be self consistent in the values used.
Signed-off-by: NAndy Walls <awalls@radix.net>
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>

Since internal to v4l2 the ioctl prototype is the same regardless of it
being called through .ioctl or .unlocked_ioctl, we need to convert it all
to the long return type of unlocked_ioctl.

Thanks to Jean-Francois Moine for posting an initial patch for this and
thus bringing it to our attention.

Cc: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Introduce a struct v4l2_file_operations for v4l2 drivers.

Remove the unnecessary inode argument.

Move compat32 handling (and llseek) into the v4l2-dev core: this is now
handled in the v4l2 core and no longer in the drivers themselves.

Note that this changeset reverts an earlier patch that changed the return
type of__video_ioctl2 from int to long. This change will be reinstated
later in a much improved version.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Use a consistent crystal value of 28.636360 MHz for computing all PLL
parameters so clocks don't have relative error due to assumed crystal
value mismatches.  Also aimed to have all PLLs run their VOCs at close to
400 MHz to minimze the error of these PLLs as frequency synthesizers. Also
set the VDCLK and AIMCLK PLLs to sane values before the APU and CPU firmware
are loaded.  Also fixed I2S Master clock dividers.

Many thanks to Mike Bradley and Jeff Campbell for reporting this problem and
suggesting the solution, researching and experimenting, and performing
extensive testing to support their suggested solution.
Reported-by: NJeff Campbell <jac1dlists@gmail.com>
Reported-by: NMike Bradley <mike.bradley@incanetworks.com>
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Disable AV_LOCK, locking of audio PLL to video PLL in the cx18-av-core for
analog captures.  It seems to have adverse effects on captures from
SVideo and CVBS sources with current clock & crystal settings in the driver.

Many thanks to Jeff Campbell and Mike Bradley for reporting this problem,
and suggesting the solution and performing extensive testing to support their
suggestion.
Reported-by: NJeff Campbell <jac1dlists@gmail.com>
Reported-by: NMike Bradley <mike.bradley@incanetworks.com>
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Refine the firmware load and firmware startup process.  Significant changes
are to ensure the SCB and IPC area are correct before starting up the firmware,
and letting the CPU firmware start up the APU firmware for us.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

cx18: Use a known open task handle when setting stream CX2341x parameters
Sometimes, we might only have VBI or YUV stream open instead of an MPEG stream.
Let's make sure we use a valid task handle to perform the CX2341x control
settings.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

VBI comment corrections to avoid future confusion about standards.
Comments on cx18 VBI implementation shortcomings that need resolution.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Removed magic number that referred to firmware limit on the number of
MDLs the firmware can maintain for any stream at any one time.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A combined authorship patch from Hans Verkuil and Andy Walls.  Raw
VBI can now be captured but requires a video capture to be in progress as well.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is a port of the fixes Hans Verkuil made for ivtv/cx25840:
The service_set field was used to determine whether raw or sliced VBI was
desired. This is incorrect since it is perfectly valid to select sliced VBI
with a service_set of 0.

Instead the driver should check on VIDIOC_S_FMT whether the type
field matches the raw or sliced VBI type.

Updated the cx18 driver accordingly, including an additional check in
cx18_start_v4l2_encode_stream() that didn't exist in ivtv.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

cx18: Avoid making firmware API calls with the queue lock held.  The source
of MPEG strem corruption when not holding the queue lock was found to be that
the MPEG buffer could be retrieved by the user app before it was sync'ed for
the host cpu.  Incoming buffers are now sync'ed before being put on q_full and
releasing the queue lock.  We can thus avoid the sometimes lengthy call to
the firmware for CPU_DE_SET_MDL while holding the queue lock, so we can get
better performance.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

cx18: Increment version number due to siginificant buffering changes.
Now version 1.0.4
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

cx18: Add module parameters for finer control over buffer allocations.
User now has the option of setting smaller buffers to get lower
latency transfers from the encoder.  User can also now set the number
of buffers used for a stream explicitly.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

cx18: Allow more than 63 capture buffers in rotation per stream.  Implement
q_busy to hold buffers the firmware has for use.  q_free holds truly unused
buffers in a pool.  New buffers are given to the firmware as soon as the
firmware returns one, if there are any to give to the firmware.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Eliminate q_io from stream buffer handling in anticipation of upcoming
changes in buffer handling.  q_io was a holdover from ivtv and it's function
in cx18 was trivial and not necessary.  We just push things back onto the
front of q_full now, instead of maintaining a 1 buffer q_io queue.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>