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.
Alberto Panizzo [Mon, 17 Jan 2011 09:52:10 +0000 (06:52 -0300)]
[media] V4L: mx3_camera: fix capture issues for non 8-bit per pixel formats
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.
[media] V4L: mx3_camera: correct 'sizeimage' value reporting
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.
Mathias Krause [Sun, 30 Jan 2011 10:05:58 +0000 (07:05 -0300)]
[media] V4L: omap1_camera: fix use after free
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/
[media] V4L: soc-camera: start stream after queueing the buffers
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.
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>
drivers/ieee1394/ has been removed in Linux 2.6.37. The corresponding
backend code in firedtv is no longer built in now and can be deleted.
Firedtv continues to work with drivers/firewire/.
Also, fix a Kconfig menu comment: Removal of CONFIG_IEEE1394 made the
"Supported FireWire (IEEE 1394) Adapters" comment disappear; bring it back
with corrected dependency.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Reviewed-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sat, 5 Feb 2011 13:10:38 +0000 (10:10 -0300)]
[media] v4l: removal of old, obsolete ioctls
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>
Hans Verkuil [Sat, 5 Feb 2011 12:29:31 +0000 (09:29 -0300)]
[media] dabusb: remove obsolete driver
The dabusb driver was conceived as an experimental driver for a test
device. The driver never supported any shipped product, and, while
there were some updates for it in 2003, for an ancient product,
those changes were never submitted upstream.
Also, there's no DocBook for its API, nor any upstream discussion.
So it was decided to remove it in 2.6.39. Future support for a DAB API
should be discussed on the linux-media list first.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sat, 5 Feb 2011 12:25:02 +0000 (09:25 -0300)]
[media] se401: remove last V4L1 driver
This driver is for obsolete hardware that the old maintainer
didn't care (or not have the hardware anymore), and that no other developer
could find any hardware to buy.
The V4L1 API is no longer supported, and since nobody stepped in to convert
them to V4L2 the decision was made to remove them.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans de Goede [Tue, 22 Feb 2011 16:39:36 +0000 (13:39 -0300)]
[media] staging-usbvideo: remove
With the new gspca v4l2 vicam driver, there is no more reason to keep the
old v4l1 usbvideo vicam driver around, and since that is the last
usbvideo framework using driver, the old usbvideo framework itself can
go too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans de Goede [Wed, 16 Feb 2011 11:17:36 +0000 (08:17 -0300)]
[media] gspca_sn9c20x: Add hflip and vflip controls for the ov7660 sensor
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>
[media] gspca - sonixj: Better scanning of isochronous packets
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.
Hans Verkuil [Tue, 22 Feb 2011 15:31:07 +0000 (12:31 -0300)]
[media] v4l2-ctrls: Fix control enumeration for multiple subdevs with ctrl
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.
tuner-core has no business to do with digital TV. So, don't use
T_DIGITAL_TV on it, as it has no code to distinguish between
them, and nobody fills T_DIGITAL_TV right.
tda9887 used to use the T_STANDBY type internally, while tea5761
used it to put the device to sleep. Fix the code for it to work
properly with the tuner core changes and remove this flag from
tuner.h.
Remove the now obsolete set_freq. Also merge set_addr and set_type_addr.
In the past, it used to have two different setup calls, one to set just
the tuner type to any tuner found, and another to set the type only if
the address matches. Those two internal calls were grouped together,
but the functions weren't merged, making the code uglier.
[media] tuner-core: Don't use a static var for xc5000_cfg
A static var is evil, especially if a device has two boards with
xc5000. Instead, just like the other drivers, use stack to store
its config during setup.
[media] tuner-core: Some cleanups at check_mode/set_mode
Properly document those functions and do some cleanups around that.
There's just one behavior change on this patchset: it will now restore
TV frequency when changing from radio to TV mode.
[media] tuner-core: Reorganize the functions internally
This is a big patch with no functional changes. It just
rearranges everything inside the driver, and prepares to
break TV and Radio into two separate fops groups.
Currently, it has an heuristics logic to determine if the
call came from radio or video. However, the caller driver
knows for sure, so tuner-core shouldn't try to guess it.
[media] cx88: Don't allow opening a device while it is not ready
After registering the cdev, it would be possible do have an open on it.
In a matter of fact, some versions of udev do this. So, move registration
to the end and protect it with a mutex.
[media] cx231xx: Allow some boards to not use I2C port 3
Some devices don't need to use it. So allow to just disable this logic.
Having it enabled on some devices cause power management to complain,
generating error -71.
[media] cx231xx: Use parameters to describe some board variants
Instead of per-model tests all over the code, use some parameters
at the board entries to describe the model variants for:
- devices with 417 MPEG encoder;
- devices that use external AV;
- devices where vbi VANC endpoint doesn't work;
- devices with xc5000 that require different IF
initialization (and probably will cover also
xc3028).
- devices with xceive tuner that require a reset
during init.
[media] cx231xx: Use a generic check for TUNER_XC5000
The check for xc5000 assumes that the tuner will always
be using the same bus and will have the same address.
As those are configurable via dev->board, it should use,
instead, the values defined there.
Also, a similar type of test will be needed by other
tuners (for example, for TUNER_XC2028)
[media] cx231xx: Simplify interface checking logic at probe
Just a cleanup patch. Removes one indent level by moving
the return -ENODEV to happen before the device register
logic, if the interface is not the audio/video (int 1).
[media] saa7134: Properly report when a board doesn't have eeprom
When a device is not detected, the driver prints a warning message.
That's ok, except for the fact that, even on newer devices that have
eeprom but aren't yet supported, it prints a message saying that the
device doesn't have eeprom.
Fix it by having a separate message for devices with eeprom, but not
yet known by the driver.
[media] ngene: Fix compilation when cxd2099 is not enabled
drivers/media/dvb/ngene/ngene-i2c.o: In function `cxd2099_attach':
ngene-i2c.c:(.text+0x195): multiple definition of `cxd2099_attach'
drivers/media/dvb/ngene/ngene-core.o:ngene-core.c:(.text+0x100): first defined here
drivers/media/dvb/ngene/ngene-cards.o: In function `cxd2099_attach':
ngene-cards.c:(.text+0x116): multiple definition of `cxd2099_attach'
drivers/media/dvb/ngene/ngene-core.o:ngene-core.c:(.text+0x100): first defined here
drivers/media/dvb/ngene/ngene-dvb.o: In function `cxd2099_attach':
ngene-dvb.c:(.text+0x7ad): multiple definition of `cxd2099_attach'
drivers/media/dvb/ngene/ngene-core.o:ngene-core.c:(.text+0x100): first defined here
This driver is abusing the kernel<=>userspace API, due to the lack of a
proper solution for it. A discussion were done at:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html
But there's not a solution for it yet. So, move the driver to staging, while
we don't have a final solution.
Oliver Endriss [Mon, 10 Jan 2011 09:36:24 +0000 (06:36 -0300)]
[media] stv090x: 22kHz workaround must also be performed for the 2nd frontend
22kHz workaround must also be performed for the 2nd frontend.
Signed-off-by: Oliver Endriss <o.endriss@gmx.de> Signed-off-by: Manu Abraham <manu@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
projects / mv-sheeva.git / log