| Age | Commit message (Collapse) | Author |
|---|
|
cx23885_board structure
This is needed for multifrontend support.
NetUP Dual DVB-T/C CI RF card has frontends connected to port B & C
Each frontend has two switchable cores - DVB-T & DVB-C
Signed-off-by: Igor M. Liplianin <liplianin@netup.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
There is two external I2C buses in cx23885 chip.
Currently, analog tuners supported for second I2C bus only
In NetUP Dual DVB-T/C CI RF card tuners connected to first bus
So, in order to support analog tuners sitting on first bus
we need modifications.
Signed-off-by: Igor M. Liplianin <liplianin@netup.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
The card based on cx23885 PCI-e brige. Altera FPGA for CI,
multistandard demods stv0367 from STM for QAM & OFDM, Xcieve xc5000 tuners
and additional cx25840 for second analog input.
Signed-off-by: Igor M. Liplianin <liplianin@netup.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
An Altera FPGA CI module for NetUP Dual DVB-T/C RF CI card.
Signed-off-by: Igor M. Liplianin <liplianin@netup.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
This patch fixes the warning "Using plain integer as NULL pointer",
generated by sparse, by replacing the offending 0s with NULL.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Reviewed-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
This soc_camera driver is for Omnivision's OV9740 sensor. This initial
submission provides support for YUV422 output at 1280x720 (720p), which is
the sensor's native resolution. 640x480 (VGA) is also supported, with
cropping and scaling performed by the sensor's ISP.
This driver is heavily based off of the existing OV9640 driver.
Signed-off-by: Andrew Chew <achew@nvidia.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Use the correct scales to calculate cropping offsets.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Now that soc-camera supports videobuf API v1 and v2, camera-host drivers
can be converted to videobuf2 individually. This patch converts the
mx3_camera driver.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Convert the sh_mobile_ceu_camera driver to the videobuf2 API.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Extend soc-camera core to also support the videobuf2 API.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
videobuf2-memops and videobuf2-core can be compiled as modules, in which
case 3 more symbols from videobuf2-memops.c have to be exported.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
If the camera was set to output formats like RGB565 YUYV or SBGGR10,
the resulting image was scrambled due to erroneous interpretations of
horizontal parameter's units.
This patch in fourcc_to_ipu_pix, eliminate also the pixel formats mappings
that, first are not used within mainline code and second, standing at
the datasheets, they will not work properly:
The IPU internal bus support only the following data formatting
(44.1.1.3 Data Flows and Formats):
1 YUV 4:4:4 or RGB-8 bits per color component
2 YUV 4:4:4 or RGB-10 bits per color component
3 Generic data (from sensor to the system memory only)
And format conversions are done:
- from memory: unpacking from other formats to IPU supported ones
- to memory: packing in the inverse order.
So, assigning a packing/unpacking strategy to the IPU for those formats
will produce a packing to memory and not the inverse.
Signed-off-by: Alberto Panizzo <maramaopercheseimorto@gmail.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
The 'pix->width' field may be updated in mx3_camera_set_fmt() to
fulfill the IPU stride line alignment requirements. If this update
takes place, the 'fmt.pix.sizeimage' field in the struct v4l2_format
stucture returned by VIDIOC_S_FMT is wrong. We need to update the
'pix->sizeimage' field in the mx3_camera_set_fmt() function to fix
this issue.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Even though clk_put() is a no-op on most architectures it is not for
some ARM implementations. To not fail on those, release the clock timer
before freeing the surrounding structure.
This bug was spotted by the semantic patch tool coccinelle using the
script found at scripts/coccinelle/free/kfree.cocci.
More information about semantic patching is available at
http://coccinelle.lip6.fr/
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
pixel
Add a function to calculate the number of samples on the media-bus,
required to retrieve one pixel of a certain format.
Signed-off-by: Alberto Panizzo <maramaopercheseimorto@gmail.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Some camera systems have strong requirement for capturing
an exact number of frames after starting the stream and do
not tolerate losing captured frames. By starting the stream
after the videobuf has queued the buffers, we ensure that
no frame will be lost.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
add vidioc_enum_framesizes implementation, follow default_g_parm()
and g_mbus_fmt() method
Signed-off-by: Qing Xu <qingx@marvell.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Reported by, and based on a patch from, Martin Dauskardt.
The AUDIO_AC3_BITRATE control is still missing from this list, but such
optional controls are a bit hard to handle. This will be fixed automatically
when we switch to the control framework.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Reported-by: Martin Dauskardt <martin.dauskardt@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Some ioctl's were defined wrong on 2.6.2 and 2.6.6, using the wrong
type of R/W arguments. They were fixed, but the old ioctl names are
still there, maintained to avoid breaking binary compatibility:
There's no sense on preserving those forever, as it is very doubtful
that someone would try to use a such old binary with a modern kernel.
Removing them will allow us to remove some magic done at the V4L ioctl
handler.
Note that any application compiled with a videodev2.h from 2.6.7 or later
will be using the correct ioctls.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Having a framerate divisor of 3 is not really necesarry and leads to
various troubles (frames going missing, compression issues) when allowed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
This is a complete rewrite of the old v4l1 vicam subdriver, featuring
multiple resolutions, gain + exposure control and still has less code.
Oh and it is a v4l2 driver rather then v4l1 ofcourse :)
Many thanks to Devin Heitmueller <dheitmueller@kernellabs.com> for
donating his 3com homeconnect to me, which made this rewrite possible.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
In good lighting conditions (lots of details visible) the current buffers
are sometimes too small.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
This fixes the led not working on this camera
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Tested with a camera with usb-id: 0c45:62bb
Also enable dmi based flopped laptop detection for the 0c45:627b ov7660 model.
Some of the MSI laptops with upside down camera have this one instead of the
0c45:624f.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Tested with a camera with usb-id: 0c45:62bb
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
This avoids to define the webcam model.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
The gain/expo adjustment was too long.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
During image capture, the filling rate of the isoc packets is computed.
It is then used by a work queue to update the current JPEG quality.
Tested-by: Franck Bourdonnec <fbourdonnec@chez.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
A marker 'ff ff 00 c4 c4 96' indicates an end of frame.
It is 62 bytes long and may be splitted on 2 packets.
It contains a flag 'USB full' which indicates that the frame is truncated.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
v4l2-ctl and qv4l2 enumerate controls using V4L2_CTRL_FLAG_NEXT_CTRL,
falling back to the old method if the flag isn't supported.
The v4l2_subdev_queryctrl function will currently handle that flag, but
for the controls of the subdev only. This isn't right, it should refuse
this flag, otherwise v4l2-ctl will only see the controls of the first
subdev.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Subdev controls return codes are evil, as they return -EINVAL to mean
both unsupported and invalid arguments. Due to that, we need to use a
trick to identify what controls are supported by a subdev.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
On some cases, driver returns 1. This should be OK, but qv4l2 is too
strict about return values.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Having the device detection happening at reset is bad, as every time,
it will produce a message like:
tvp5150 2-005c: tvp5150am1 detected.
This only polutes the log and for an accidental kernel hacker, it looks
like a real problem. So, move those printk's to happen during device
probe.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
It makes no sense that tuner_lookup would touch at the standby
state. Remove it.
Thanks-to: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Group a few functions together and add/fix comments for each
block of the driver.
This is just a cleanup patch meant to improve driver readability.
No functional changes in this patch.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
This driver is complex, and used by everyone. Better to have it
properly documented.
No functional changes are done in this patch.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
