Hans Verkuil [Sun, 6 Sep 2009 10:54:00 +0000 (07:54 -0300)]
V4L/DVB (12725): v4l: warn when desired devnodenr is in use & add _no_warn function
Warn when the desired device node number is already in use, except when
the new video_register_device_no_warn function is called since in some
use-cases that warning is not relevant.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Mon, 7 Sep 2009 06:40:24 +0000 (03:40 -0300)]
V4L/DVB (12724): v4l2-dev: add simple wrapper functions around the devnode numbers
There are some subtle differences in the way the devnode numbers are
handled depending on whether the FIXED_MINOR_RANGES config option is
set. Add some simple wrapper functions to handle that correctly.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sun, 6 Sep 2009 10:13:14 +0000 (07:13 -0300)]
V4L/DVB (12722): v4l2-dev: replace 'kernel number' by 'device node number'.
The term 'kernel number' is very vague, so replace it with the somewhat more
descriptive term 'device node number'.
In one place the local variable 'nr' was used to create the device node number
of the new device name. This has been replaced with the vdev->num field to
more clearly mark this as being the device node number and not the minor
number.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Mon, 10 Aug 2009 05:49:08 +0000 (02:49 -0300)]
V4L/DVB (12540): v4l: simplify v4l2_i2c_new_subdev and friends
Rewrite v4l2_i2c_new_subdev as a simplified version of v4l2_i2c_new_subdev_cfg
and remove v4l2_i2c_new_probed_subdev and v4l2_i2c_new_probed_subdev_addr.
This simplifies this API substantially.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
V4L/DVB (12580): soc-camera: remove now unneeded subdevice group ID assignments
Since we are not using v4l2_device_call_* calls any more, we don't need to
initialise subdevice .grp_id any more. This also fixes compiler warnings on
64-bit platforms.
V4L/DVB (12534): soc-camera: V4L2 API compliant scaling (S_FMT) and cropping (S_CROP)
The initial soc-camera scaling and cropping implementation turned out to be
incompliant with the V4L2 API, e.g., it expected the user to specify cropping
in output window pixels, instead of input window pixels. This patch converts
the soc-camera core and all drivers to comply with the standard.
V4L/DVB (12529): soc-camera: switch to s_crop v4l2-subdev video operation
Remove set_crop soc-camera device method and switch to s_crop from v4l2-subdev
video operations. Also extend non-i2c drivers to also hold a pointer to their
v4l2-subdev instance in control device driver-data, i.e., in
dev_get_drvdata((struct device *)to_soc_camera_control(icd))
Use host-side image scaling when the client fails to set the requested format.
We also have to take scaling into account when performing host-side cropping.
Similar to cropping we try to use client-side scaling as much as possible to
preserve bus bandwidth and optimise the frame-rate.
V4L/DVB (12527): tw9910: do not lie about cropping abilities
The current tw9910 driver does not implement cropping correctly. Therefore, and
also because various rectangles in struct soc_camera_device are in user scale,
we cannot and shall not use rect_current as window location.
V4L/DVB (12526): ov772x: do not use scaling for cropping
OV772x sensors cannot crop, they only support two fixed formats: VGA and QVGA.
We should not change the format when requested to crop, only S_FMT can do this.
V4L/DVB (12525): soc-camera: prohibit geometry change with initialised buffers
Prohibit S_FMT and S_CROP with a different window width or height after video
buffer initialisation. This simplifies the work to be done in specific host and
client drivers, and it doesn't seem to make much sense to allow these changes.
We do however allow S_CROP with equal width and height to just move the window,
this doesn't affect video buffer management and is usually easy enough to
implement.
Not all video capture devices can configure arbitrary cropping, whereas the
CEU module on SuperH CPUs can crop with pixel precision. However, we want to
use camera cropping if possible to save bandwidth and increase the frame-rate.
This patch verifies whether the camera managed to crop exactly the requested
rectangle, and if not, uses host-side cropping. To be able to crop on CEU we
have to preserve camera rectangle too, for which the host_priv member in
struct soc_camera_device is used. We now allocate memory dynamically, thus we
have to use the .put_formats() method from struct soc_camera_host_ops to free
it.
V4L/DVB (12520): sh-mobile-ceu-camera: do not wait for interrupt when releasing buffers
Patch
[PATCH] video: use videobuf_waiton() in sh_mobile_ceu free_buffer()
was not quite correct. It closed a race, but introduced a potential
lock-up, if for some reason an interrupt does not come. This has been
observed in tests with tw9910. This patch safely dequeues buffers without
waiting for their completion. It also moves a buffer state assignment
under a spinlock to make it atomic with queuing of the buffer.
V4L/DVB (12519): soc-camera: put pixel format initialisation back in probe, add .put_formats()
The move of format translation initialisation into soc_camera_open() was
temporary for the soc-camera as platform driver intermediate step, put it back
into soc_camera_probe(). Also add a .put_formats() method to
soc_camera_host_ops to free any resources host driver might have allocated in
.get_formats().
V4L/DVB (12518): ov772x: S_CROP must return actually configured geometry
V4L2 drivers are allowed to configure a geometry different than what has been
requested by the user with S_CROP, but then they have to adjust the input
rectangle accordingly. Fix ov772x to comply with this requirement.
V4L/DVB (12517): mt9t031: improve rectangle placement in invalid S_CROP
1. soc-camera always requests a valid rectangle, when calling .s_fmt(), no need
to check and adjust
2. in .s_crop(), if the rectangle exceeds sensor limits, push it to the
respective border instead of centering
3. take into account left and top borders when checking
V4L/DVB (12512): ov772x: implement a band-stop filter support
The V4L2_CID_BAND_STOP_FILTER control is used to switch the "Banding Filter" on
OV772x cameras on and off and to set the minimum AEC value in BDBASE register.
V4L/DVB (12510): soc-camera: (partially) convert to v4l2-(sub)dev API
Convert the soc-camera framework to use the v4l2-(sub)dev API. Start using
v4l2-subdev operations. Only a part of the interface between the
soc_camera core, soc_camera host drivers on one side and soc_camera device
drivers on the other side is replaced so far. The rest of the interface
will be replaced in incremental steps, and will require extensions and,
possibly, modifications to the v4l2-subdev code.
V4L/DVB (12509): sh: prepare board-ap325rxa.c for v4l2-subdev conversion
We will be registering and unregistering the soc_camera_platform platform
device multiple times, therefore we need a .release() method and have to
nullify the kobj.
V4L/DVB (12506): soc-camera: convert to platform device
Convert soc-camera core and all drivers to platform device API. We already
converted platforms to register a platform device for each soc-camera client,
now we remove the compatibility code and switch completely to the new scheme.
This is a preparatory step for the v4l2-subdev conversion.
V4L/DVB (12505): soc_camera_platform: pass device pointer from soc-camera core on .add_device()
Add a struct device pointer to struct soc_camera_platform_info and let the user
(ap325rxa) pass it down to soc_camera_platform.c in its .add_device() method.
V4L/DVB (12504): soc-camera: prepare soc_camera_platform.c and its users for conversion
soc_camera_platform.c is only used by y SuperH ap325rxa board. This patch
converts soc_camera_platform.c and its users for the soc-camera platform-
device conversion and also extends soc-camera core to handle non-I2C cameras.
Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
V4L/DVB (12253): v4l: common vpss module for video drivers
This is a new module added for vpss library functions that are
used for configuring vpss system module. All video drivers will
include vpss.h header file and call functions defined in this
module to configure vpss system module.
V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture driver
This is the hw module for DM644x CCDC. This registers with the
vpfe capture driver and provides a set of hw_ops to configure
CCDC for a specific decoder device connected to the VPFE.
Reviewed by: Hans Verkuil <hverkuil@xs4all.nl>
Reviewed by: Laurent Pinchart <laurent.pinchart@skynet.be>
V4L/DVB (12250): v4l: dm355 ccdc module for vpfe capture driver
Adds ccdc hw module for DM355 CCDC. This registers with the bridge
driver a set of hw_ops for configuring the CCDC for a specific
decoder device connected to vpfe.
V4L/DVB (12248): v4l: vpfe capture bridge driver for DM355 and DM6446
This the vpfe capture bridge driver for doing video
capture on DM355 and DM6446 evms. The ccdc hw modules register with the
driver and are used for configuring the CCD Controller for a specific
decoder interface. The driver also registers the sub devices required
for a specific evm. More than one sub devices can be registered.
This allows driver to switch dynamically to capture video from
any sub device that is registered. Currently only one sub device
(tvp5146) is supported. But in future this driver is expected
to do capture from sensor devices such as Micron's MT9T001, MT9T031
and MT9P031 etc. The driver currently supports MMAP based IO.
Chaithrika U S [Mon, 22 Jun 2009 12:02:55 +0000 (09:02 -0300)]
V4L/DVB (12178): vpif_display: Fix compile time warnings for mutex locking
mutex_lock_interruptible return value has to be handled properly to indicate
the status to the higher layers of the kernel.
Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Michael Krufky [Sun, 6 Sep 2009 14:13:09 +0000 (11:13 -0300)]
V4L/DVB (12970): saa7164: fix 64bit build warning
Fix the following build warning:
CC [M] saa7164-core.o
saa7164-core.c: In function 'saa7164_buffer_deliver':
saa7164-core.c:113: warning: passing argument 2 of 'dvb_dmx_swfilter_packets'
from incompatible pointer type
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The VIDIOC_G_STD ioctl may not be present in the case of radio receivers.
In that case G_STD will return an error. The v4l1-compat layer should not
attempt to propagate that error to the caller, instead it should be
ignored.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Steven Toth [Thu, 27 Aug 2009 21:08:21 +0000 (18:08 -0300)]
V4L/DVB (12942): SAA7164: HVR2250 changes related to attach time tuner configuration
Ensure that by default all tuners are set correctly to master/slave mode.
For all HVR2250's, ensure slave based tuners are caliberated during attach
to avoid locking problems on tuner# above channel 91.
HVR2200 tuner attach time to be reviewed in a future patch.
Signed-off-by: Steven Toth <stoth@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Steven Toth [Wed, 12 Aug 2009 15:14:37 +0000 (12:14 -0300)]
V4L/DVB (12940): SAA7164: IRQ / message timeout related change
In some cases we're seeing large timeouts on commands. I'm changing the
implementation so that the deferred worker checks the PCI bus for
any messages and signals the waiting caller accordingly. The previous
mechanism was too unreliable.
Signed-off-by: Steven Toth <stoth@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Steven Toth [Sat, 8 Aug 2009 13:22:02 +0000 (10:22 -0300)]
V4L/DVB (12938): SAA7164: Increase the firmware command timeout to avoid firmware errors.
The firmware typically responds in < 50ms and, via the interrupts and
deferred work queue the caller (blocked in the driver) is signalled very
efficiently. In a highly stressed system this can take many multiples
of seconds. So, we need a larger maximum timeout for busy systems.
Signed-off-by: Steven Toth <stoth@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
projects / linux-beck.git / log