When adding support for both video and VBI, I missed the mmap ioctl.  Add
the missing call.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add support for raw VBI capture for the em28xx bridge, currently only for
NTSC.  Support for PAL capture to follow shortly (including the removal of
numerous hard-coded NTSC-specific sizes for capture buffers, etc).

Note that the code currently changes the default current norm from PAL to
NTSC (so that zvbi-ntsc-cc works properly).  The default norm really should
be moved into a board-level parameter.

This work was sponsored by EyeMagnet Limited.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add code enabling the VBI registers for variants of the em28xx chip that
support VBI, and make sure the isoc streaming code continues to work for
the video component of the stream (note the video and vbi data arrive
intermixed on the same isoc pipe).

Note that this version just drops the actual VBI data onto the floor as
opposed to processing it.  The "#ifdef 0" tags are for the videobuf code that
appears in the next patch in this series.

We created a separate version of the isoc_copy version for parsing the version
of the stream that includes VBI data.  In theory, they might be able to be
merged at some point in the future, but the initial goal is to ensure that we
do not cause any regressions with devices that do not have VBI support.

This work was sponsored by EyeMagnet Limited.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

V4L2 API (chapter 1.5) states that:

	Drivers must implement all input ioctls when the device has one
	or more inputs, all output ioctls when the device has one or more outputs.
	When the device has any audio inputs or outputs the driver must set the
	V4L2_CAP_AUDIO flag in the struct v4l2_capability returned by the
	VIDIOC_QUERYCAP ioctl.

So, devices without audio input should return -EINVAL.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Even devices without ac97 needs to call analog audio setup function, to
properly set xclk and mute/unmute.

Thanks to Angelo Cano <acano@fastmail.fm> for reporting and testing it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In the past, some devices with saa711x had their parameters controlled
directly inside em28xx driver, instead of using their proper module for
it.

Due to that, the ac97 controls were mixed with saa711x ones.

Older patches removed all saa711x controls, but we still need to control
ac97 devices on em28xx, since we don't have a separate v4l2 device for
it.

The proper way to address is to create a separate ac97 v4l2 device.
While we don't have it, we should clean up the code to allow having a
better view of what is part of em28xx core code and what's due to ac97
control inside it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

As em28xx chip has nothing to do with volume/mute controls, rename those
controls to properly indicate that they control the companion AC97 chip
that it is inside the boards with this chip.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Due to historical reasons, em28xx driver gets two consecutive frames and
fold them into an unique framing, doing interlacing. While this works
fine for TV images, this produces two bad effects with webcams:

1) webcam images are progressive. Merging two consecutive images produce
interlacing artifacts on the image;

2) since the driver needs to get two frames, it reduces the maximum
frame rate by two.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

em28xx doesn't have temporal scaling. However, on webcams, sensors are
capable of changing the output rate. So, VIDIOC_[G|S]_PARM ioctls should
be passed to the sensor for it to properly set frame rate.
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>

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>

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>

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>

The v4l function has a better algorithm for aligning image size.

It appears that the em2800 can only scale by 50% or 100%, i.e. the only
heights supported might be 240 and 480.  In that case the old code would
set any height other than 240 to 480.  Request 240 get 240, but request 239
and then you get 480.  Change it to round to the nearest supported value.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
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>

s_standby is only used to put the tuner in powersaving mode, so move it
from core to tuner.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Converted em28xx driver to v4l2_subdev.
Thanks to Hans Verkuil <hverkuil@xs4all.nl> for helping this conversion.
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Compro VideoMate uses an external audio DSP chip, controlled via tvaudio
module (tda9874a). This patch improves em28xx infrastructure to support
an external audio processor and fixes the Compro VideoMate entry to work
with it.
Signed-off-by: NVitaly Wool <vital@embeddedalley.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Lots of coding style fixes and a typo correction for em28xx.

[dougsland@redhat.com: fixed a reject due to a change on em28xx-audio.c]
Signed-off-by: NNicola Soranzo <nsoranzo@tiscali.it>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

usb_make_path reports canonical bus info. Use it when reporting bus info
in VIDIOC_QUERYCAP.
Signed-off-by: NThierry MERLE <thierry.merle@free.fr>
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>

Fix for KWorld 330U Board

Many thanks to Devin and Mauro!!!
Signed-off-by: NRobert Krakora <rob.krakora@messagenetsystems.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

em28xx were trying to access the third input entry, even for boards that
don't support it.

This patch reviews the input mux selection fixing this bug and a few
other troubles, like not validating the input on one userspace ioctl.
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>

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>

Add additional output formats, which will be useful for the Pinnacle PCTV
Ultimate 880e integration with the saa7136.

Thanks to Ray Lu from Empia for providing the em2860/em2880 datasheet.
Signed-off-by: NDevin Heitmueller <dheitmueller@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Now, just two routines are enough for analog: the first one configs the analog
part and register V4L2 devices, and the second one release analog devices.

After this patch, it will be easier to transform em28xx-video into an em28xx
extension, loaded only on analog devices.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

em28xx-video were holding several code that are not specific to V4L2
interface.

This patch moves the core code for em28xx-core, and usb probing code
into em28xx-cards.

This opens the possibility of breaking em28xx into a core module and a
V4L2 module, loaded only on devices that have analog interfaces.

Some cleanup may be done at em28xx-cards to optimize the config code.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

The em28xx driver can be coupled to an anciliary AC97 chip. This patch
allows read/write AC97 registers directly.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

vidioc_g_ctrl() were using an uneeded confusing logic. Instead, use the
direct approach.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

This patch uses the same code for enumberating video formats that are
present on cx88, bttv and saa7134 drivers.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The changeset 78aa52a159cf introduced a bug on em28xx: buffer setup should be
awaking xc3028. Instead, since we didn't specify the tuner mode, the device
were going to sleep, due to the lack of tuner mode when asking tuner to handle
VIDIOC_S_FREQUENCY:

xc2028 0-0061: Device is Xceive 3028 version 1.0, firmware version 2.7
xc2028 0-0061: divisor= 00 00 14 d0 (freq=83.250)
xc2028 0-0061: Putting xc2028/3028 into poweroff mode.
xc2028 0-0061: Printing sleep stack trace:
Pid: 10936, comm: mplayer Tainted: P   M      2.6.27.8 #1

Call Trace:
 [<ffffffffa0b759ea>] xc2028_sleep+0x89/0x1ab [tuner_xc2028]
 [<ffffffffa0b48fb9>] tuner_s_frequency+0xf5/0x165 [tuner]
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Changes/fixes on em28xx dev->lock:

- em28xx_init_dev() were unlocking without a previous lock;

- some read ioctls need to lock after the removal of KBL, since a write
  may be happening at the same time an ioctl is reading;

- keep the device locked during all device initialization;

- lock/unlock while reading/writing registers.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

vidioc_try_fmt_vid_cap() just checks if a given resolution is supported.
It doesn't touch on struct em28xx device descriptor. so, there's no need
to lock.

While there, use unlikely() for those values that aren't likely to
occur.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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