- 14 May, 2012 40 commits
-
-
Hans de Goede authored
Enabling vflip leads to a much better image, with vflip disabled the image looks washed out as if there is a too high brightness setting. Since we don't know how to lower the brightness setting when not vflipping, simply always vflip and tell userspace to flip the image back, resulting in a much better (less washed out) image. Since the image is now no longer too bright, also modify the luminance level the auto-gain algorithm aims for. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans de Goede authored
Our init sequence was not setting the register page to point to bank 1 before setting what should be the control reg. This causes the camera to sometimes have its LED on after init. First selecting register bank 1, rather then assuming the current register bank is bank 1, fixes this. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
Now that the pac207 driver has been converted to the control framework, there are no remaining users. Signed-off-by:
-
Hans de Goede authored
The pac207's exposure control is a clock-divider, so it goes with quite big steps. So lets use an autogain algorithm optimised for that. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
We intend to eventually port all sub-drivers to the control-framework. At which point it will make more sense to have the ctrl_handler in gspca_dev then to have it in the subdrivers. Lets move it there now, to avoid a lot of work to move it later. Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Hans de Goede authored
Now that stv06xx is using the control framework it is no longer necessary to have a (non const) copy of sd_desc inside the sd specific data struct. Signed-off-by:
-
Hans Verkuil authored
HdG: 1) Let the gspca-core cleanup the controls on control-init error, like with the other converted sub drivers 2) Note this also fixes a bug in the hdcs1020 support which was wrongly reporting an exposure range of 0-65535, even though the effective range was only 0-255 Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans Verkuil authored
HdG: Small fix: don't register some controls for sensors which don't have an implementation for them. Signed-off-by:
-
Hans Verkuil authored
The initial version was done by HV, corrections were made by HdG, and some final small changes again by HV. Signed-off-by:
-
Hans de Goede authored
Even with BRC the highest quality setting is not usable, BRC strips so much data from each MCU that the quality becomes worse then using a lower quality setting to begin with. Signed-off-by:
-
Hans de Goede authored
Always automatically adjust the Bit Rate Control setting as needed, independent of the sensor type. BRC is needed to not run out of bandwidth with higher quality settings independent of the sensor. Also only automatically adjust BRC, and don't adjust the JPEG quality control automatically, as that is not needed and leads to ugly flashes when it is changed. Note that before this patch-set the quality was never changed either due to the bugs in the quality handling fixed in previous patches in this set. Signed-off-by:
-
Hans de Goede authored
The current code is using bits 0-1 of register 8 of the zc3xx controller to set the JPEG quality, but the correct bits are bits 1-2. Bit 0 selects between truncation or rounding in the quantization phase of the compression, since rounding generally gives better results it should thus always be 1. This patch also corrects the quality percentages which belong to the 4 different settings. Last this patch removes the different reg 8 defaults depending on the sensor type. Some of them where going for a default quality setting of 50%, which generally is not necessary in any way and results in poor image quality. 75% is a good default to use for all scenarios. Signed-off-by:
-
Hans de Goede authored
When the user changes the JPEG quality while the camera is streaming, the driver should not only change the JPEG headers send to userspace, but also actually tell the camera to use a different quantization table. Signed-off-by:
-
Hans de Goede authored
The sensor specific dev_post_unset_alt functions all try to write to the bridge, and none free any memory, so they should be skipped if stop0 is called on disconnection. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
Just a small cleanup. Signed-off-by:
-
Hans de Goede authored
This is necessary to ensure that worker-threads accessing the device are stopped before our disconnect handler returns. This causes a problem with stream_off calling sd_stop0 a second time when the device handle is closed. This is fixed by setting gscpa_dev->streaming to 0 on disconnect. Note that now stream_off will never be called on a disconnected device, and the present check can thus be removed from stream_off. Signed-off-by:
-
Hans de Goede authored
So that we don't start a read stream when an app is only polling for control events. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans Verkuil authored
Due to latency concerns the VIDIOC_QBUF, DQBUF and QUERYBUF do not use the core lock, instead they rely only on queue_lock. Changes by HdG: 1) Change release from the video_device to the v4l2_device, to avoid a race on disconnect. 2) Adjust for the V4L2 core changes which cause non ioctl fops to no longer take the V4L2 core lock. [mchehab@redhat.com: fix a merge conflict] Signed-off-by:
-
Hans Verkuil authored
There are two bugs here: first the calls to stop0 (in gspca_suspend) and gspca_init_transfer (in gspca_resume) need to be called with the usb_lock held. That's true for the other places they are called and it is what subdrivers expect. Quite a few will unlock the usb_lock in stop0 while waiting for a worker thread to finish, and if usb_lock isn't held then that can cause a kernel oops. The other problem is that a worker thread needs to detect that it has to halt due to a suspend. Otherwise it will just go on looping. So add tests against gspca_dev->frozen in the worker threads that need it. Hdg, 2 minor changes: 1) The finepix device is ok with stopping reading a frame halfway through, so add frozen checks in all places where we also check if we're still streaming 2) Use gspca_dev->dev instead of gspca_dev->present to check for disconnect in all touched drivers. I plan to do this everywhere in the future, and most relevant lines in the touched drivers are already modified by this patch. Signed-off-by:
-
Hans Verkuil authored
Add V4L2_CAP_DEVICE_CAPS support to querycap and replace -EINVAL by -ENOTTY whenever an ioctl is not supported. Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
In order to support control event gspca has to use struct v4l2_fh. As a bonus feature this also gives priority handling for free. Signed-off-by:
-
Hans Verkuil authored
Prepare for control events: free up file->private_data by using video_drvdata(file) to get to the gspca_dev struct. [mchehab@redhat.com: fix a compile error: ‘file’ undeclared] Signed-off-by:
-
Hans Verkuil authored
Make the necessary changes to allow subdrivers to use the control framework. This does not add control event support, that comes later. It add a init_control cam_op that is called after init in probe that allows the subdriver to set up the controls. HdG: Call v4l2_ctrl_handler_setup from resume instead of gspca_set_default_mode, as we just want to resend the current ctrl values to the device. Signed-off-by:
-
Hans de Goede authored
My last locking rework for pwc mistakenly assumed that videbuf2 does its own locking, but it does not! This patch fixes the missing locking by moving over the the video_device lock, and introducing a separate lock for the videobuf2_queue. Signed-off-by:
-
Hans de Goede authored
Various error paths in fileio_init where not setting the request-count to 0 when unrequesting the buffers on error to init the fileio emulation. Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
This used to be the default if the lock pointer was set, but now that lock is by default only used for ioctl serialization. Those drivers that already used core locking have this flag set explicitly, except for some drivers where it was obvious that there was no need to serialize any file operations other than ioctl. The drivers that didn't need this flag were: drivers/media/radio/dsbr100.c drivers/media/radio/radio-isa.c drivers/media/radio/radio-keene.c drivers/media/radio/radio-miropcm20.c drivers/media/radio/radio-mr800.c drivers/media/radio/radio-tea5764.c drivers/media/radio/radio-timb.c drivers/media/video/vivi.c sound/i2c/other/tea575x-tuner.c The other drivers that use core locking and where it was not immediately obvious that this flag wasn't needed were changed so that the flag is set together with a comment that that driver needs work to avoid having to set that flag. This will often involve taking the core lock in the fops themselves. Eventually this flag should go and it should not be used in new drivers. There are a few reasons why we want to avoid core locking of non-ioctl fops: in the case of mmap this can lead to a deadlock in rare situations since when mmap is called the mmap_sem is held and it is possible for other parts of the code to take that lock as well (copy_from_user()/copy_to_user() perform a down_read(&mm->mmap_sem) when a page fault occurs). It is very unlikely that that happens since the core lock serializes all fops, but the kernel warns about it if lock validation is turned on. For poll it is also undesirable to take the core lock as that can introduce increased latency. The same is true for read/write. While it was possible to make flags or something to turn on/off taking the core lock for each file operation, in practice it is much simpler to just not take it at all except for ioctl and leave it to the driver to take the lock. There are only a handful fops compared to the zillion ioctls we have. I also wanted to make it obvious which drivers still take the lock for all fops, so that's why I chose to have drivers set it explicitly. Signed-off-by:
-
Hans Verkuil authored
Rather than checking the priority for each ioctl that needs to, just mark such ioctls in the table and do it only once. Signed-off-by:
-
Hans Verkuil authored
The tea575x-tuner framework can support the VIDIOC_S_HW_FREQ_SEEK for only some of the tea575x-based boards. Mark this ioctl as invalid if the board doesn't support it. This fixes an issue with S_HW_FREQ_SEEK in combination with priority handling: since the priority check is done first it could return -EBUSY, even though calling the S_HW_FREQ_SEEK ioctl would return -ENOTTY. It should always return ENOTTY in such a case. Signed-off-by:
-
Hans Verkuil authored
Rather than testing whether an ioctl is implemented in the driver or not every time the ioctl is called, do it upfront when the device is registered. This also allows a driver to disable certain ioctls based on the capabilities of the detected board, something you can't do today without creating separate v4l2_ioctl_ops structs for each new variation. For the most part it is pretty straightforward, but for control ioctls a flag is needed since it is possible that you have per-filehandle controls, and that can't be determined upfront of course. Signed-off-by:
-
Hans Verkuil authored
Using the V4L2 core lock is a very robust method that is usually very good at doing the right thing. But some drivers, particularly USB drivers, may want to prevent the core from taking the lock for specific ioctls, particularly buffer queuing ioctls. The reason is that certain commands like S_CTRL can take a long time to process over USB and all the time the core has the lock, preventing VIDIOC_DQBUF from proceeding, even though a frame may be ready in the queue. This introduces unwanted latency. Since the buffer queuing commands often have their own internal lock it is often not necessary to take the core lock. Drivers can now say that they don't want the core to take the lock for specific ioctls. As it is a specific opt-out it makes it clear to the reviewer that those ioctls will need more care when reviewing. Signed-off-by:
-
Sakari Ailus authored
Add driver for SMIA++/SMIA image sensors. The driver exposes the sensor as three subdevs, pixel array, binner and scaler --- in case the device has a scaler. Currently it relies on the board code for external clock handling. There is no fast way out of this dependency before the ISP drivers (omap3isp) among others will be able to export that clock through the clock framework instead. Signed-off-by:
Sakari Ailus <sakari.ailus@maxwell.research.nokia.com> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
