- 21 Sep, 2011 39 commits
-
-
Sylwester Nawrocki authored
SR030PC30, NOON010PC30, M5MOLS are camera sensors so better place for them is under the "Camera sensors" Kconfig section. Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Sylwester Nawrocki authored
Remove the now unneeded check for the platform data in s_power handler and the platform data pointer in struct noon010_info. Also do not reset the configured output resolution and pixel format when cycling sensor's power. Add small delay for proper reset signal shape. Signed-off-by:
-
Sylwester Nawrocki authored
Replace g/s_mbus_fmt ops with the pad level get/set_fmt operations. Add media entity initialization and set subdev flags so the host driver creates a subdev device node for the driver. A mutex was added for serializing the subdev operations. When setting format is attempted during streaming an (EBUSY) error will be returned. After the device is powered up it will now remain in "power sleep" mode until s_stream(1) is called. The "power sleep" mode is used to suspend/resume frame generation at the sensor's output through s_stream op. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Thomas Meyer authored
Use resource_size function on resource object instead of explicit computation. The semantic patch that makes this output is available in scripts/coccinelle/api/resource_size.cocci. More information about semantic patching is available at http://coccinelle.lip6.fr/Signed-off-by:
Thomas Meyer <thomas@m3y3r.de> Signed-off-by:
-
Michael Grzeschik authored
Signed-off-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Acked-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
Sylwester Nawrocki authored
s_stream does nothing in current form so remove it. Signed-off-by:
Kyungmin Park <kyungin.park@samsung.com> Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
Now that the auto cluster core changed to a different scheme of how to handle volatile controls (including how to switch from auto to manual mode) the pwc code can be simplified to use that new core support. Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
The problem tackled in this patch is how to handle volatile autoclusters correctly. A volatile autocluster is a cluster of related controls where one control is the control that toggles between manual and auto mode and the other controls are the values for the manual mode. For example autogain and gain, autoexposure and exposure, etc. If the hardware lets you read out the automatically calculated manual values while in automode, then those manual controls should be marked volatile. gain value as calculated by the autogain circuitry, then you would mark the gain control as volatile (i.e. continuously changing). The question in such use cases is what to do when switching from the auto mode to the manual mode. Should we switch to the last set manual values or should the volatile values be copied and used as the initial manual values. For example: suppose the mode is manual gain and gain is set to 5. Then autogain is turned on and the gain is set by the hardware to 2. Finally the user switches back to manual gain. What should the gain be? 2 or 5? After a long discussion the decisions was made to keep the last value as calculated by the auto mode (so 2 in the example above). The reason is that webcams that do such things will adapt themselves to the current light conditions and when you switch back to manual mode you expect that you keep the same picture. If you would switch back to old manual values, then that would give you a suddenly different picture, which is jarring for the user. Additionally, this would be difficult to implement in applications that store and restore the control values at application exit and start. If you want to keep the old manual values when you switch from auto to manual, then there would have to be a way for applications to get hold of those old values while in auto mode, but there isn't. So this patch will do all the heavy lifting in v4l2-ctrls.c: if you go from auto mode to manual mode and the manual controls are volatile, then g_volatile_ctrl will be called to get the current values for the manual controls before switching to manual mode. Signed-off-by:
-
Steven Toth authored
Thanks to Greg Tangey for prompting me to merge this. Signed-off-by: -
Antti Palosaari authored
it9135 was the only one intended with spaces as others are tabs. Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Antti Palosaari authored
msleep() => usleep_range() Signed-off-by:
-
Antti Palosaari authored
Signed-off-by:
-
Chris Rankin authored
Signed-off-by:
Chris Rankin <rankincj@yahoo.com> Signed-off-by:
-
Antti Palosaari authored
Signed-off-by:
-
Antti Palosaari authored
TDA10071 firmware version 1.21.31.2 Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
Michael Krufky <mkrufky@kernellabs.com> Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Antti Palosaari authored
It is based of... * Empia EM28174 * NXP TDA10071 & Conexant CX24118A combo * Allegro A8293 Signed-off-by:
-
Antti Palosaari authored
NXP TDA10071 DVB-S/S2 demodulator & Conexant CX24118A tuner combo driver Signed-off-by:
-
Antti Palosaari authored
Signed-off-by:
-
Hans Verkuil authored
With the new flag there is no need anymore to have a separate is_volatile field. Modify all users to use the new flag. Signed-off-by:
-
Hans Verkuil authored
Add a new VOLATILE control flag that is set for volatile controls. That way applications know whether the value of the control is volatile (i.e. can change continuously) or not. Until now this was an internal property, but it is useful to know in userspace as well. A typical use case is the gain value when autogain is on. In that case the hardware will continuously adjust the gain based various environmental factors. This patch just adds and documents the flag, it's not yet used. Signed-off-by:
-
- 18 Sep, 2011 1 commit
-
-
Arvydas Sidorenko authored
checkpatch.pl gave some coding style errors, so on the way to the first patch I added the fix to them. Signed-off-by:
Arvydas Sidorenko <asido4@gmail.com> Signed-off-by:
-
