- 11 Sep, 2011 9 commits
-
-
Jean-François Moine authored
The webcam is build from an Omnivision test kit which contains a OV538 bridge and a OV9712 sensor. Signed-off-by:
Jean-François Moine <moinejf@free.fr> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-François Moine authored
Signed-off-by:
-
Jean-François Moine authored
The variable gspca_debug is defined and settable in gspca main. Signed-off-by:
-
Jean-François Moine authored
Signed-off-by:
-
Jean-François Moine authored
Lower exposure values give too dark images. Signed-off-by:
-
Jean-François Moine authored
The contrast was too low. Higher values are better. Signed-off-by:
-
Jean-François Moine authored
Signed-off-by:
-
Jean-François Moine authored
The images are clearer with a lower bridge clock. Signed-off-by:
-
Jean-François Moine authored
The list of the webcams which have LED inversion was rebuild scanning ms-win .inf files. Signed-off-by:
-
- 09 Sep, 2011 2 commits
-
-
Michael Krufky authored
The check for (adap->active_fe < 0) at the top of dvb_usb_ctrl_feed is a sanity check to ensure that adap->active_fe is valid. Improve that sanity check by also checking for (adap->active_fe >= adap->num_frontends_initialized) Signed-off-by:
Michael Krufky <mkrufky@kernellabs.com> Signed-off-by:
-
Michael Krufky authored
This fixes a bug introduced by a previous changeset entitled, [media] dvb-usb: refactor MFE code for individual streaming config per frontend As reported by Antti Palosaari, This error is shown by VLC when channel changed: [0x7f1bbc000cd0] dvb access error: DMXSetFilter: failed with -1 (Invalid argument) [0x7f1bbc000cd0] dvb access error: DMXSetFilter failed [0x7f1bbc32f910] main stream error: cannot pre fill buffer After my own investigations, I've determined that this error case occurs when the application stops streaming but leaves the frontend and dvr devices open. A typical example of this usage would be a channel change operation while watching live television. The error occurs when the application attempts to stream after tuning to the new channel. To prevent this error, don't set adap->active_fe to -1 unless the application closes the device. Cc: Antti Palosaari <crope@iki.fi> Signed-off-by:
-
- 08 Sep, 2011 1 commit
-
-
Tony Jago authored
Hauppauge have released a new model rev, sub id 8940, this adds support. [stoth@kernellabs.com: I modified Tony's patch slightly in relation to the card numbering in saa7164.h, appending rather than inserting the new card - normal practise] Signed-off-by:
Tony Jago <tony@hammertelecom.com.au> Signed-off-by:
Steven Toth <stoth@kernellabs.com> Signed-off-by:
-
- 06 Sep, 2011 28 commits
-
-
Sylwester Nawrocki authored
The driver supports only multi-planar API and conversion to single-planar API should be done in libv4l2. Remove misleading single planar capability flags to avoid problems in applications and libv4l2. Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
-
Sylwester Nawrocki authored
Horizontal crop offset must be multiple of 2 otherwise color distortion occurs. Signed-off-by:
-
Sylwester Nawrocki authored
Add support for whole pipeline suspend/resume. Sensors must support suspend/resume through s_power subdev operation. Signed-off-by:
-
Sylwester Nawrocki authored
Also correct and improve *_queue_add/pop functions description. Signed-off-by:
-
Sylwester Nawrocki authored
Signed-off-by:
-
Sylwester Nawrocki authored
Add support for transparent DMA transfer of JPEG data with MIPI-CSI2 USER1 format. In JPEG mode the color effect, scaling and cropping is not supported as well as image rotation and flipping thus these controls are marked as inactive if V4L2_PIX_FMT_JPEG pixel format was selected. Signed-off-by:
-
Sylwester Nawrocki authored
Add a subdev to expose the host's scaling and composition functions. The camera frame composition onto an output buffer may be configured through set/get_crop at FIMC.{n} source pad. Additionally allow crop, composition and controls to be modified during streaming. Make sure the default format is set when opening the video capture node. Rename struct fimc_vid_cap::fmt to more relevant 'mf' to avoid confusion. Signed-off-by: -
Sylwester Nawrocki authored
In the camera capture driver use fimc_pipeline_* calls provided by the media device driver part, in place where v4l2_subdev_call() were used. This way the capture driver don't need to differentiate between various H/W pipeline setups, i.e. if the MIPI-CSI receiver subdev is used or not. Remove the sync_capture_fmt() function instead of which fimc_pipeline_try_format() is introduced in the following patch adding the FIMC capture subdev. The TRY_FMT ioctl function is completed by a subsequent patch adding the capture subdev, so the try_fmt routines can be reused in the subdev and the video node ioctl handlers. Signed-off-by:
-
Sylwester Nawrocki authored
Replace fimc_find_format() and find_mbus_format() with single function that can return a pointer to the private format description based on fourcc, media bus code or index in the table. Create separate VIDIOC_ENUM_FMT ioctl handlers for video capture and mem-to-mem video node. This is needed because some formats are valid only for the video capture and some only for the mem-to-mem video node. Signed-off-by:
-
Sylwester Nawrocki authored
Move the camera capture H/W initialization sequence to a separate function. This is needed for reuse in the following runtime PM code. Signed-off-by:
-
Sylwester Nawrocki authored
Add the link_setup handler for the camera capture video node. Signed-off-by:
-
Sylwester Nawrocki authored
Convert the v4l controls code to use the new control framework. fimc_ctrls_activate/deactivate functions are introduced for the transparent DMA transfer mode (JPEG), where the rotation and flipping controls are not supported. The capture video node does not inherit sensors' controls when the subdevs are configured by the user space (user_subdev_api == true). However by default after the driver's initialization the 'user-subdev_api' flag is false and any sensor controls will also be available at the video node. When the pipeline links are disconnected through the media device the FIMC and any sensor inherited controls are destroyed and then again created when the pipeline connection completes. Signed-off-by:
-
Sylwester Nawrocki authored
This is a prerequisite for the patch converting the driver to use the control framework. As the capture driver does not use per file handle contexts, two separate ioctl handlers are created for it (vidioc_try_fmt_mplane, and vidioc_g_fmt_mplane) so there is no handlers shared between the memory-to-memory and capture video node. Signed-off-by:
-
Sylwester Nawrocki authored
Add a top level media device driver aggregating FIMC video devnodes, MIPI-CSIS and sensor subdevs. This driver gathers all media entities and creates the possible links between them during initialization. By default some links will be activated to enable access to all available sensors in the system. For example if there are sensors S0, S1 listed in the media device platform data definition they will be by default assigned to FIMC0, FIMC1 respectively, which in turn will corresponds to separate /dev/video?. There is enough FIMC H/W entities to cover all available physical camera interfaces in the system. The fimc media device driver is bound to the "s5p-fimc-md" platform device. Such platform device should be created by board initialization code and camera sensors description array need to be specified as its platform data. The media device driver also implements various video pipeline operations, for enabling subdevs power, streaming, etc., which will be used by the capture video node driver. Signed-off-by:
-
Sylwester Nawrocki authored
Currently there is a v4l2_device instance being registered per each (capture and memory-to-memory) video node created per FIMC H/W instance. This patch is a prerequisite for using the top level v4l2_device instantiated by the media device driver. To retain current debug trace semantic (so it's possible to distinguish between the capture and m2m FIMC) the video_device is used in place of v4l2_device where appropriate. Signed-off-by:
-
Sylwester Nawrocki authored
The sensor subdevs need to be shared between all available FIMC instances. Remove their registration from FIMC capture driver so they can then be registered to the media device driver. Signed-off-by:
-
Sylwester Nawrocki authored
The current driver allowed camera sensors to be used only with single FIMC H/W instance, FIMC0..FIMC2/3, designated at compile time. Remaining FIMC entities could be used for video processing only, as mem-to-mem devices. Required camera could be selected with S_INPUT ioctl at one devnode only. However in that case it was not possible to use both cameras independently at the same time, as all sensors were registered to single FIMC capture driver. In most recent S5P SoC version there is enough FIMC H/W instances to cover all physical camera interfaces. Each FIMC instance exports its own video devnode. Thus we distribute the camera sensors one per each /dev/video? by default. It will allow to use both camera simultaneously by opening different video node. The camera sensors at FIMC are now not selected with S_INPUT ioctl, there is one input only available per /dev/video?. By default a single sensor is connected at FIMC input as specified by the media device platform data subdev description table. This assignment can be changed at runtime through the pipeline reconfiguration at the media device level. Signed-off-by:
-
Sylwester Nawrocki authored
There are 2 separate clock outputs available in the SoC for external sensors. These two clocks can be shared among all FIMC entities and there is currently no any arbitration of the clocks in the driver. So make the capture driver not touching these clocks and let them be be properly handled at the media device driver level, enabling proper arbitration between FIMC entities. Signed-off-by:
-
Sylwester Nawrocki authored
Do not register video nodes during FIMC device probe. Also make fimc_register_m2m_device() public for use by the media device driver. The video nodes are to be registered during the media device driver initialization, altogether with the subdev devnodes. The video capture nodes need to be registered as last ones when the remaining pipeline elements are already initialized. Signed-off-by:
-
Sylwester Nawrocki authored
Add intialization of the media entities for video capture and mem-to-mem video nodes. The mem-to-mem entity has no pads whereas the capture entity has single sink pad. Also clean up the video node naming for consistency. Signed-off-by:
-
Sylwester Nawrocki authored
Do not resume the device during system resume if it was idle before system suspend, as this causes resume from suspend to RAM failures on Exynos4. For this purpose runtime PM and system sleep helpers are separated. Signed-off-by:
-
Sylwester Nawrocki authored
On the SoCs this driver is intended to support the are three separate pins to supply the MIPI-CSIS subsystem: 1.1V or 1.2V, 1.8V and power supply for an internal PLL. This patch adds support for two separate voltage supplies to cover properly board configurations where PMIC requires to configure independently each external supply of the MIPI-CSI device. The 1.8V and PLL supply are assigned a single "vdd18" regulator supply name as it seems more reasonable than creating separate regulator supplies for them. While at here stop using the 'fixed_phy_vdd' platform_data field. It has been introduced for boards where the MIPI-CSIS supplies are not controllable. However it is not needed as those boards can use the dummy regulator. Signed-off-by:
-
Sylwester Nawrocki authored
Add runtime PM and system sleep support in the memory-to-memory driver. It's required to enable the FIMC operation on Exynos4 SoCs. This patch prevents system boot failure when the driver is compiled in, as it now tries to access its I/O memory without first enabling the corresponding power domain. The camera capture device suspend/resume is not fully covered, the capture device is just powered on/off during the video node open/close. However this enables it's normal operation on Exynos4 SoCs. [mchehab@redhat.com: fix a small checkpatch error] Signed-off-by:
-
Marek Szyprowski authored
This patch changes the order of operations during stream on call. Now the buffers are first queued to the driver and then the start_streaming method is called. This resolves the most common case when the driver needs to know buffer addresses to enable dma engine and start streaming. Additional parameter to start_streaming method have been added to simplify drivers code. The driver are now obliged to check if the number of queued buffers is high enough to enable hardware streaming. If not - it can return an error. In such case all the buffers that have been pre-queued are invalidated. This patch also updates all videobuf2 clients to work properly with the changed order of operations. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Josh Wu <josh.wu@atmel.com> Signed-off-by:
-
Yu Tang authored
Align vb2 user pointer VMA release sequence with munmap. Do vm_ops->vm_close before release file. Signed-off-by:
Yu Tang <ytang5@marvell.com> Signed-off-by:
-
Marek Szyprowski authored
Use the correct 'dma_addr' name for the buffer address. 'paddr' suggested that this is the physical address in system memory. For most ARM platforms these two are the same, but this is not a generic rule. 'dma_addr' will also point better to dma-mapping api. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
Marek Szyprowski authored
Plane sizes array was declared as unsigned long[], while unsigned int is more than enough for storing size of the video buffer. This patch reduces the size of the array by definiting it as unsigned int[]. Reported-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Marek Szyprowski authored
MAPPED flag was set for the buffer only if all it's planes were mapped and relied on a simple mapping counter. This assumption is really bogus, especially because the buffers may be mapped multiple times. Also the meaning of this flag for muliplane buffers was not really useful. This patch fixes this issue by setting the MAPPED flag for the buffer if any of it's planes is in use (what means that has been mapped at least once), so MAPPED flag can be used as 'in_use' indicator. Reported-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
