- 06 Jan, 2012 33 commits
-
-
Guennadi Liakhovetski authored
Cleanly separating register contexts A and B will allow us to configure the contexts independently. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Guennadi Liakhovetski authored
The "pixfmt" parameter of the struct soc_camera_host_ops::set_bus_param() method is redundant, because at the time, when this method is called, pixfmt is guaranteed to be equal to icd->current_fmt->host_fmt->fourcc. Remove this parameter and update all drivers accordingly. Signed-off-by:
-
Hans de Goede authored
Before this patch the resulting values from a try_fmt were different then those from a s_fmt with the same parameters. try_fmt simply did not touch / fill some values like bytesperline at all. This patch also corrects bytesperline to the proper value for a planar format such as the YUV420P format the pwc driver produces, which is the bytesperline value for the biggest plane, rather then those of all planes added together. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
Instead of making this a module parameter, automatically fallback to higher compression settings if there is not enough bandwidth. Signed-off-by:
-
Hans de Goede authored
The pwc driver claims to support any resolution between 160x120 and 640x480, but emulates this by simply drawing a black border around the image. Userspace can draw its own black border if it really wants one. Signed-off-by:
-
Hans de Goede authored
This stems from the v4l1 era, with v4l2 everything can be done with standardized v4l2 API calls. Signed-off-by:
-
Hans de Goede authored
The in kernel version of the pwc driver has never supported snapshot mode, and now that we no longer support the pixfmt.priv abuse there also no longer is a way for userspace to request it, rendering all the code in question dead (never called), so remove it. Signed-off-by:
-
Hans de Goede authored
The .priv field never was intended for this, setting a framerate is support using the standardized S_PARM ioctl. Signed-off-by:
-
Hans de Goede authored
Setting pan/tilt should be done with v4l2 controls, like with other cams. The button is available as a standard input device Signed-off-by:
-
Hans de Goede authored
So that events get generated for the new red + blue bal values when switching to a preset. This allows apps to solely rely on events instead of needing to do a query + g_ctrl on all controls when a control with the update flag set is gets set or gets an event. Signed-off-by:
-
Hans de Goede authored
While testing gtk-v4l's new ctrl event code, I hit the following deadlock in the pwc driver: Thread 1: -Does a VIDIOC_G_CTRL -video2_ioctl takes the modlock -video2_ioctl calls v4l2_g_ctrl -v4l2_g_ctrl takes the ctrl_handler lock -v4l2_g_ctrl calls pwc_g_volatile_ctrl -pwc_g_volatile_ctrl releases the modlock as the usb transfer can take a significant amount of time and we don't want to block DQBUF / QBUF too long Thread 2: -Does a VIDIOC_FOO_CTRL -video2_ioctl takes the modlock -video2_ioctl calls v4l2_foo_ctrl -v4l2_foo_ctrl blocks while trying to take the ctrl_handler lock Thread 1: -Blocks while trying to re-take the modlock, as its caller will eventually unlock that Now we have thread 1 waiting for the modlock while holding the ctrl_handler lock and thread 2 waiting for the ctrl_handler lock while holding the modlock -> deadlock. Conclusion: 1) We cannot unlock modlock from pwc_s_ctrl / pwc_g_volatile_ctrl, but this can cause QBUF / DQBUF to block for up to a full second 2) After evaluating various option I came to the conclusion that pwc should stop using the v4l2 core locking, and instead do its own locking Thus this patch stops pwc using the v4l2 core locking, and replaces that with it doing its own locking where necessary. Signed-off-by:
-
Hans de Goede authored
Currently auto white balance speed and delay are only available through custom ioctls, which are deprecated and will be going away in 3.3 . Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
This is a preperation patch for adding support for control events. Actually enabling support for control events will be done in a separate patch, as that depends on the necessary poll changes going upstream Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
Somehow the code has ended up assuming 1400 packets/sec which of course is wrong for usb1 devices like the ov511 cameras. usb1 only does 1000 (isoc) packets / sec. Signed-off-by:
-
Hans de Goede authored
Reported by: Grzegorz Woźniak Signed-off-by:
-
Hans de Goede authored
This got broken by some gscpa core fixes, this patch restores the proper min/max values for these controls. Signed-off-by:
-
Theodore Kilgore authored
Written by Theodore Kilgore With minor changes by Hans de Goede: -Code style fixes -Correct the verbose level on various PDEBUG messages -Make error messages use pr_err instead of PDEBUG -Document the jl20 pixel format Signed-off-by:
Theodore Kilgore <kilgota@auburn.edu> Signed-off-by:
-
Mauro Carvalho Chehab authored
* tag 'v3.2': (83 commits) Linux 3.2 minixfs: misplaced checks lead to dentry leak ptrace: ensure JOBCTL_STOP_SIGMASK is not zero after detach ptrace: partially fix the do_wait(WEXITED) vs EXIT_DEAD->EXIT_ZOMBIE race Revert "rtc: Expire alarms after the time is set." [CIFS] default ntlmv2 for cifs mount delayed to 3.3 cifs: fix bad buffer length check in coalesce_t2 Revert "rtc: Disable the alarm in the hardware" hung_task: fix false positive during vfork security: Fix security_old_inode_init_security() when CONFIG_SECURITY is not set fix CAN MAINTAINERS SCM tree type mwifiex: fix crash during simultaneous scan and connect b43: fix regression in PIO case ath9k: Fix kernel panic in AR2427 in AP mode CAN MAINTAINERS update net: fsl: fec: fix build for mx23-only kernel sch_qfq: fix overflow in qfq_update_start() drm/radeon/kms/atom: fix possible segfault in pm setup gspca: Fix falling back to lower isoc alt settings futex: Fix uninterruptible loop due to gate_area ...
-
Manjunath Hadli authored
This patch implements necessary changes for enabling dm365 and dm355 hardware for vpbe. The patch contains additional HD mode support for dm365 (720p60, 1080i30) and appropriate register modifications based on version numbers. VPBE_VERSION_2 = dm365 specific VPBE_VERSION_3 = dm355 specific Signed-off-by:
Manjunath Hadli <manjunath.hadli@ti.com> Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Manjunath Hadli authored
Add OSD block changes to enable dm365 and dm355 for vpbe driver. Changes are based on version number of OSD, which have incremental changes over 644x OSD hardware interms of few registers. VPBE_VERSION_2 = dm365 specific VPBE_VERSION_3 = dm355 specific Acked-by:
-
Manjunath Hadli authored
This patch implements the core additions to the display driver, mainly controlling the VENC and other encoders for dm365. This patch also includes addition of amplifier subdevice to the vpbe driver and interfacing with venc subdevice. Signed-off-by:
-
Hans de Goede authored
When using the SN9C20X_I420 fmt the sn9c20x needs more bandwidth than our regular bandwidth calculations reserve. This patch adds a sd_isoc_init function, which forces the use of a specific altsetting when using the SN9C20X_I420 fmt. This fixes the bottom 10-30% of the image getting corrupted when using the SN9C20X_I420 fmt (which is the default fmt). Signed-off-by:
Jean-François Moine <moinejf@free.fr> Signed-off-by:
-
Hans de Goede authored
Some cameras will pretty much entirely fill all the image buffers all the time even though they are using compression. This patch adds a flag to sd_desc, which drivers for such cameras can set. When this flag is set the bandwidth calculation code will no longer assume that the image buffer size is a worst case and less bandwidth than imagebufsize * fps will be used on average. This patch sets this new flag for 3 drivers: * For spca561 (for rev12a cameras) and nw80x cams as these simply don't work when given less bandwidth than imagebufsize * fps. * For sn9c20x cameras, because these show severy jpeg artifacts when given less bandwidth than imagebufsize * fps and since these are usb2 cameras there is plenty bandwidth anyways. Signed-off-by:
-
Hans de Goede authored
Quoting from the official usb 20 spec: "5.6.4 Isochronous Transfer Bus Access Constraints Isochronous transfers can only be used by full-speed and high-speed devices." This means that for code paths which are isoc mode only, we don't need to check for the device being low speed, simplifying the code. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
Check dev->actconfig rather than dev->config when checking various configuration things. dev->config points to the array of configs for the device so dev->config->foo boils down to dev->config[0].foo and the first config is not necessarily always the active config. Signed-off-by:
-
Hans de Goede authored
In case we ever get sub drivers which do 7.5 fps and express this as 15 / 2 fps. Signed-off-by:
-
Hans de Goede authored
The calculated bandwidth should not be multiplied by the interval, but be divided by it. Also bInterbval should be interpreted as a power of 2 for isochronous endpoints. Signed-off-by:
-
Hans de Goede authored
After the "gspca: Fix bulk mode cameras no longer working (regression fix)" patch build_ep_tb is no longer being called for bulk endpoints. This patch renames build_ep_tb to build_isoc_ep_tb to make clear it should only be called for isoc mode cameras. This patch also: - drops the no longer needed xfer parameter - removes a check for bulk mode from the build_isoc_ep_tb code Signed-off-by:
-
Jean-François Moine authored
Having: - a mean image size of 0.375 time the max compressed image size and - a frame rate of 30 fps for small images or with USB 2.0/3.0 seems more realistic and gives less image freezes. Signed-off-by:
-
Jose Alberto Reguero authored
This path add support to "OmniVision Technologies, Inc. VEHO Filmscanner". Signed-off-by:
Jose Alberto Reguero <jareguero@telefonica.net> Signed-off-by:
-
- 05 Jan, 2012 7 commits
-
-
Gareth Williams authored
Fix detection of EMP202 audio chip. Some versions have an id of 0x83847650 instead of 0xffffffff Honestech Vidbox NW03 has a EMP202 audio chip with a different Vendor ID. Apparently, it is the same with the Gadmei ITV380: http://linuxtv.org/wiki/index.php/Gadmei_USB_TVBox_UTV380Signed-off-by:
Gareth Williams <gareth@garethwilliams.me.uk> Signed-off-by:
-
Malcolm Priestley authored
Support for IT1935 9006 devices. 9006 have version 2 type chip. 9006 devices should use dvb-usb-it9135-02.fw firmware. On the device tested the tuner id was set to 0 which meant the driver used tuner id 0x38. The device functioned normally. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Instead of creating two DVB frontend entries for the same device, create just one entry, and fill the delivery_system according with the supported standards. Signed-off-by: -
Mauro Carvalho Chehab authored
ops.info.frequency_stepsize is used only for DVB-T & friends. For DVB-C, the step size is calculated using the symbol rate. Signed-off-by: -
Mauro Carvalho Chehab authored
While this patch change some things, the updated fields there are used just on printk, so it shouldn't cause any functional changes. Yet, this routine is a little complex, so explain a little more how it works. Signed-off-by: -
Mauro Carvalho Chehab authored
Instead of changing the ops.info.type struct, updates only the data that will be returned to userspace. Also add some debug messages to help tracking such issues. Signed-off-by:
-
