I just wondering how to set shutter or aperture value in uvc driver.
Hi Laurent, I try to add the more exposure methods of the M-5MOLS driver. Currently, the only 2 exposure type are available in the M-5MOLS driver - V4L2_EXPOSURE_AUTO, V4L2_EXPOSURE_MANUAL. But, the HW is capable to So, I found the only UVC driver looks like using extra enumerations V4L2_EXPOSURE_SHUTTER_PRIORITY, V4L2_EXPOSURE_APERTURE_PRIORITY. But, I don't know how to set the each value in the each mode. The way pointed the specific value is only one - V4L2_CID_EXPOSURE_ABSOLUTE. So, how can I set the specific value at the each mode? Regards, Heungjun Kim -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I just wondering how to set shutter or aperture value in uvc driver.
missing. sorry :) 2011-05-25 오후 3:49, Kim, HeungJun 쓴 글: Hi Laurent, I try to add the more exposure methods of the M-5MOLS driver. Currently, the only 2 exposure type are available in the M-5MOLS driver - V4L2_EXPOSURE_AUTO, V4L2_EXPOSURE_MANUAL. But, the HW is capable to the HW is capable to shutter, aperture exposure value, of course auto exposure. So, I found the only UVC driver looks like using extra enumerations V4L2_EXPOSURE_SHUTTER_PRIORITY, V4L2_EXPOSURE_APERTURE_PRIORITY. But, I don't know how to set the each value in the each mode. The way pointed the specific value is only one - V4L2_CID_EXPOSURE_ABSOLUTE. So, how can I set the specific value at the each mode? Regards, Heungjun Kim -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
build errors on kinect and rc-main - 2.6.38
Hello, I'm trying to build the media tree using the automatic script and end-up with at least two errors not allowing me to move forward positively. Ubuntu 11.04 x86_64 2.6.38-8-generic First one is on Kinect (don't need it, I can disable the build): CC [M] /home/nico/src/media_build/v4l/kinect.o /home/nico/src/media_build/v4l/kinect.c:38:19: error: 'D_ERR' undeclared here (not in a function) /home/nico/src/media_build/v4l/kinect.c:38:27: error: 'D_PROBE' undeclared here (not in a function) /home/nico/src/media_build/v4l/kinect.c:38:37: error: 'D_CONF' undeclared here (not in a function) /home/nico/src/media_build/v4l/kinect.c:38:46: error: 'D_STREAM' undeclared here (not in a function) /home/nico/src/media_build/v4l/kinect.c:38:57: error: 'D_FRAM' undeclared here (not in a function) /home/nico/src/media_build/v4l/kinect.c:38:66: error: 'D_PACK' undeclared here (not in a function) /home/nico/src/media_build/v4l/kinect.c:39:2: error: 'D_USBI' undeclared here (not in a function) /home/nico/src/media_build/v4l/kinect.c:39:11: error: 'D_USBO' undeclared here (not in a function) /home/nico/src/media_build/v4l/kinect.c:39:20: error: 'D_V4L2' undeclared here (not in a function) make[3]: *** [/home/nico/src/media_build/v4l/kinect.o] Error 1 make[2]: *** [_module_/home/nico/src/media_build/v4l] Error 2 The second one is on rc-main (I probably need that!): CC [M] /home/nico/src/media_build/v4l/rc-main.o /home/nico/src/media_build/v4l/rc-main.c: In function 'rc_allocate_device': /home/nico/src/media_build/v4l/rc-main.c:993:29: warning: assignment from incompatible pointer type /home/nico/src/media_build/v4l/rc-main.c:994:29: warning: assignment from incompatible pointer type CC [M] /home/nico/src/media_build/v4l/ir-raw.o CC [M] /home/nico/src/media_build/v4l/mipi-csis.o /home/nico/src/media_build/v4l/mipi-csis.c:29:28: fatal error: plat/mipi_csis.h: No such file or directory compilation terminated. Thanks for looking into it! Nico -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] MT9P031: Add support for Aptina mt9p031 sensor.
Please, do not remove anyone from the CC list. On 25 May 2011 05:45, Chris Rodley carlight...@yahoo.co.nz wrote: Hi, Have upgraded the driver to Javier's latest RFC driver. Still having problems viewing output. Setting up with: # media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] # media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' Setting up format SGRBG12 320x240 on pad mt9p031 2-0048/0 Format set: SGRB Setting up format SGRBG12 320x240 on pad OMAP3 ISP CCDC/0 Format set: SGRBG12 320x240 Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/0 Format set: SGRBG8 320x240 Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/1 Format set: SGRBG8 320x240 Then: # yavta -f SGRBG8 -s 320x240 -n 4 --capture=100 -F /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: width: 320 height: 240 buffer size: 76800 Video format: GRBG (47425247) 320x240 4 buffers requested. length: 76800 offset: 0 Buffer 0 mapped at address 0x4006c000. length: 76800 offset: 77824 Buffer 1 mapped at address 0x40222000. length: 76800 offset: 155648 Buffer 2 mapped at address 0x4025e000. length: 76800 offset: 233472 Buffer 3 mapped at address 0x402f. After this it hangs and will exit on 'ctrl c': omap3isp omap3isp: CCDC stop timeout! Any ideas what is causing this problem? No idea, it works for me. Note you have to apply RFC + PATCH v2 2/2. Please, double check. Also, if you have problems with last RFC patch you should answer RFC mail. Not this one. Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: build errors on kinect and rc-main - 2.6.38 (mipi-csis not rc-main)
On Wed, 2011-05-25 at 07:43 +0100, Nicolas WILL wrote: The second one is on rc-main (I probably need that!): CC [M] /home/nico/src/media_build/v4l/rc-main.o /home/nico/src/media_build/v4l/rc-main.c: In function 'rc_allocate_device': /home/nico/src/media_build/v4l/rc-main.c:993:29: warning: assignment from incompatible pointer type /home/nico/src/media_build/v4l/rc-main.c:994:29: warning: assignment from incompatible pointer type CC [M] /home/nico/src/media_build/v4l/ir-raw.o CC [M] /home/nico/src/media_build/v4l/mipi-csis.o /home/nico/src/media_build/v4l/mipi-csis.c:29:28: fatal error: plat/mipi_csis.h: No such file or directory compilation terminated. Oh, not rc-main, but mipi-csis! Sorry... Nico -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FW: OMAP 3 ISP
Hi Alex,
On Tuesday 24 May 2011 16:11:16 Alex Gershgorin wrote:
Hi All,
I wrote a simple V4L2 subdevs I2C driver which returns a fixed format and
size. I do not understand who reads these parameters, user application
through IOCTL or OMAP3 ISP driver uses them regardless of the user space
application?
Both. media-ctl (and other userspace applications) can use them, and the OMAP3
ISP driver retrieves them when starting the video stream to make sure that the
formats at the sensor output and at the CCDC input match.
Another question, if I need to change polarity of Vertical or Horizontal
synchronization signals, according struct isp_parallel_platform_data, is
it not possible?
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
unsigned int bridge:4;
};
Could you please try the following patch ?
From 7f8eff25e63880a93bc283cd97840227cd092622 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
Date: Wed, 25 May 2011 09:16:28 +0200
Subject: [PATCH] omap3isp: Support configurable HS/VS polarities
Add two fields to the ISP parallel platform data to set the HS and VS
signals polarities.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3isp/isp.h |6 ++
drivers/media/video/omap3isp/ispccdc.c |4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index 2620c40..529e582 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -139,6 +139,10 @@ struct isp_reg {
* 3 - CAMEXT[13:6] - CAM[7:0]
* @clk_pol: Pixel clock polarity
* 0 - Non Inverted, 1 - Inverted
+ * @hs_pol: Horizontal synchronization polarity
+ * 0 - Active high, 1 - Active low
+ * @vs_pol: Vertical synchronization polarity
+ * 0 - Active high, 1 - Active low
* @bridge: CCDC Bridge input control
* ISPCTRL_PAR_BRIDGE_DISABLE - Disable
* ISPCTRL_PAR_BRIDGE_LENDIAN - Little endian
@@ -147,6 +151,8 @@ struct isp_reg {
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
+ unsigned int hs_pol:1;
+ unsigned int vs_pol:1;
unsigned int bridge:4;
};
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index 39d501b..5e742b2 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -1148,6 +1148,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
omap3isp_configure_bridge(isp, ccdc-input, pdata, shift);
ccdc-syncif.datsz = depth_out;
+ ccdc-syncif.hdpol = pdata ? pdata- hs_pol : 0;
+ ccdc-syncif.vdpol = pdata ? pdata- vs_pol : 0;
ccdc_config_sync_if(ccdc, ccdc-syncif);
/* CCDC_PAD_SINK */
@@ -2257,8 +2259,6 @@ int omap3isp_ccdc_init(struct isp_device *isp)
ccdc-syncif.fldout = 0;
ccdc-syncif.fldpol = 0;
ccdc-syncif.fldstat = 0;
- ccdc-syncif.hdpol = 0;
- ccdc-syncif.vdpol = 0;
ccdc-clamp.oblen = 0;
ccdc-clamp.dcsubval = 0;
--
1.7.3.4
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] Add mt9p031 sensor support.
Hi Javier,
Thanks for the patch. Here's a review of the power handling code.
On Tuesday 24 May 2011 16:30:43 Javier Martin wrote:
This RFC includes a power management implementation that causes
the sensor to show images with horizontal artifacts (usually
monochrome lines that appear on the image randomly).
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
[snip]
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..04d8812
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
[snip]
@@ -0,0 +1,841 @@
+/*
+ * Driver for MT9P031 CMOS Image Sensor from Aptina
+ *
+ * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on the MT9V032 driver and Bastian Hecht's code.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/device.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include media/v4l2-subdev.h
+#include linux/videodev2.h
+
+#include media/mt9p031.h
+#include media/v4l2-chip-ident.h
This header is not needed anymore.
+#include media/v4l2-subdev.h
+#include media/v4l2-device.h
+
+#define MT9P031_PIXCLK_FREQ 5400
+
+/* mt9p031 selected register addresses */
+#define MT9P031_CHIP_VERSION 0x00
+#define MT9P031_CHIP_VERSION_VALUE 0x1801
+#define MT9P031_ROW_START0x01
+#define MT9P031_ROW_START_DEF 54
+#define MT9P031_COLUMN_START 0x02
+#define MT9P031_COLUMN_START_DEF16
+#define MT9P031_WINDOW_HEIGHT0x03
+#define MT9P031_WINDOW_WIDTH 0x04
+#define MT9P031_H_BLANKING 0x05
+#define MT9P031_H_BLANKING_VALUE0
+#define MT9P031_V_BLANKING 0x06
+#define MT9P031_V_BLANKING_VALUE25
+#define MT9P031_OUTPUT_CONTROL 0x07
+#define MT9P031_OUTPUT_CONTROL_CEN 2
+#define MT9P031_OUTPUT_CONTROL_SYN 1
+#define MT9P031_SHUTTER_WIDTH_UPPER 0x08
+#define MT9P031_SHUTTER_WIDTH0x09
+#define MT9P031_PIXEL_CLOCK_CONTROL 0x0a
+#define MT9P031_FRAME_RESTART0x0b
+#define MT9P031_SHUTTER_DELAY0x0c
+#define MT9P031_RST 0x0d
+#define MT9P031_RST_ENABLE 1
+#define MT9P031_RST_DISABLE 0
+#define MT9P031_READ_MODE_1 0x1e
+#define MT9P031_READ_MODE_2 0x20
+#define MT9P031_READ_MODE_2_ROW_MIR 0x8000
+#define MT9P031_READ_MODE_2_COL_MIR 0x4000
+#define MT9P031_ROW_ADDRESS_MODE 0x22
+#define MT9P031_COLUMN_ADDRESS_MODE 0x23
+#define MT9P031_GLOBAL_GAIN 0x35
+
+#define MT9P031_WINDOW_HEIGHT_MAX1944
+#define MT9P031_WINDOW_WIDTH_MAX 2592
+#define MT9P031_WINDOW_HEIGHT_MIN2
+#define MT9P031_WINDOW_WIDTH_MIN 18
Can you move those 4 constants right below MT9P031_WINDOW_HEIGHT and
MT9P031_WINDOW_WIDTH ? The max values are not correct, according to the
datasheet they should be 2005 and 2751. You can define *_DEF constants for the
default width and height.
+struct mt9p031 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_rect rect; /* Sensor window */
+ struct v4l2_mbus_framefmt format;
+ struct mt9p031_platform_data *pdata;
+ struct mutex power_lock; /* lock to protect power_count */
+ int power_count;
+ u16 xskip;
+ u16 yskip;
+ /* cache register values */
+ u16 output_control;
+ u16 h_blanking;
+ u16 v_blanking;
+ u16 column_address_mode;
+ u16 row_address_mode;
+ u16 column_start;
+ u16 row_start;
+ u16 window_width;
+ u16 window_height;
+ struct regulator *reg_1v8;
+ struct regulator *reg_2v8;
+};
[snip]
+static int restore_registers(struct i2c_client *client)
+{
+ int ret;
+ struct mt9p031 *mt9p031 = to_mt9p031(client);
+
+ /* Disable register update, reconfigure atomically */
+ ret = mt9p031_set_output_control(mt9p031, 0,
+ MT9P031_OUTPUT_CONTROL_SYN);
+ if (ret 0)
+ return ret;
+
+ /* Blanking and start values - default... */
+ ret = reg_write(client, MT9P031_H_BLANKING, mt9p031-h_blanking);
+ if (ret 0)
+ return ret;
+
+ ret = reg_write(client, MT9P031_V_BLANKING,
[PATCH] s5p-csis: Add missing dependency on PLAT_S5P
s5p-csis is to be built only on S5P SoC platforms. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com --- Hi Nicolas, On x86 mipi-csis build should be disabled. This patch should the issue. Regards, Sylwester Nawrocki Samsung Poland RD Center --- drivers/media/video/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index cf5a1f6..bd739a6 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -954,7 +954,7 @@ config VIDEO_SAMSUNG_S5P_FIMC config VIDEO_S5P_MIPI_CSIS tristate Samsung S5P and EXYNOS4 MIPI CSI receiver driver - depends on VIDEO_V4L2 PM_RUNTIME VIDEO_V4L2_SUBDEV_API + depends on VIDEO_V4L2 PM_RUNTIME PLAT_S5P VIDEO_V4L2_SUBDEV_API PLAT_S5P ---help--- This is a v4l2 driver for Samsung S5P/EXYNOS4 MIPI-CSI receiver. -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: isp: fix compiler warning
Hi Sanjeev, On Monday 23 May 2011 20:09:58 Premi, Sanjeev wrote: On Monday, May 23, 2011 12:56 AM Laurent Pinchart wrote: On Saturday 21 May 2011 12:55:32 Mauro Carvalho Chehab wrote: Em 18-05-2011 13:06, Sanjeev Premi escreveu: [snip] @@ -387,7 +387,7 @@ static inline void isp_isr_dbg(struct isp_device *isp, u32 irqstatus) }; int i; - dev_dbg(isp-dev, ); + printk(KERN_DEBUG %s:\n, dev_driver_string(isp-dev)); The original code doesn't include any \n. Is there a particular reason why you want to add one ? [sp] Sorry, that's a mistake out of habit. Another way to fix warning would be to make the string meaningful: - dev_dbg(isp-dev, ); + dev_dbg (isp-dev, ISP_IRQ:); Is this better? That looks good to me. I'll queue your patch in my tree (with a space after the colon). Thanks. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.40] Fixes
On Tuesday, May 24, 2011 08:28:32 Hans Verkuil wrote: On Tuesday, May 24, 2011 03:42:32 Mauro Carvalho Chehab wrote: Em 23-05-2011 08:06, Hans Verkuil escreveu: Hi Mauro, Here are a few fixes: the first fixes a bug in the wl12xx drivers (I hope Matti's email is still correct). The second fixes a few DocBook validation errors, and the last fixes READ_ONLY and GRABBED handling in the control framework. Regards, Hans The following changes since commit 87cf028f3aa1ed51fe29c36df548aa714dc7438f: [media] dm1105: GPIO handling added, I2C on GPIO added, LNB control through GPIO reworked (2011-05-21 11:10:28 -0300) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git fixes Hans Verkuil (3): wl12xx: g_volatile_ctrl fix: wrong field set. Media DocBook: fix validation errors. The two above are fixes... v4l2-ctrls: drivers should be able to ignore READ_ONLY and GRABBED flags But this one is a change at the behaviour. I need to analyse it better. The idea of a read only control that it is not read only seems too weird on my tired eyes. It's read-only for *applications*. But if you have a read-only control that reflects a driver state, then it should be possible for a *driver* to change it. It's something that is needed for the upcoming Flash and HDMI APIs. The userspace behavior does not change. BTW, if you prefer to move this last patch to 2.6.41, then that's OK by me. It's not really necessary for 2.6.40. I'm going to move this patch to 2.6.41, so there is no need for you to review this. I'll include it in another patch series I'm working on. Regards, Hans Regards, Hans I'll take a more careful look on it tomorrow. Thanks, Mauro. Documentation/DocBook/dvb/dvbproperty.xml|5 ++- Documentation/DocBook/v4l/subdev-formats.xml | 10 ++-- drivers/media/radio/radio-wl1273.c |2 +- drivers/media/radio/wl128x/fmdrv_v4l2.c |2 +- drivers/media/video/v4l2-ctrls.c | 59 +- 5 files changed, 50 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] s5p-csis: Add missing dependency on PLAT_S5P
s5p-csis is to be built only on S5P SoC platforms. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com --- Resending, as the previous patch had PLAT_S5P added twice.. --- drivers/media/video/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index cf5a1f6..bb53de7 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -954,7 +954,7 @@ config VIDEO_SAMSUNG_S5P_FIMC config VIDEO_S5P_MIPI_CSIS tristate Samsung S5P and EXYNOS4 MIPI CSI receiver driver - depends on VIDEO_V4L2 PM_RUNTIME VIDEO_V4L2_SUBDEV_API + depends on VIDEO_V4L2 PM_RUNTIME PLAT_S5P VIDEO_V4L2_SUBDEV_API ---help--- This is a v4l2 driver for Samsung S5P/EXYNOS4 MIPI-CSI receiver. -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Fix the derot zig-zag to work with TT-USB2.0 TechnoTrend
(The initial patch cause too long tune delay on non-present carriers. Use the
hardware derot, by writing zero to the derot register.)
From 2b960abaeeaa32f6bcaa350ca80906c467ab9cb1 Mon Sep 17 00:00:00 2001
From: Hans Petter Selasky hsela...@c2i.net
Date: Tue, 24 May 2011 21:44:53 +0200
Subject: [PATCH] Fix the derot zig-zag to work with TT-USB2.0 TechnoTrend
hardware.
Signed-off-by: Hans Petter Selasky hsela...@c2i.net
---
drivers/media/dvb/frontends/stb0899_algo.c | 130
drivers/media/dvb/frontends/stb0899_priv.h |2 -
2 files changed, 36 insertions(+), 96 deletions(-)
diff --git a/drivers/media/dvb/frontends/stb0899_algo.c
b/drivers/media/dvb/frontends/stb0899_algo.c
index d70eee0..0cdaac2 100644
--- a/drivers/media/dvb/frontends/stb0899_algo.c
+++ b/drivers/media/dvb/frontends/stb0899_algo.c
@@ -117,7 +117,7 @@ static u32 stb0899_set_srate(struct stb0899_state *state,
u32 master_clk, u32 sr
*/
static long stb0899_calc_derot_time(long srate)
{
- if (srate 0)
+ if (srate 999)
return (10 / (srate / 1000));
else
return 0;
@@ -207,36 +207,23 @@ static enum stb0899_status stb0899_search_tmg(struct
stb0899_state *state)
{
struct stb0899_internal *internal = state-internal;
struct stb0899_params *params = state-params;
-
- short int derot_step, derot_freq = 0, derot_limit, next_loop = 3;
- int index = 0;
- u8 cfr[2];
+ int index;
+ u8 cfr[2] = {0,0};
internal-status = NOTIMING;
- /* timing loop computation symbol rate optimisation */
- derot_limit = (internal-sub_range / 2L) / internal-mclk;
- derot_step = (params-srate / 2L) / internal-mclk;
-
- while ((stb0899_check_tmg(state) != TIMINGOK) next_loop) {
- index++;
- derot_freq += index * internal-direction * derot_step; /* next
derot zig zag position */
+ /* let the hardware figure out derot frequency */
+ stb0899_write_regs(state, STB0899_CFRM, cfr, 2); /* derotator frequency
*/
- if (abs(derot_freq) derot_limit)
- next_loop--;
-
- if (next_loop) {
- STB0899_SETFIELD_VAL(CFRM, cfr[0],
MSB(state-config-inversion *
derot_freq));
- STB0899_SETFIELD_VAL(CFRL, cfr[1],
LSB(state-config-inversion *
derot_freq));
- stb0899_write_regs(state, STB0899_CFRM, cfr, 2); /*
derotator
frequency */
+ for (index = 0; index 8; index++) {
+ if (stb0899_check_tmg(state) == TIMINGOK) {
+ /* get derotator frequency */
+ stb0899_read_regs(state, STB0899_CFRM, cfr, 2);
+ internal-derot_freq = state-config-inversion *
MAKEWORD16(cfr[0], cfr[1]);
+ dprintk(state-verbose, FE_DEBUG, 1, ---TIMING OK
!
+ Derot Freq = %d, internal-derot_freq);
+ break;
}
- internal-direction = -internal-direction; /* Change
zigzag direction
*/
- }
-
- if (internal-status == TIMINGOK) {
- stb0899_read_regs(state, STB0899_CFRM, cfr, 2); /* get
derotator
frequency */
- internal-derot_freq = state-config-inversion *
MAKEWORD16(cfr[0],
cfr[1]);
- dprintk(state-verbose, FE_DEBUG, 1, ---TIMING OK ! Derot
Freq =
%d, internal-derot_freq);
}
return internal-status;
@@ -277,50 +264,25 @@ static enum stb0899_status stb0899_check_carrier(struct
stb0899_state *state)
static enum stb0899_status stb0899_search_carrier(struct stb0899_state
*state)
{
struct stb0899_internal *internal = state-internal;
-
- short int derot_freq = 0, last_derot_freq = 0, derot_limit, next_loop =
3;
- int index = 0;
+ int index;
u8 cfr[2];
u8 reg;
internal-status = NOCARRIER;
- derot_limit = (internal-sub_range / 2L) / internal-mclk;
- derot_freq = internal-derot_freq;
reg = stb0899_read_reg(state, STB0899_CFD);
STB0899_SETFIELD_VAL(CFD_ON, reg, 1);
stb0899_write_reg(state, STB0899_CFD, reg);
- do {
- dprintk(state-verbose, FE_DEBUG, 1, Derot Freq=%d, mclk=%d,
derot_freq, internal-mclk);
- if (stb0899_check_carrier(state) == NOCARRIER) {
- index++;
- last_derot_freq = derot_freq;
- derot_freq += index * internal-direction *
internal-derot_step;
/* next zig zag derotator position */
-
- if(abs(derot_freq) derot_limit)
- next_loop--;
-
- if (next_loop) {
- reg = stb0899_read_reg(state, STB0899_CFD);
- STB0899_SETFIELD_VAL(CFD_ON, reg, 1);
-
[PATCH] ivtv: use display information in info not in var for panning
We must not use any information in the passed var besides xoffset, yoffset and vmode as otherwise applications might abuse it. Also use the aligned fix.line_length and not the (possible) unaligned xres_virtual. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Andy Walls awa...@md.metrocast.net --- drivers/media/video/ivtv/ivtvfb.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) Andy, This patch hasn't been tested as I don't have access to ivtv hardware. Can you push it through your tree if it works for you ? You could CC sta...@kernel.org as well. diff --git a/drivers/media/video/ivtv/ivtvfb.c b/drivers/media/video/ivtv/ivtvfb.c index 1724745..2d5a974 100644 --- a/drivers/media/video/ivtv/ivtvfb.c +++ b/drivers/media/video/ivtv/ivtvfb.c @@ -836,7 +836,8 @@ static int ivtvfb_pan_display(struct fb_var_screeninfo *var, struct fb_info *inf u32 osd_pan_index; struct ivtv *itv = (struct ivtv *) info-par; - osd_pan_index = (var-xoffset + (var-yoffset * var-xres_virtual))*var-bits_per_pixel/8; + osd_pan_index = var-yoffset * info-fix.line_length + + var-xoffset * info-var.bits_per_pixel / 8; write_reg(osd_pan_index, 0x02A0C); /* Pass this info back the yuv handler */ -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] Add mt9p031 sensor support.
Hi, thank you for the review, I agree with you on all the suggested changes except on this one: On 25 May 2011 10:05, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, Thanks for the patch. Here's a review of the power handling code. On Tuesday 24 May 2011 16:30:43 Javier Martin wrote: This RFC includes a power management implementation that causes the sensor to show images with horizontal artifacts (usually monochrome lines that appear on the image randomly). Signed-off-by: Javier Martin javier.mar...@vista-silicon.com [snip] diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..04d8812 --- /dev/null +++ b/drivers/media/video/mt9p031.c [snip] +#define MT9P031_WINDOW_HEIGHT_MAX 1944 +#define MT9P031_WINDOW_WIDTH_MAX 2592 +#define MT9P031_WINDOW_HEIGHT_MIN 2 +#define MT9P031_WINDOW_WIDTH_MIN 18 Can you move those 4 constants right below MT9P031_WINDOW_HEIGHT and MT9P031_WINDOW_WIDTH ? The max values are not correct, according to the datasheet they should be 2005 and 2751. In figure 4, it says active image size is 2592 x 1944 Why should I include active boundary and dark pixels? -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] Add mt9p031 sensor support.
Hi Javier, On Wednesday 25 May 2011 11:41:42 javier Martin wrote: Hi, thank you for the review, I agree with you on all the suggested changes except on this one: On 25 May 2011 10:05, Laurent Pinchart wrote: On Tuesday 24 May 2011 16:30:43 Javier Martin wrote: This RFC includes a power management implementation that causes the sensor to show images with horizontal artifacts (usually monochrome lines that appear on the image randomly). Signed-off-by: Javier Martin javier.mar...@vista-silicon.com [snip] diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..04d8812 --- /dev/null +++ b/drivers/media/video/mt9p031.c [snip] +#define MT9P031_WINDOW_HEIGHT_MAX1944 +#define MT9P031_WINDOW_WIDTH_MAX 2592 +#define MT9P031_WINDOW_HEIGHT_MIN2 +#define MT9P031_WINDOW_WIDTH_MIN 18 Can you move those 4 constants right below MT9P031_WINDOW_HEIGHT and MT9P031_WINDOW_WIDTH ? The max values are not correct, according to the datasheet they should be 2005 and 2751. In figure 4, it says active image size is 2592 x 1944 Why should I include active boundary and dark pixels? Users might want to get the dark pixels for black level compensation purpose. As the chip allows for that, it should be supported. The default should of course be the active area of 2592 x 1944 pixels. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
v4l2_mbus_framefmt and v4l2_pix_format
Hi Hans and Laurent, I got fmt info from a video data source subdev, I thought there should be a helper function to convert these two format enums. However, v4l2_fill_pix_format didn't do this, why? Should I do this in bridge driver one by one? I think these codes are common use, I prefer adding them in v4l2_fill_pix_format. Thanks, Scott -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: FW: OMAP 3 ISP
Hi Laurent,
Unfortunately, at this point I have no Hardware platforms, but in the
next week we should get Zoom OMAP35 Torpedo evaluation kit
and then I can test it.
I have already applied this patch on the last main line
Kernel version (2.6.39) and continue to work on the platform device for Zoom
OMAP35xx Torpedo.
Thanks for this patch :-)
Regards,
Alex Gershgorin
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Wednesday, May 25, 2011 10:22 AM
To: Alex Gershgorin
Cc: 'Sakari Ailus'; Michael Jones; 'linux-media@vger.kernel.org';
'age...@rambler.ru'
Subject: Re: FW: OMAP 3 ISP
Hi Alex,
On Tuesday 24 May 2011 16:11:16 Alex Gershgorin wrote:
Hi All,
I wrote a simple V4L2 subdevs I2C driver which returns a fixed format and
size. I do not understand who reads these parameters, user application
through IOCTL or OMAP3 ISP driver uses them regardless of the user space
application?
Both. media-ctl (and other userspace applications) can use them, and the OMAP3
ISP driver retrieves them when starting the video stream to make sure that the
formats at the sensor output and at the CCDC input match.
Another question, if I need to change polarity of Vertical or Horizontal
synchronization signals, according struct isp_parallel_platform_data, is
it not possible?
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
unsigned int bridge:4;
};
Could you please try the following patch ?
From 7f8eff25e63880a93bc283cd97840227cd092622 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
Date: Wed, 25 May 2011 09:16:28 +0200
Subject: [PATCH] omap3isp: Support configurable HS/VS polarities
Add two fields to the ISP parallel platform data to set the HS and VS
signals polarities.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3isp/isp.h |6 ++
drivers/media/video/omap3isp/ispccdc.c |4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index 2620c40..529e582 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -139,6 +139,10 @@ struct isp_reg {
* 3 - CAMEXT[13:6] - CAM[7:0]
* @clk_pol: Pixel clock polarity
* 0 - Non Inverted, 1 - Inverted
+ * @hs_pol: Horizontal synchronization polarity
+ * 0 - Active high, 1 - Active low
+ * @vs_pol: Vertical synchronization polarity
+ * 0 - Active high, 1 - Active low
* @bridge: CCDC Bridge input control
* ISPCTRL_PAR_BRIDGE_DISABLE - Disable
* ISPCTRL_PAR_BRIDGE_LENDIAN - Little endian
@@ -147,6 +151,8 @@ struct isp_reg {
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
+ unsigned int hs_pol:1;
+ unsigned int vs_pol:1;
unsigned int bridge:4;
};
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index 39d501b..5e742b2 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -1148,6 +1148,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
omap3isp_configure_bridge(isp, ccdc-input, pdata, shift);
ccdc-syncif.datsz = depth_out;
+ ccdc-syncif.hdpol = pdata ? pdata- hs_pol : 0;
+ ccdc-syncif.vdpol = pdata ? pdata- vs_pol : 0;
ccdc_config_sync_if(ccdc, ccdc-syncif);
/* CCDC_PAD_SINK */
@@ -2257,8 +2259,6 @@ int omap3isp_ccdc_init(struct isp_device *isp)
ccdc-syncif.fldout = 0;
ccdc-syncif.fldpol = 0;
ccdc-syncif.fldstat = 0;
- ccdc-syncif.hdpol = 0;
- ccdc-syncif.vdpol = 0;
ccdc-clamp.oblen = 0;
ccdc-clamp.dcsubval = 0;
--
1.7.3.4
--
Regards,
Laurent Pinchart
__ Information from ESET NOD32 Antivirus, version of virus signature
database 6149 (20110524) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__ Information from ESET NOD32 Antivirus, version of virus signature
database 6149 (20110524) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FW: OMAP 3 ISP
Hi Alex, On Wednesday 25 May 2011 11:58:58 Alex Gershgorin wrote: Hi Laurent, Unfortunately, at this point I have no Hardware platforms, but in the next week we should get Zoom OMAP35 Torpedo evaluation kit and then I can test it. I have already applied this patch on the last main line Kernel version (2.6.39) and continue to work on the platform device for Zoom OMAP35xx Torpedo. Thanks for this patch :-) You're welcome. Please let me know if it works for you when you'll receive the hardware. I will then push the patch to mainline. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l2_mbus_framefmt and v4l2_pix_format
On Wednesday, May 25, 2011 11:56:23 Scott Jiang wrote: Hi Hans and Laurent, I got fmt info from a video data source subdev, I thought there should be a helper function to convert these two format enums. However, v4l2_fill_pix_format didn't do this, why? Should I do this in bridge driver one by one? I think these codes are common use, I prefer adding them in v4l2_fill_pix_format. Only the bridge driver knows how these two enums relate. The mediabus enum as used by subdevs describes the format of the video data as is transferred over the physical bus between the subdev and the bridge. The V4L2_PIX_FMT* formats describe what the video data looks like in memory. Depending on the DMA engine those may or may not have a simple one on one mapping. In other words, it is indeed the bridge driver that has to do the mapping. That said, soc_camera has such a mapping. If it turns out that it can be reused elsewhere for certain bridges, then that code should probably be made a generic helper function. (See soc_mediabus.c/h) Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l2_mbus_framefmt and v4l2_pix_format
Hi Scott On Wed, 25 May 2011, Scott Jiang wrote: Hi Hans and Laurent, I got fmt info from a video data source subdev, I thought there should be a helper function to convert these two format enums. However, v4l2_fill_pix_format didn't do this, why? Should I do this in bridge driver one by one? Because various camera hosts (bridges) can produce different pixel formats in memory from the same mediabus code. However, there is a very common way to handle such video data in the bridge: store it in RAM in a natural way. This mode is called in soc-camera the pass-through mode and there is an API to handle this mode in drivers/media/video/soc_mediabus.c. If this functionality is considered useful also outside of soc-camera, that API can easily be made generic. I think these codes are common use, I prefer adding them in v4l2_fill_pix_format. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: FW: OMAP 3 ISP
Of course, in any case, you'll be the first who will know the results :-) Regards, Alex Gershgorin -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Wednesday, May 25, 2011 1:02 PM To: Alex Gershgorin Cc: 'Sakari Ailus'; Michael Jones; 'linux-media@vger.kernel.org'; 'age...@rambler.ru' Subject: Re: FW: OMAP 3 ISP Hi Alex, On Wednesday 25 May 2011 11:58:58 Alex Gershgorin wrote: Hi Laurent, Unfortunately, at this point I have no Hardware platforms, but in the next week we should get Zoom OMAP35 Torpedo evaluation kit and then I can test it. I have already applied this patch on the last main line Kernel version (2.6.39) and continue to work on the platform device for Zoom OMAP35xx Torpedo. Thanks for this patch :-) You're welcome. Please let me know if it works for you when you'll receive the hardware. I will then push the patch to mainline. -- Regards, Laurent Pinchart __ Information from ESET NOD32 Antivirus, version of virus signature database 6149 (20110524) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6150 (20110525) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Second RFC version of mt9p031 sensor with power managament.
It includes several fixes pointed out by Laurent Pinchart. However,
the BUG which shows artifacts in the image (horizontal lines) still
persists. It won't happen if 1v8 regulator is not disabled (i.e.
comment line where it is disabled in function mt9p031_power_off).
I know there can be some other details to fix but I would like someone
could help in the power management issue.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile |1 +
drivers/media/video/mt9p031.c | 752 +
include/media/mt9p031.h | 11 +
4 files changed, 771 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9p031.c
create mode 100644 include/media/mt9p031.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 00f51dd..8a596cc 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -329,6 +329,13 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_MT9P031
+ tristate Aptina MT9P031 support
+ depends on I2C VIDEO_V4L2
+ ---help---
+This is a Video4Linux2 sensor-level driver for the Aptina
+(Micron) mt9p031 5 Mpixel camera.
+
config VIDEO_MT9V011
tristate Micron mt9v011 sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..912b29b 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..39579de
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
@@ -0,0 +1,752 @@
+/*
+ * Driver for MT9P031 CMOS Image Sensor from Aptina
+ *
+ * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on the MT9V032 driver and Bastian Hecht's code.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/device.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include media/v4l2-subdev.h
+#include linux/videodev2.h
+
+#include media/mt9p031.h
+#include media/v4l2-subdev.h
+#include media/v4l2-device.h
+
+#define MT9P031_PIXCLK_FREQ5400
+
+/* mt9p031 selected register addresses */
+#define MT9P031_CHIP_VERSION 0x00
+#defineMT9P031_CHIP_VERSION_VALUE 0x1801
+#define MT9P031_ROW_START 0x01
+#defineMT9P031_ROW_START_DEF 54
+#define MT9P031_COLUMN_START 0x02
+#defineMT9P031_COLUMN_START_DEF16
+#define MT9P031_WINDOW_HEIGHT 0x03
+#defineMT9P031_WINDOW_HEIGHT_MAX 1944
+#defineMT9P031_WINDOW_HEIGHT_MIN 2
+#define MT9P031_WINDOW_WIDTH 0x04
+#defineMT9P031_WINDOW_WIDTH_MAX2592
+#defineMT9P031_WINDOW_WIDTH_MIN18
+#define MT9P031_H_BLANKING 0x05
+#defineMT9P031_H_BLANKING_VALUE0
+#define MT9P031_V_BLANKING 0x06
+#defineMT9P031_V_BLANKING_VALUE25
+#define MT9P031_OUTPUT_CONTROL 0x07
+#defineMT9P031_OUTPUT_CONTROL_CEN 2
+#defineMT9P031_OUTPUT_CONTROL_SYN 1
+#define MT9P031_SHUTTER_WIDTH_UPPER0x08
+#define MT9P031_SHUTTER_WIDTH 0x09
+#define MT9P031_PIXEL_CLOCK_CONTROL0x0a
+#define MT9P031_FRAME_RESTART 0x0b
+#define MT9P031_SHUTTER_DELAY 0x0c
+#define MT9P031_RST0x0d
+#defineMT9P031_RST_ENABLE 1
+#defineMT9P031_RST_DISABLE 0
+#define MT9P031_READ_MODE_10x1e
+#define MT9P031_READ_MODE_20x20
+#defineMT9P031_READ_MODE_2_ROW_MIR 0x8000
+#defineMT9P031_READ_MODE_2_COL_MIR 0x4000
+#define MT9P031_ROW_ADDRESS_MODE 0x22
+#define MT9P031_COLUMN_ADDRESS_MODE0x23
+#define MT9P031_GLOBAL_GAIN0x35
+
+struct mt9p031 {
+ struct v4l2_subdev subdev;
+
Re: I just wondering how to set shutter or aperture value in uvc driver.
Hi Heungjun, On Wednesday 25 May 2011 08:49:31 Kim, HeungJun wrote: Hi Laurent, I try to add the more exposure methods of the M-5MOLS driver. Currently, the only 2 exposure type are available in the M-5MOLS driver - V4L2_EXPOSURE_AUTO, V4L2_EXPOSURE_MANUAL. But, the HW is capable to shutter, aperture exposure value, of course auto exposure. So, I found the only UVC driver looks like using extra enumerations V4L2_EXPOSURE_SHUTTER_PRIORITY, V4L2_EXPOSURE_APERTURE_PRIORITY. But, I don't know how to set the each value in the each mode. The way pointed the specific value is only one - V4L2_CID_EXPOSURE_ABSOLUTE. So, how can I set the specific value at the each mode? You can control the aperture using the V4L2_CID_IRIS_ABSOLUTE control. See http://linuxtv.org/downloads/v4l-dvb-apis/extended-controls.html#camera- controls for more information regarding the exposure and iris controls. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I just wondering how to set shutter or aperture value in uvc driver.
Hi Laurent, 2011-05-25 오후 8:17, Laurent Pinchart 쓴 글: Hi Heungjun, On Wednesday 25 May 2011 08:49:31 Kim, HeungJun wrote: Hi Laurent, I try to add the more exposure methods of the M-5MOLS driver. Currently, the only 2 exposure type are available in the M-5MOLS driver - V4L2_EXPOSURE_AUTO, V4L2_EXPOSURE_MANUAL. But, the HW is capable to shutter, aperture exposure value, of course auto exposure. So, I found the only UVC driver looks like using extra enumerations V4L2_EXPOSURE_SHUTTER_PRIORITY, V4L2_EXPOSURE_APERTURE_PRIORITY. But, I don't know how to set the each value in the each mode. The way pointed the specific value is only one - V4L2_CID_EXPOSURE_ABSOLUTE. So, how can I set the specific value at the each mode? You can control the aperture using the V4L2_CID_IRIS_ABSOLUTE control. See http://linuxtv.org/downloads/v4l-dvb-apis/extended-controls.html#camera- controls for more information regarding the exposure and iris controls. Thanks for response, and I could understand this! Sorry for pre-checking documents. :) Regards, Heungjun Kim -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l2_mbus_framefmt and v4l2_pix_format
Hi Guennadi, On 05/25/2011 12:11 PM, Guennadi Liakhovetski wrote: Hi Scott On Wed, 25 May 2011, Scott Jiang wrote: Hi Hans and Laurent, I got fmt info from a video data source subdev, I thought there should be a helper function to convert these two format enums. However, v4l2_fill_pix_format didn't do this, why? Should I do this in bridge driver one by one? Because various camera hosts (bridges) can produce different pixel formats in memory from the same mediabus code. However, there is a very common way to handle such video data in the bridge: store it in RAM in a natural way. This mode is called in soc-camera the pass-through mode and there is an API to handle this mode in drivers/media/video/soc_mediabus.c. If this Sorry about getting off the topic a bit. As some media bus formats require different conversion process in the bridge to obtain specific format in memory (fourcc) I was wondering whether it would be reasonable to indicate the natural fourccs for the applications when enumerating formats supported by the bridge/DMA with VIDIOC_ENUM_FMT? So applications are aware what are the natural formats and which require lossy conversion. And in this way could choose formats that yield better quality. Now there are following flags available for struct v4l2_fmtdesc::flags V4L2_FMT_FLAG_COMPRESSED V4L2_FMT_FLAG_EMULATED I thought about something like V4L2_FMT_HW_EMULATED or V4L2_FMT_FLAG_LOW_QUALITY. I not happy with those exact names but I hope that gives a basic idea what I am talking about. Possibly I am missing other ways to achieve the same. Regards, -- Sylwester Nawrocki Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l2_mbus_framefmt and v4l2_pix_format
On Wed, 25 May 2011, Sylwester Nawrocki wrote: Hi Guennadi, On 05/25/2011 12:11 PM, Guennadi Liakhovetski wrote: Hi Scott On Wed, 25 May 2011, Scott Jiang wrote: Hi Hans and Laurent, I got fmt info from a video data source subdev, I thought there should be a helper function to convert these two format enums. However, v4l2_fill_pix_format didn't do this, why? Should I do this in bridge driver one by one? Because various camera hosts (bridges) can produce different pixel formats in memory from the same mediabus code. However, there is a very common way to handle such video data in the bridge: store it in RAM in a natural way. This mode is called in soc-camera the pass-through mode and there is an API to handle this mode in drivers/media/video/soc_mediabus.c. If this Sorry about getting off the topic a bit. As some media bus formats require different conversion process in the bridge to obtain specific format in memory (fourcc) I was wondering whether it would be reasonable to indicate the natural fourccs for the applications when enumerating formats supported by the bridge/DMA with VIDIOC_ENUM_FMT? So applications are aware what are the natural formats and which require lossy conversion. And in this way could choose formats that yield better quality. Yes, in principle this seems like a good idea to me. Of course, somebody will have to teach the user-space to use this information:) Now there are following flags available for struct v4l2_fmtdesc::flags V4L2_FMT_FLAG_COMPRESSED V4L2_FMT_FLAG_EMULATED I thought about something like V4L2_FMT_HW_EMULATED or V4L2_FMT_FLAG_LOW_QUALITY. I not happy with those exact names but I hope that gives a basic idea what I am talking about. Possibly I am missing other ways to achieve the same. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v19 5/6] davinci vpbe: Build infrastructure for VPBE driver
This patch adds the build infra-structure for Davinci VPBE dislay driver. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Acked-by: Muralidharan Karicheri m-kariche...@ti.com Acked-by: Hans Verkuil hverk...@xs4all.nl --- drivers/media/video/davinci/Kconfig | 23 +++ drivers/media/video/davinci/Makefile |2 ++ 2 files changed, 25 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 6b19540..60a456e 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -91,3 +91,26 @@ config VIDEO_ISIF To compile this driver as a module, choose M here: the module will be called vpfe. + +config VIDEO_DM644X_VPBE + tristate DM644X VPBE HW module + depends on ARCH_DAVINCI_DM644x + select VIDEO_VPSS_SYSTEM + select VIDEOBUF_DMA_CONTIG + help + Enables VPBE modules used for display on a DM644x + SoC. + + To compile this driver as a module, choose M here: the + module will be called vpbe. + + +config VIDEO_VPBE_DISPLAY + tristate VPBE V4L2 Display driver + depends on ARCH_DAVINCI_DM644x + select VIDEO_DM644X_VPBE + help + Enables VPBE V4L2 Display driver on a DM644x device + + To compile this driver as a module, choose M here: the + module will be called vpbe_display. diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index a379557..ae7dafb 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -16,3 +16,5 @@ obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o obj-$(CONFIG_VIDEO_ISIF) += isif.o +obj-$(CONFIG_VIDEO_DM644X_VPBE) += vpbe.o vpbe_osd.o vpbe_venc.o +obj-$(CONFIG_VIDEO_VPBE_DISPLAY) += vpbe_display.o -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v19 0/6] davinci vpbe: dm6446 v4l2 driver
fixed a wrong file inclusion in one of the patches Manjunath Hadli (6): davinci vpbe: V4L2 display driver for DM644X SoC davinci vpbe: VPBE display driver davinci vpbe: OSD(On Screen Display) block davinci vpbe: VENC( Video Encoder) implementation davinci vpbe: Build infrastructure for VPBE driver davinci vpbe: Readme text for Dm6446 vpbe Documentation/video4linux/README.davinci-vpbe | 93 ++ drivers/media/video/davinci/Kconfig | 23 + drivers/media/video/davinci/Makefile |2 + drivers/media/video/davinci/vpbe.c| 864 drivers/media/video/davinci/vpbe_display.c| 1860 + drivers/media/video/davinci/vpbe_osd.c| 1231 drivers/media/video/davinci/vpbe_osd_regs.h | 364 + drivers/media/video/davinci/vpbe_venc.c | 566 drivers/media/video/davinci/vpbe_venc_regs.h | 177 +++ include/media/davinci/vpbe.h | 184 +++ include/media/davinci/vpbe_display.h | 147 ++ include/media/davinci/vpbe_osd.h | 394 ++ include/media/davinci/vpbe_types.h| 91 ++ include/media/davinci/vpbe_venc.h | 45 + 14 files changed, 6041 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe create mode 100644 drivers/media/video/davinci/vpbe.c create mode 100644 drivers/media/video/davinci/vpbe_display.c create mode 100644 drivers/media/video/davinci/vpbe_osd.c create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h create mode 100644 drivers/media/video/davinci/vpbe_venc.c create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h create mode 100644 include/media/davinci/vpbe.h create mode 100644 include/media/davinci/vpbe_display.h create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 include/media/davinci/vpbe_types.h create mode 100644 include/media/davinci/vpbe_venc.h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v19 6/6] davinci vpbe: Readme text for Dm6446 vpbe
Please refer to this file for detailed documentation of davinci vpbe v4l2 driver. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Acked-by: Muralidharan Karicheri m-kariche...@ti.com Acked-by: Hans Verkuil hverk...@xs4all.nl --- Documentation/video4linux/README.davinci-vpbe | 93 + 1 files changed, 93 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe diff --git a/Documentation/video4linux/README.davinci-vpbe b/Documentation/video4linux/README.davinci-vpbe new file mode 100644 index 000..7a460b0 --- /dev/null +++ b/Documentation/video4linux/README.davinci-vpbe @@ -0,0 +1,93 @@ + +VPBE V4L2 driver design + == + + File partitioning + - + V4L2 display device driver + drivers/media/video/davinci/vpbe_display.c + drivers/media/video/davinci/vpbe_display.h + + VPBE display controller + drivers/media/video/davinci/vpbe.c + drivers/media/video/davinci/vpbe.h + + VPBE venc sub device driver + drivers/media/video/davinci/vpbe_venc.c + drivers/media/video/davinci/vpbe_venc.h + drivers/media/video/davinci/vpbe_venc_regs.h + + VPBE osd driver + drivers/media/video/davinci/vpbe_osd.c + drivers/media/video/davinci/vpbe_osd.h + drivers/media/video/davinci/vpbe_osd_regs.h + + Functional partitioning + --- + + Consists of the following (in the same order as the list under file + partitioning):- + + 1. V4L2 display driver +Implements creation of video2 and video3 device nodes and +provides v4l2 device interface to manage VID0 and VID1 layers. + + 2. Display controller +Loads up VENC, OSD and external encoders such as ths8200. It provides +a set of API calls to V4L2 drivers to set the output/standards +in the VENC or external sub devices. It also provides +a device object to access the services from OSD subdevice +using sub device ops. The connection of external encoders to VENC LCD +controller port is done at init time based on default output and standard +selection or at run time when application change the output through +V4L2 IOCTLs. + +When connected to an external encoder, vpbe controller is also responsible +for setting up the interface between VENC and external encoders based on +board specific settings (specified in board-xxx-evm.c). This allows +interfacing external encoders such as ths8200. The setup_if_config() +is implemented for this as well as configure_venc() (part of the next patch) +API to set timings in VENC for a specific display resolution. As of this +patch series, the interconnection and enabling and setting of the external +encoders is not present, and would be a part of the next patch series. + + 3. VENC subdevice module +Responsible for setting outputs provided through internal DACs and also +setting timings at LCD controller port when external encoders are connected +at the port or LCD panel timings required. When external encoder/LCD panel +is connected, the timings for a specific standard/preset is retrieved from +the board specific table and the values are used to set the timings in +venc using non-standard timing mode. + +Support LCD Panel displays using the VENC. For example to support a Logic +PD display, it requires setting up the LCD controller port with a set of +timings for the resolution supported and setting the dot clock. So we could +add the available outputs as a board specific entry (i.e add the LogicPD +output name to board-xxx-evm.c). A table of timings for various LCDs +supported can be maintained in the board specific setup file to support +various LCD displays.As of this patch a basic driver is present, and this +support for external encoders and displays forms a part of the next +patch series. + + 4. OSD module +OSD module implements all OSD layer management and hardware specific +features. The VPBE module interacts with the OSD for enabling and +disabling appropriate features of the OSD. + + Current status:- + + A fully functional working version of the V4L2 driver is available. This + driver has been tested with NTSC and PAL standards and buffer streaming. + + Following are TBDs. + + vpbe display controller +- Add support for external encoders. +- add support for selecting external encoder as default at probe time. + + vpbe venc sub device +- add timings for supporting ths8200 +- add support for LogicPD LCD. + + FB drivers +- Add support for fbdev drivers.- Ready and part of subsequent patches. -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v19 3/6] davinci vpbe: OSD(On Screen Display) block
This patch implements the functionality of the OSD block
of the VPBE. The OSD in total supports 4 planes or Video
sources - 2 mainly RGB and 2 Video. The patch implements general
handling of all the planes, with specific emphasis on the Video
plane capabilities as the Video planes are supported through the
V4L2 driver.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/davinci/vpbe_osd.c | 1231 +++
drivers/media/video/davinci/vpbe_osd_regs.h | 364
include/media/davinci/vpbe_osd.h| 394 +
3 files changed, 1989 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe_osd.c
create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h
create mode 100644 include/media/davinci/vpbe_osd.h
diff --git a/drivers/media/video/davinci/vpbe_osd.c
b/drivers/media/video/davinci/vpbe_osd.c
new file mode 100644
index 000..5352884
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_osd.c
@@ -0,0 +1,1231 @@
+/*
+ * Copyright (C) 2007-2010 Texas Instruments Inc
+ * Copyright (C) 2007 MontaVista Software, Inc.
+ *
+ * Andy Lowe (al...@mvista.com), MontaVista Software
+ * - Initial version
+ * Murali Karicheri (mkarich...@gmail.com), Texas Instruments Ltd.
+ * - ported to sub device interface
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/slab.h
+
+#include mach/io.h
+#include mach/cputype.h
+#include mach/hardware.h
+
+#include media/davinci/vpss.h
+#include media/v4l2-device.h
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe_osd.h
+
+#include linux/io.h
+#include vpbe_osd_regs.h
+
+#define MODULE_NAMEVPBE_OSD_SUBDEV_NAME
+
+/* register access routines */
+static inline u32 osd_read(struct osd_state *sd, u32 offset)
+{
+ struct osd_state *osd = sd;
+
+ return readl(osd-osd_base + offset);
+}
+
+static inline u32 osd_write(struct osd_state *sd, u32 val, u32 offset)
+{
+ struct osd_state *osd = sd;
+
+ writel(val, osd-osd_base + offset);
+
+ return val;
+}
+
+static inline u32 osd_set(struct osd_state *sd, u32 mask, u32 offset)
+{
+ struct osd_state *osd = sd;
+
+ u32 addr = osd-osd_base + offset;
+ u32 val = readl(addr) | mask;
+
+ writel(val, addr);
+
+ return val;
+}
+
+static inline u32 osd_clear(struct osd_state *sd, u32 mask, u32 offset)
+{
+ struct osd_state *osd = sd;
+
+ u32 addr = osd-osd_base + offset;
+ u32 val = readl(addr) ~mask;
+
+ writel(val, addr);
+
+ return val;
+}
+
+static inline u32 osd_modify(struct osd_state *sd, u32 mask, u32 val,
+u32 offset)
+{
+ struct osd_state *osd = sd;
+
+ u32 addr = osd-osd_base + offset;
+ u32 new_val = (readl(addr) ~mask) | (val mask);
+
+ writel(new_val, addr);
+
+ return new_val;
+}
+
+/* define some macros for layer and pixfmt classification */
+#define is_osd_win(layer) (((layer) == WIN_OSD0) || ((layer) == WIN_OSD1))
+#define is_vid_win(layer) (((layer) == WIN_VID0) || ((layer) == WIN_VID1))
+#define is_rgb_pixfmt(pixfmt) \
+ (((pixfmt) == PIXFMT_RGB565) || ((pixfmt) == PIXFMT_RGB888))
+#define is_yc_pixfmt(pixfmt) \
+ (((pixfmt) == PIXFMT_YCbCrI) || ((pixfmt) == PIXFMT_YCrCbI) || \
+ ((pixfmt) == PIXFMT_NV12))
+#define MAX_WIN_SIZE OSD_VIDWIN0XP_V0X
+#define MAX_LINE_LENGTH (OSD_VIDWIN0OFST_V0LO 5)
+
+/**
+ * _osd_dm6446_vid0_pingpong() - field inversion fix for DM6446
+ * @sd - ptr to struct osd_state
+ * @field_inversion - inversion flag
+ * @fb_base_phys - frame buffer address
+ * @lconfig - ptr to layer config
+ *
+ * This routine implements a workaround for the field signal inversion silicon
+ * erratum described in Advisory 1.3.8 for the DM6446. The fb_base_phys and
+ * lconfig parameters apply to the vid0 window. This routine should be called
+ * whenever the vid0 layer configuration or start address is modified, or when
+ * the OSD field inversion setting is modified.
+ * Returns: 1 if the ping-pong buffers need to be toggled in the vsync isr, or
+ * 0 otherwise
+ */
+static int
[PATCH v19 2/6] davinci vpbe: VPBE display driver
This patch implements the core functionality of the display driver,
mainly controlling the VENC and other encoders, and acting as
the one point interface for the main V4L2 driver. This implements
the core of each of the V4L2 IOCTLs.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/davinci/vpbe.c | 864
include/media/davinci/vpbe.h | 184
2 files changed, 1048 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe.c
create mode 100644 include/media/davinci/vpbe.h
diff --git a/drivers/media/video/davinci/vpbe.c
b/drivers/media/video/davinci/vpbe.c
new file mode 100644
index 000..d773d30
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe.c
@@ -0,0 +1,864 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/string.h
+#include linux/wait.h
+#include linux/time.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/clk.h
+#include linux/err.h
+
+#include media/v4l2-device.h
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe.h
+#include media/davinci/vpss.h
+#include media/davinci/vpbe_venc.h
+
+#define VPBE_DEFAULT_OUTPUTComposite
+#define VPBE_DEFAULT_MODE ntsc
+
+static char *def_output = VPBE_DEFAULT_OUTPUT;
+static char *def_mode = VPBE_DEFAULT_MODE;
+static int debug;
+
+module_param(def_output, charp, S_IRUGO);
+module_param(def_mode, charp, S_IRUGO);
+module_param(debug, int, 0644);
+
+MODULE_PARM_DESC(def_output, vpbe output name (default:Composite));
+MODULE_PARM_DESC(def_mode, vpbe output mode name (default:ntsc);
+MODULE_PARM_DESC(debug, Debug level 0-1);
+
+MODULE_DESCRIPTION(TI DMXXX VPBE Display controller);
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Texas Instruments);
+
+/**
+ * vpbe_current_encoder_info - Get config info for current encoder
+ * @vpbe_dev - vpbe device ptr
+ *
+ * Return ptr to current encoder config info
+ */
+static struct encoder_config_info*
+vpbe_current_encoder_info(struct vpbe_device *vpbe_dev)
+{
+ struct vpbe_config *cfg = vpbe_dev-cfg;
+ int index = vpbe_dev-current_sd_index;
+
+ return ((index == 0) ? cfg-venc :
+ cfg-ext_encoders[index-1]);
+}
+
+/**
+ * vpbe_find_encoder_sd_index - Given a name find encoder sd index
+ *
+ * @vpbe_config - ptr to vpbe cfg
+ * @output_index - index used by application
+ *
+ * Return sd index of the encoder
+ */
+static int vpbe_find_encoder_sd_index(struct vpbe_config *cfg,
+int index)
+{
+ char *encoder_name = cfg-outputs[index].subdev_name;
+ int i;
+
+ /* Venc is always first */
+ if (!strcmp(encoder_name, cfg-venc.module_name))
+ return 0;
+
+ for (i = 0; i cfg-num_ext_encoders; i++) {
+ if (!strcmp(encoder_name,
+cfg-ext_encoders[i].module_name))
+ return i+1;
+ }
+
+ return -EINVAL;
+}
+
+/**
+ * vpbe_g_cropcap - Get crop capabilities of the display
+ * @vpbe_dev - vpbe device ptr
+ * @cropcap - cropcap is a ptr to struct v4l2_cropcap
+ *
+ * Update the crop capabilities in crop cap for current
+ * mode
+ */
+static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev,
+ struct v4l2_cropcap *cropcap)
+{
+ if (NULL == cropcap)
+ return -EINVAL;
+ cropcap-bounds.left = 0;
+ cropcap-bounds.top = 0;
+ cropcap-bounds.width = vpbe_dev-current_timings.xres;
+ cropcap-bounds.height = vpbe_dev-current_timings.yres;
+ cropcap-defrect = cropcap-bounds;
+
+ return 0;
+}
+
+/**
+ * vpbe_enum_outputs - enumerate outputs
+ * @vpbe_dev - vpbe device ptr
+ * @output - ptr to v4l2_output structure
+ *
+ * Enumerates the outputs available at the vpbe display
+ * returns the status, -EINVAL if end of output list
+ */
+static int vpbe_enum_outputs(struct vpbe_device *vpbe_dev,
+struct v4l2_output *output)
+{
+ struct vpbe_config *cfg = vpbe_dev-cfg;
+ int temp_index = output-index;
+
+ if
[PATCH v19 4/6] davinci vpbe: VENC( Video Encoder) implementation
This patch adds the VENC or the Video encoder, which is responsible
for the blending of all source planes and timing generation for Video
modes like NTSC, PAL and other digital outputs. the VENC implementation
currently supports COMPOSITE and COMPONENT outputs and NTSC and PAL
resolutions through the analog DACs. The venc block is implemented
as a subdevice, allowing for additional external and internal encoders
of other kind to plug-in.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/davinci/vpbe_venc.c | 566 ++
drivers/media/video/davinci/vpbe_venc_regs.h | 177
include/media/davinci/vpbe_venc.h| 45 ++
3 files changed, 788 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe_venc.c
create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
create mode 100644 include/media/davinci/vpbe_venc.h
diff --git a/drivers/media/video/davinci/vpbe_venc.c
b/drivers/media/video/davinci/vpbe_venc.c
new file mode 100644
index 000..03a3e5c
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_venc.c
@@ -0,0 +1,566 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/ctype.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+#include linux/slab.h
+
+#include mach/hardware.h
+#include mach/mux.h
+#include mach/io.h
+#include mach/i2c.h
+
+#include linux/io.h
+
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe_venc.h
+#include media/davinci/vpss.h
+#include media/v4l2-device.h
+
+#include vpbe_venc_regs.h
+
+#define MODULE_NAMEVPBE_VENC_SUBDEV_NAME
+
+static int debug = 2;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, Debug level 0-2);
+
+struct venc_state {
+ struct v4l2_subdev sd;
+ struct venc_callback *callback;
+ struct venc_platform_data *pdata;
+ struct device *pdev;
+ u32 output;
+ v4l2_std_id std;
+ spinlock_t lock;
+ void __iomem *venc_base;
+ void __iomem *vdaccfg_reg;
+};
+
+static inline struct venc_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct venc_state, sd);
+}
+
+static inline u32 venc_read(struct v4l2_subdev *sd, u32 offset)
+{
+ struct venc_state *venc = to_state(sd);
+
+ return readl(venc-venc_base + offset);
+}
+
+static inline u32 venc_write(struct v4l2_subdev *sd, u32 offset, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+
+ writel(val, (venc-venc_base + offset));
+
+ return val;
+}
+
+static inline u32 venc_modify(struct v4l2_subdev *sd, u32 offset,
+u32 val, u32 mask)
+{
+ u32 new_val = (venc_read(sd, offset) ~mask) | (val mask);
+
+ venc_write(sd, offset, new_val);
+
+ return new_val;
+}
+
+static inline u32 vdaccfg_write(struct v4l2_subdev *sd, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+
+ writel(val, venc-vdaccfg_reg);
+
+ val = readl(venc-vdaccfg_reg);
+
+ return val;
+}
+
+/* This function sets the dac of the VPBE for various outputs
+ */
+static int venc_set_dac(struct v4l2_subdev *sd, u32 out_index)
+{
+ switch (out_index) {
+ case 0:
+ v4l2_dbg(debug, 1, sd, Setting output to Composite\n);
+ venc_write(sd, VENC_DACSEL, 0);
+ break;
+ case 1:
+ v4l2_dbg(debug, 1, sd, Setting output to S-Video\n);
+ venc_write(sd, VENC_DACSEL, 0x210);
+ break;
+ case 2:
+ venc_write(sd, VENC_DACSEL, 0x543);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void venc_enabledigitaloutput(struct v4l2_subdev *sd, int benable)
+{
+ v4l2_dbg(debug, 2, sd, venc_enabledigitaloutput\n);
+
+ if (benable) {
+ venc_write(sd, VENC_VMOD, 0);
+ venc_write(sd, VENC_CVBS, 0);
+ venc_write(sd, VENC_LCDOUT, 0);
+ venc_write(sd, VENC_HSPLS, 0);
+ venc_write(sd,
[PATCH] Add remote control support for mantis
Add remote control support for mantis driver
Signed-off-by: Christoph Pinkl christoph.pi...@gmail.com
---
drivers/media/dvb/mantis/hopper_cards.c|2 +-
drivers/media/dvb/mantis/mantis_cards.c| 27 +++-
drivers/media/dvb/mantis/mantis_common.h | 23 ++-
drivers/media/dvb/mantis/mantis_input.c| 168
+++-
drivers/media/dvb/mantis/mantis_input.h| 28
drivers/media/dvb/mantis/mantis_uart.c | 18 +--
drivers/media/dvb/mantis/mantis_vp1041.c | 20 +++
drivers/media/dvb/mantis/mantis_vp2033.c |4 +
drivers/media/dvb/mantis/mantis_vp2040.c |4 +
drivers/media/rc/keymaps/Makefile |3 +
.../media/rc/keymaps/rc-terratec-cinergy-c-pci.c | 85 ++
.../media/rc/keymaps/rc-terratec-cinergy-s2-hd.c | 85 ++
drivers/media/rc/keymaps/rc-twinhan-dtv-cab-ci.c | 95 +++
include/media/rc-map.h |3 +
14 files changed, 438 insertions(+), 127 deletions(-)
create mode 100644 drivers/media/dvb/mantis/mantis_input.h
create mode 100644 drivers/media/rc/keymaps/rc-terratec-cinergy-c-pci.c
create mode 100644 drivers/media/rc/keymaps/rc-terratec-cinergy-s2-hd.c
create mode 100644 drivers/media/rc/keymaps/rc-twinhan-dtv-cab-ci.c
diff --git a/drivers/media/dvb/mantis/hopper_cards.c
b/drivers/media/dvb/mantis/hopper_cards.c
index 1402062..0b76664 100644
--- a/drivers/media/dvb/mantis/hopper_cards.c
+++ b/drivers/media/dvb/mantis/hopper_cards.c
@@ -107,7 +107,7 @@ static irqreturn_t hopper_irq_handler(int irq, void
*dev_id)
}
if (stat MANTIS_INT_IRQ1) {
dprintk(MANTIS_DEBUG, 0, %s, label[2]);
- schedule_work(mantis-uart_work);
+ tasklet_schedule(mantis-uart_tasklet);
}
if (stat MANTIS_INT_OCERR) {
dprintk(MANTIS_DEBUG, 0, %s, label[3]);
diff --git a/drivers/media/dvb/mantis/mantis_cards.c
b/drivers/media/dvb/mantis/mantis_cards.c
index 05cbb9d..8eca749 100644
--- a/drivers/media/dvb/mantis/mantis_cards.c
+++ b/drivers/media/dvb/mantis/mantis_cards.c
@@ -49,6 +49,7 @@
#include mantis_pci.h
#include mantis_i2c.h
#include mantis_reg.h
+#include mantis_input.h
static unsigned int verbose;
module_param(verbose, int, 0644);
@@ -115,7 +116,7 @@ static irqreturn_t mantis_irq_handler(int irq, void
*dev_id)
}
if (stat MANTIS_INT_IRQ1) {
dprintk(MANTIS_DEBUG, 0, %s, label[2]);
- schedule_work(mantis-uart_work);
+ tasklet_schedule(mantis-uart_tasklet);
}
if (stat MANTIS_INT_OCERR) {
dprintk(MANTIS_DEBUG, 0, %s, label[3]);
@@ -180,6 +181,14 @@ static int __devinit mantis_pci_probe(struct pci_dev
*pdev, const struct pci_dev
config-irq_handler = mantis_irq_handler;
mantis-hwconfig= config;
+ if (mantis-hwconfig-config_init != NULL) {
+ dprintk(MANTIS_ERROR, 1,
+ Mantis-subsystem: vendor:0x%04x, device:0x%04x\n,
+ mantis-pdev-subsystem_vendor,
+ mantis-pdev-subsystem_device);
+ mantis-hwconfig-config_init(mantis);
+ }
+
err = mantis_pci_init(mantis);
if (err) {
dprintk(MANTIS_ERROR, 1, ERROR: Mantis PCI initialization
failed %d, err);
@@ -215,21 +224,32 @@ static int __devinit mantis_pci_probe(struct pci_dev
*pdev, const struct pci_dev
dprintk(MANTIS_ERROR, 1, ERROR: Mantis DVB initialization
failed %d, err);
goto fail4;
}
+
+ err = mantis_input_init(mantis);
+ if (err 0) {
+ dprintk(MANTIS_ERROR, 1, ERROR: Mantis INPUT initialization
failed %d, err);
+ goto fail6;
+ }
+
+
err = mantis_uart_init(mantis);
if (err 0) {
dprintk(MANTIS_ERROR, 1, ERROR: Mantis UART initialization
failed %d, err);
- goto fail6;
+ goto fail7;
}
devs++;
return err;
-
+fail7:
dprintk(MANTIS_ERROR, 1, ERROR: Mantis UART exit! %d, err);
mantis_uart_exit(mantis);
fail6:
+ dprintk(MANTIS_ERROR, 1, ERROR: Mantis INPUT exit! %d, err);
+ mantis_input_exit(mantis);
+
fail4:
dprintk(MANTIS_ERROR, 1, ERROR: Mantis DMA exit! %d, err);
mantis_dma_exit(mantis);
@@ -257,6 +277,7 @@ static void __devexit mantis_pci_remove(struct pci_dev
*pdev)
if (mantis) {
mantis_uart_exit(mantis);
+ mantis_input_exit(mantis);
mantis_dvb_exit(mantis);
mantis_dma_exit(mantis);
mantis_i2c_exit(mantis);
diff --git a/drivers/media/dvb/mantis/mantis_common.h
b/drivers/media/dvb/mantis/mantis_common.h
index bd400d2..a61046d 100644
--- a/drivers/media/dvb/mantis/mantis_common.h
+++
[RFCv2 PATCH 00/11] Control Event
This is the second version of the patch series introducing a new event that is triggered when a control's value or state changes. It incorporates the comments made since version 1. Most of these patches are relatively minor infrastructure changes. The real work is done in patch 7. This patch series builds on the bitmask patch series. The main changes since version 1 are: - The patches that add the bitmask control type are split off since these are needed sooner than the control events and they are indepedent of one another. - Instead of having separate CTRL_CH_VALUE and CTRL_CH_STATE events, there is now just one V4L2_EVENT_CTRL event which has a bitmask telling what was changed since the last event. In addition, the event payload gives all the relevant control data (type, value, min, max, step, def, flags). This greatly simplifies the applications that need to use this as it prevents having to do additional calls to VIDIOC_G_CTRL or VIDIOC_QUERYCTRL. - If you call VIDIOC_S_CTRL or VIDIOC_S_EXT_CTRLS, then the filehandle passed to the ioctl function will be skipped when the events for the new value are generated. This prevents nasty feedback loops. - Documentation was added. The vivi driver has been updated to support control events. The qv4l2 application has also been updated to test control events. You can find it here: http://git.linuxtv.org/hverkuil/v4l-utils.git?a=shortlog;h=refs/heads/core Please review! I'd like to get this in for 2.6.41. Still on my TODO list (will be done as separate patch series): - Change the way volatile controls are handled. - Add autofoo/foo support. - Make it possible to update control values from interrupt context. This will only be possible for a certain subset of controls. - I need to figure out how to handle the case where there are two inputs, each with its own subdev and set of controls. Switching inputs would imply switching controls as well. I've tried several things, but it's all very awkward. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 03/11] v4l2-ioctl: add ctrl_handler to v4l2_fh
This is required to implement control events and is also needed to allow
for per-filehandle control handlers.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/v4l2-fh.c|2 ++
drivers/media/video/v4l2-ioctl.c | 36 +++-
include/media/v4l2-fh.h |2 ++
3 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c
index 717f71e..8635011 100644
--- a/drivers/media/video/v4l2-fh.c
+++ b/drivers/media/video/v4l2-fh.c
@@ -32,6 +32,8 @@
int v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
{
fh-vdev = vdev;
+ /* Inherit from video_device. May be overridden by the driver. */
+ fh-ctrl_handler = vdev-ctrl_handler;
INIT_LIST_HEAD(fh-list);
set_bit(V4L2_FL_USES_V4L2_FH, fh-vdev-flags);
fh-prio = V4L2_PRIORITY_UNSET;
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 506edcc..75d475c 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -1418,7 +1418,9 @@ static long __video_do_ioctl(struct file *file,
{
struct v4l2_queryctrl *p = arg;
- if (vfd-ctrl_handler)
+ if (vfh vfh-ctrl_handler)
+ ret = v4l2_queryctrl(vfh-ctrl_handler, p);
+ else if (vfd-ctrl_handler)
ret = v4l2_queryctrl(vfd-ctrl_handler, p);
else if (ops-vidioc_queryctrl)
ret = ops-vidioc_queryctrl(file, fh, p);
@@ -1438,7 +1440,9 @@ static long __video_do_ioctl(struct file *file,
{
struct v4l2_control *p = arg;
- if (vfd-ctrl_handler)
+ if (vfh vfh-ctrl_handler)
+ ret = v4l2_g_ctrl(vfh-ctrl_handler, p);
+ else if (vfd-ctrl_handler)
ret = v4l2_g_ctrl(vfd-ctrl_handler, p);
else if (ops-vidioc_g_ctrl)
ret = ops-vidioc_g_ctrl(file, fh, p);
@@ -1470,12 +1474,16 @@ static long __video_do_ioctl(struct file *file,
struct v4l2_ext_controls ctrls;
struct v4l2_ext_control ctrl;
- if (!vfd-ctrl_handler
+ if (!(vfh vfh-ctrl_handler) !vfd-ctrl_handler
!ops-vidioc_s_ctrl !ops-vidioc_s_ext_ctrls)
break;
dbgarg(cmd, id=0x%x, value=%d\n, p-id, p-value);
+ if (vfh vfh-ctrl_handler) {
+ ret = v4l2_s_ctrl(vfh-ctrl_handler, p);
+ break;
+ }
if (vfd-ctrl_handler) {
ret = v4l2_s_ctrl(vfd-ctrl_handler, p);
break;
@@ -1501,7 +1509,9 @@ static long __video_do_ioctl(struct file *file,
struct v4l2_ext_controls *p = arg;
p-error_idx = p-count;
- if (vfd-ctrl_handler)
+ if (vfh vfh-ctrl_handler)
+ ret = v4l2_g_ext_ctrls(vfh-ctrl_handler, p);
+ else if (vfd-ctrl_handler)
ret = v4l2_g_ext_ctrls(vfd-ctrl_handler, p);
else if (ops-vidioc_g_ext_ctrls check_ext_ctrls(p, 0))
ret = ops-vidioc_g_ext_ctrls(file, fh, p);
@@ -1515,10 +1525,13 @@ static long __video_do_ioctl(struct file *file,
struct v4l2_ext_controls *p = arg;
p-error_idx = p-count;
- if (!vfd-ctrl_handler !ops-vidioc_s_ext_ctrls)
+ if (!(vfh vfh-ctrl_handler) !vfd-ctrl_handler
+ !ops-vidioc_s_ext_ctrls)
break;
v4l_print_ext_ctrls(cmd, vfd, p, 1);
- if (vfd-ctrl_handler)
+ if (vfh vfh-ctrl_handler)
+ ret = v4l2_s_ext_ctrls(vfh-ctrl_handler, p);
+ else if (vfd-ctrl_handler)
ret = v4l2_s_ext_ctrls(vfd-ctrl_handler, p);
else if (check_ext_ctrls(p, 0))
ret = ops-vidioc_s_ext_ctrls(file, fh, p);
@@ -1529,10 +1542,13 @@ static long __video_do_ioctl(struct file *file,
struct v4l2_ext_controls *p = arg;
p-error_idx = p-count;
- if (!vfd-ctrl_handler !ops-vidioc_try_ext_ctrls)
+ if (!(vfh vfh-ctrl_handler) !vfd-ctrl_handler
+ !ops-vidioc_try_ext_ctrls)
break;
v4l_print_ext_ctrls(cmd, vfd, p, 1);
- if (vfd-ctrl_handler)
+ if (vfh vfh-ctrl_handler)
+ ret = v4l2_try_ext_ctrls(vfh-ctrl_handler, p);
+ else if (vfd-ctrl_handler)
ret = v4l2_try_ext_ctrls(vfd-ctrl_handler, p);
else if (check_ext_ctrls(p, 0))
ret =
[RFCv2 PATCH 01/11] v4l2-ctrls: introduce call_op define
From: Hans Verkuil hans.verk...@cisco.com
Add the call_op define to safely call the control ops. This also allows
for controls without any ops such as the 'control class' controls.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 223e040..8b5f67f 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -25,6 +25,9 @@
#include media/v4l2-ctrls.h
#include media/v4l2-dev.h
+#define call_op(master, op) \
+ ((master-ops master-ops-op) ? master-ops-op(master) : 0)
+
/* Internal temporary helper struct, one for each v4l2_ext_control */
struct ctrl_helper {
/* The control corresponding to the v4l2_ext_control ID field. */
@@ -1306,7 +1309,7 @@ int v4l2_ctrl_handler_setup(struct v4l2_ctrl_handler *hdl)
if (ctrl-type == V4L2_CTRL_TYPE_BUTTON ||
(ctrl-flags V4L2_CTRL_FLAG_READ_ONLY))
continue;
- ret = master-ops-s_ctrl(master);
+ ret = call_op(master, s_ctrl);
if (ret)
break;
for (i = 0; i master-ncontrols; i++)
@@ -1583,8 +1586,8 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl,
struct v4l2_ext_controls *cs
v4l2_ctrl_lock(master);
/* g_volatile_ctrl will update the current control values */
- if (ctrl-is_volatile master-ops-g_volatile_ctrl)
- ret = master-ops-g_volatile_ctrl(master);
+ if (ctrl-is_volatile)
+ ret = call_op(master, g_volatile_ctrl);
/* If OK, then copy the current control values to the caller */
if (!ret)
ret = cluster_walk(i, cs, helpers, cur_to_user);
@@ -1615,8 +1618,8 @@ static int get_ctrl(struct v4l2_ctrl *ctrl, s32 *val)
v4l2_ctrl_lock(master);
/* g_volatile_ctrl will update the current control values */
- if (ctrl-is_volatile master-ops-g_volatile_ctrl)
- ret = master-ops-g_volatile_ctrl(master);
+ if (ctrl-is_volatile)
+ ret = call_op(master, g_volatile_ctrl);
*val = ctrl-cur.val;
v4l2_ctrl_unlock(master);
return ret;
@@ -1690,12 +1693,12 @@ static int try_or_set_control_cluster(struct v4l2_ctrl
*master, bool set)
/* For larger clusters you have to call try_ctrl again to
verify that the controls are still valid after the
'cur_to_new' above. */
- if (!ret master-ops-try_ctrl try)
- ret = master-ops-try_ctrl(master);
+ if (!ret try)
+ ret = call_op(master, try_ctrl);
/* Don't set if there is no change */
if (!ret set cluster_changed(master)) {
- ret = master-ops-s_ctrl(master);
+ ret = call_op(master, s_ctrl);
/* If OK, then make the new values permanent. */
if (!ret)
for (i = 0; i master-ncontrols; i++)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 07/11] v4l2-ctrls: add control events.
From: Hans Verkuil hans.verk...@cisco.com
Whenever a control changes value or state an event is sent to anyone
that subscribed to it.
This functionality is useful for control panels but also for applications
that need to wait for (usually status) controls to change value.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 101 ++
drivers/media/video/v4l2-event.c | 126 +++---
drivers/media/video/v4l2-fh.c|4 +-
include/linux/videodev2.h| 29 -
include/media/v4l2-ctrls.h | 16 +-
include/media/v4l2-event.h |2 +
6 files changed, 237 insertions(+), 41 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 3e0d8ab..e2a7ac7 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -23,6 +23,7 @@
#include media/v4l2-ioctl.h
#include media/v4l2-device.h
#include media/v4l2-ctrls.h
+#include media/v4l2-event.h
#include media/v4l2-dev.h
#define call_op(master, op) \
@@ -540,6 +541,44 @@ static bool type_is_int(const struct v4l2_ctrl *ctrl)
}
}
+static void fill_event(struct v4l2_event *ev, struct v4l2_ctrl *ctrl, u32
changes)
+{
+ memset(ev-reserved, 0, sizeof(ev-reserved));
+ ev-type = V4L2_EVENT_CTRL;
+ ev-id = ctrl-id;
+ ev-u.ctrl.changes = changes;
+ ev-u.ctrl.type = ctrl-type;
+ ev-u.ctrl.flags = ctrl-flags;
+ if (ctrl-type == V4L2_CTRL_TYPE_STRING)
+ ev-u.ctrl.value64 = 0;
+ else
+ ev-u.ctrl.value64 = ctrl-cur.val64;
+ ev-u.ctrl.minimum = ctrl-minimum;
+ ev-u.ctrl.maximum = ctrl-maximum;
+ if (ctrl-type == V4L2_CTRL_TYPE_MENU)
+ ev-u.ctrl.step = 1;
+ else
+ ev-u.ctrl.step = ctrl-step;
+ ev-u.ctrl.default_value = ctrl-default_value;
+}
+
+static void send_event(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, u32 changes)
+{
+ struct v4l2_event ev;
+ struct v4l2_ctrl_fh *pos;
+
+ if (list_empty(ctrl-fhs))
+ return;
+ fill_event(ev, ctrl, changes);
+
+ list_for_each_entry(pos, ctrl-fhs, node) {
+ if (pos-fh == fh)
+ continue;
+ ev.u.ctrl.flags = ctrl-flags;
+ v4l2_event_queue_fh(pos-fh, ev);
+ }
+}
+
/* Helper function: copy the current control value back to the caller */
static int cur_to_user(struct v4l2_ext_control *c,
struct v4l2_ctrl *ctrl)
@@ -629,20 +668,30 @@ static int new_to_user(struct v4l2_ext_control *c,
/* Copy the new value to the current value. */
static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl)
{
+ bool changed = false;
+
if (ctrl == NULL)
return;
switch (ctrl-type) {
+ case V4L2_CTRL_TYPE_BUTTON:
+ changed = true;
+ break;
case V4L2_CTRL_TYPE_STRING:
/* strings are always 0-terminated */
+ changed = strcmp(ctrl-string, ctrl-cur.string);
strcpy(ctrl-cur.string, ctrl-string);
break;
case V4L2_CTRL_TYPE_INTEGER64:
+ changed = ctrl-val64 != ctrl-cur.val64;
ctrl-cur.val64 = ctrl-val64;
break;
default:
+ changed = ctrl-val != ctrl-cur.val;
ctrl-cur.val = ctrl-val;
break;
}
+ if (changed)
+ send_event(fh, ctrl, V4L2_EVENT_CTRL_CH_VALUE);
}
/* Copy the current value to the new value */
@@ -787,6 +836,7 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
{
struct v4l2_ctrl_ref *ref, *next_ref;
struct v4l2_ctrl *ctrl, *next_ctrl;
+ struct v4l2_ctrl_fh *ctrl_fh, *next_ctrl_fh;
if (hdl == NULL || hdl-buckets == NULL)
return;
@@ -800,6 +850,10 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
/* Free all controls owned by the handler */
list_for_each_entry_safe(ctrl, next_ctrl, hdl-ctrls, node) {
list_del(ctrl-node);
+ list_for_each_entry_safe(ctrl_fh, next_ctrl_fh, ctrl-fhs,
node) {
+ list_del(ctrl_fh-node);
+ kfree(ctrl_fh);
+ }
kfree(ctrl);
}
kfree(hdl-buckets);
@@ -1006,6 +1060,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
}
INIT_LIST_HEAD(ctrl-node);
+ INIT_LIST_HEAD(ctrl-fhs);
ctrl-handler = hdl;
ctrl-ops = ops;
ctrl-id = id;
@@ -1147,6 +1202,9 @@ int v4l2_ctrl_add_handler(struct v4l2_ctrl_handler *hdl,
/* Skip handler-private controls. */
if (ctrl-is_private)
continue;
+ /* And control classes */
+ if (ctrl-type ==
[RFCv2 PATCH 09/11] vivi: support control events.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/vivi.c | 161 ++-
1 files changed, 97 insertions(+), 64 deletions(-)
diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index 21d8f6a..93692ad 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -32,6 +32,7 @@
#include media/v4l2-ioctl.h
#include media/v4l2-ctrls.h
#include media/v4l2-fh.h
+#include media/v4l2-event.h
#include media/v4l2-common.h
#define VIVI_MODULE_NAME vivi
@@ -157,54 +158,6 @@ struct vivi_dmaqueue {
static LIST_HEAD(vivi_devlist);
-struct vivi_dev {
- struct list_head vivi_devlist;
- struct v4l2_device v4l2_dev;
- struct v4l2_ctrl_handler ctrl_handler;
-
- /* controls */
- struct v4l2_ctrl *brightness;
- struct v4l2_ctrl *contrast;
- struct v4l2_ctrl *saturation;
- struct v4l2_ctrl *hue;
- struct v4l2_ctrl *volume;
- struct v4l2_ctrl *button;
- struct v4l2_ctrl *boolean;
- struct v4l2_ctrl *int32;
- struct v4l2_ctrl *int64;
- struct v4l2_ctrl *menu;
- struct v4l2_ctrl *string;
- struct v4l2_ctrl *bitmask;
-
- spinlock_t slock;
- struct mutex mutex;
-
- /* various device info */
- struct video_device*vfd;
-
- struct vivi_dmaqueue vidq;
-
- /* Several counters */
- unsigned ms;
- unsigned long jiffies;
- unsigned button_pressed;
-
- intmv_count;/* Controls bars movement */
-
- /* Input Number */
- intinput;
-
- /* video capture */
- struct vivi_fmt*fmt;
- unsigned int width, height;
- struct vb2_queue vb_vidq;
- enum v4l2_fieldfield;
- unsigned int field_count;
-
- u8 bars[9][3];
- u8 line[MAX_WIDTH * 4];
-};
-
/* --
DMA and thread functions
--*/
@@ -257,6 +210,50 @@ static struct bar_std bars[] = {
#define NUM_INPUTS ARRAY_SIZE(bars)
+struct vivi_dev {
+ struct list_head vivi_devlist;
+ struct v4l2_device v4l2_dev;
+ struct v4l2_ctrl_handler ctrl_handler;
+
+ /* controls */
+ struct v4l2_ctrl *volume;
+ struct v4l2_ctrl *button;
+ struct v4l2_ctrl *boolean;
+ struct v4l2_ctrl *int32;
+ struct v4l2_ctrl *int64;
+ struct v4l2_ctrl *menu;
+ struct v4l2_ctrl *string;
+ struct v4l2_ctrl *bitmask;
+
+ spinlock_t slock;
+ struct mutex mutex;
+
+ /* various device info */
+ struct video_device*vfd;
+
+ struct vivi_dmaqueue vidq;
+
+ /* Several counters */
+ unsigned ms;
+ unsigned long jiffies;
+ unsigned button_pressed;
+
+ intmv_count;/* Controls bars movement */
+
+ /* Input Number */
+ intinput;
+
+ /* video capture */
+ struct vivi_fmt*fmt;
+ unsigned int width, height;
+ struct vb2_queue vb_vidq;
+ enum v4l2_fieldfield;
+ unsigned int field_count;
+
+ u8 bars[9][3];
+ u8 line[MAX_WIDTH * 4];
+};
+
#define TO_Y(r, g, b) \
(((16829 * r + 33039 * g + 6416 * b + 32768) 16) + 16)
/* RGB to V(Cr) Color transform */
@@ -451,6 +448,14 @@ static void gen_text(struct vivi_dev *dev, char *basep,
static void vivi_fillbuff(struct vivi_dev *dev, struct vivi_buffer *buf)
{
+ struct v4l2_ctrl *brightness = v4l2_ctrl_find(dev-ctrl_handler,
+ V4L2_CID_BRIGHTNESS);
+ struct v4l2_ctrl *contrast = v4l2_ctrl_find(dev-ctrl_handler,
+ V4L2_CID_CONTRAST);
+ struct v4l2_ctrl *saturation = v4l2_ctrl_find(dev-ctrl_handler,
+ V4L2_CID_SATURATION);
+ struct v4l2_ctrl *hue = v4l2_ctrl_find(dev-ctrl_handler,
+ V4L2_CID_HUE);
int wmax = dev-width;
int hmax = dev-height;
struct timeval ts;
@@ -482,10 +487,10 @@ static void vivi_fillbuff(struct vivi_dev
[RFCv2 PATCH 10/11] V4L2 spec: document control events.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media-entities.tmpl |1 + Documentation/DocBook/v4l/vidioc-dqevent.xml | 17 +++- .../DocBook/v4l/vidioc-subscribe-event.xml | 142 +++- 3 files changed, 158 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index c8abb23..e0754a6 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -167,6 +167,7 @@ !ENTITY v4l2-event structnbsp;link linkend='v4l2-event'v4l2_event/link !ENTITY v4l2-event-subscription structnbsp;link linkend='v4l2-event-subscription'v4l2_event_subscription/link !ENTITY v4l2-event-vsync structnbsp;link linkend='v4l2-event-vsync'v4l2_event_vsync/link +!ENTITY v4l2-event-ctrl structnbsp;link linkend='v4l2-event-ctrl'v4l2_event_ctrl/link !ENTITY v4l2-ext-control structnbsp;link linkend='v4l2-ext-control'v4l2_ext_control/link !ENTITY v4l2-ext-controls structnbsp;link linkend='v4l2-ext-controls'v4l2_ext_controls/link !ENTITY v4l2-fmtdesc structnbsp;link linkend='v4l2-fmtdesc'v4l2_fmtdesc/link diff --git a/Documentation/DocBook/v4l/vidioc-dqevent.xml b/Documentation/DocBook/v4l/vidioc-dqevent.xml index 4e0a7cc..b8c4f76 100644 --- a/Documentation/DocBook/v4l/vidioc-dqevent.xml +++ b/Documentation/DocBook/v4l/vidioc-dqevent.xml @@ -81,6 +81,13 @@ /row row entry/entry + entryv4l2-event-ctrl;/entry +entrystructfieldctrl/structfield/entry + entryEvent data for event V4L2_EVENT_CTRL. +/entry + /row + row + entry/entry entry__u8/entry entrystructfielddata/structfield[64]/entry entryEvent data. Defined by the event type. The union @@ -110,8 +117,16 @@ entryEvent timestamp./entry /row row + entryu32/entry + entrystructfieldid/structfield/entry +entry/entry + entryThe ID associated with the event source. If the event does not + have an associated ID (this depends on the event type), then this + is 0./entry + /row + row entry__u32/entry - entrystructfieldreserved/structfield[9]/entry + entrystructfieldreserved/structfield[8]/entry entry/entry entryReserved for future extensions. Drivers must set the array to zero./entry diff --git a/Documentation/DocBook/v4l/vidioc-subscribe-event.xml b/Documentation/DocBook/v4l/vidioc-subscribe-event.xml index 8b50179..975f603 100644 --- a/Documentation/DocBook/v4l/vidioc-subscribe-event.xml +++ b/Documentation/DocBook/v4l/vidioc-subscribe-event.xml @@ -64,7 +64,19 @@ /row row entry__u32/entry - entrystructfieldreserved/structfield[7]/entry + entrystructfieldid/structfield/entry + entryID of the event source. If there is no ID associated with + the event source, then set this to 0. Whether or not an event + needs an ID depends on the event type./entry + /row + row + entry__u32/entry + entrystructfieldflags/structfield/entry + entryEvent flags, see xref linkend=event-flags /./entry + /row + row + entry__u32/entry + entrystructfieldreserved/structfield[5]/entry entryReserved for future extensions. Drivers and applications must set the array to zero./entry /row @@ -100,6 +112,23 @@ /entry /row row + entryconstantV4L2_EVENT_CTRL/constant/entry + entry3/entry + entryThis event requires that the structfieldid/structfield + matches the control ID from which you want to receive events. + This event is triggered if the control's value changes, if a + button control is pressed or if the control's flags change. + This event has v4l2-event-ctrl; associated with it. This struct + contains much of the same information as v4l2-queryctrl; and + v4l2-control;. + + If the event is generated due to a call to VIDIOC-S-CTRL; or + VIDIOC-S-EXT-CTRLS;, then the event will not be sent to + the file handle that called the ioctl function. This prevents + nasty feedback loops. + /entry + /row + row entryconstantV4L2_EVENT_PRIVATE_START/constant/entry entry0x0800/entry entryBase event number for driver-private events./entry @@ -108,6 +137,23 @@ /tgroup /table +table pgwide=1 frame=none id=event-flags + titleEvent Flags/title + tgroup cols=3 + cs-def; + tbody
[RFCv2 PATCH 05/11] v4l2-ctrls: add v4l2_fh pointer to the set control functions.
From: Hans Verkuil hans.verk...@cisco.com
When an application changes a control you want to generate an event.
However, you want to avoid sending such an event back to the application
(file handle) that caused the change.
Add the filehandle to the various set control functions.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 45
drivers/media/video/v4l2-ioctl.c |8 +++---
drivers/media/video/v4l2-subdev.c |4 +-
include/media/v4l2-ctrls.h|8 --
4 files changed, 36 insertions(+), 29 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index d895048..3e0d8ab 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -627,7 +627,7 @@ static int new_to_user(struct v4l2_ext_control *c,
}
/* Copy the new value to the current value. */
-static void new_to_cur(struct v4l2_ctrl *ctrl)
+static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl)
{
if (ctrl == NULL)
return;
@@ -1639,7 +1639,8 @@ EXPORT_SYMBOL(v4l2_ctrl_g_ctrl);
/* Core function that calls try/s_ctrl and ensures that the new value is
copied to the current value on a set.
Must be called with ctrl-handler-lock held. */
-static int try_or_set_control_cluster(struct v4l2_ctrl *master, bool set)
+static int try_or_set_control_cluster(struct v4l2_fh *fh,
+ struct v4l2_ctrl *master, bool set)
{
bool try = !set;
int ret = 0;
@@ -1680,7 +1681,7 @@ static int try_or_set_control_cluster(struct v4l2_ctrl
*master, bool set)
/* If OK, then make the new values permanent. */
if (!ret)
for (i = 0; i master-ncontrols; i++)
- new_to_cur(master-cluster[i]);
+ new_to_cur(fh, master-cluster[i]);
}
return ret;
}
@@ -1705,7 +1706,8 @@ static int check_flags_cluster(struct v4l2_ctrl *master)
}
/* Try or set controls. */
-static int try_or_set_ext_ctrls(struct v4l2_ctrl_handler *hdl,
+static int try_or_set_ext_ctrls(struct v4l2_fh *fh,
+ struct v4l2_ctrl_handler *hdl,
struct v4l2_ext_controls *cs,
struct ctrl_helper *helpers,
bool set)
@@ -1755,7 +1757,7 @@ static int try_or_set_ext_ctrls(struct v4l2_ctrl_handler
*hdl,
ret = check_flags_cluster(master);
if (!ret)
- ret = try_or_set_control_cluster(master, set);
+ ret = try_or_set_control_cluster(fh, master, set);
/* Copy the new values back to userspace. */
if (!ret)
@@ -1768,7 +1770,7 @@ static int try_or_set_ext_ctrls(struct v4l2_ctrl_handler
*hdl,
}
/* Try or try-and-set controls */
-static int try_set_ext_ctrls(struct v4l2_ctrl_handler *hdl,
+static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
struct v4l2_ext_controls *cs,
bool set)
{
@@ -1796,7 +1798,7 @@ static int try_set_ext_ctrls(struct v4l2_ctrl_handler
*hdl,
goto free;
/* First 'try' all controls and abort on error */
- ret = try_or_set_ext_ctrls(hdl, cs, helpers, false);
+ ret = try_or_set_ext_ctrls(NULL, hdl, cs, helpers, false);
/* If this is a 'set' operation and the initial 'try' failed,
then set error_idx to count to tell the application that no
controls changed value yet. */
@@ -1806,7 +1808,7 @@ static int try_set_ext_ctrls(struct v4l2_ctrl_handler
*hdl,
/* Reset 'handled' state */
for (i = 0; i cs-count; i++)
helpers[i].handled = false;
- ret = try_or_set_ext_ctrls(hdl, cs, helpers, true);
+ ret = try_or_set_ext_ctrls(fh, hdl, cs, helpers, true);
}
free:
@@ -1817,30 +1819,32 @@ free:
int v4l2_try_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls
*cs)
{
- return try_set_ext_ctrls(hdl, cs, false);
+ return try_set_ext_ctrls(NULL, hdl, cs, false);
}
EXPORT_SYMBOL(v4l2_try_ext_ctrls);
-int v4l2_s_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls
*cs)
+int v4l2_s_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
+ struct v4l2_ext_controls *cs)
{
- return try_set_ext_ctrls(hdl, cs, true);
+ return try_set_ext_ctrls(fh, hdl, cs, true);
}
EXPORT_SYMBOL(v4l2_s_ext_ctrls);
int v4l2_subdev_try_ext_ctrls(struct v4l2_subdev *sd, struct v4l2_ext_controls
*cs)
{
- return try_set_ext_ctrls(sd-ctrl_handler, cs, false);
+ return try_set_ext_ctrls(NULL, sd-ctrl_handler, cs, false);
}
EXPORT_SYMBOL(v4l2_subdev_try_ext_ctrls);
[RFCv2 PATCH 08/11] v4l2-ctrls: simplify event subscription.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 31 +++
include/media/v4l2-ctrls.h | 25 +
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index e2a7ac7..9807a20 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -831,6 +831,22 @@ int v4l2_ctrl_handler_init(struct v4l2_ctrl_handler *hdl,
}
EXPORT_SYMBOL(v4l2_ctrl_handler_init);
+/* Count the number of controls */
+unsigned v4l2_ctrl_handler_cnt(struct v4l2_ctrl_handler *hdl)
+{
+ struct v4l2_ctrl_ref *ref;
+ unsigned cnt = 0;
+
+ if (hdl == NULL)
+ return 0;
+ mutex_lock(hdl-lock);
+ list_for_each_entry(ref, hdl-ctrl_refs, node)
+ cnt++;
+ mutex_unlock(hdl-lock);
+ return cnt;
+}
+EXPORT_SYMBOL(v4l2_ctrl_handler_cnt);
+
/* Free all controls and control refs */
void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
{
@@ -1999,3 +2015,18 @@ void v4l2_ctrl_del_fh(struct v4l2_ctrl *ctrl, struct
v4l2_fh *fh)
v4l2_ctrl_unlock(ctrl);
}
EXPORT_SYMBOL(v4l2_ctrl_del_fh);
+
+int v4l2_ctrl_sub_fh(struct v4l2_fh *fh, struct v4l2_event_subscription *sub,
+unsigned n)
+{
+ int ret = 0;
+
+ if (!fh-events)
+ ret = v4l2_event_init(fh);
+ if (!ret)
+ ret = v4l2_event_alloc(fh, n);
+ if (!ret)
+ ret = v4l2_event_subscribe(fh, sub);
+ return ret;
+}
+EXPORT_SYMBOL(v4l2_ctrl_sub_fh);
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 2b99f29..e2b9053 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -252,6 +252,14 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
int v4l2_ctrl_handler_init(struct v4l2_ctrl_handler *hdl,
unsigned nr_of_controls_hint);
+/** v4l2_ctrl_handler_cnt() - Count the number of controls in the handler.
+ * @hdl: The control handler.
+ *
+ * Returns the number of controls referenced by this handler.
+ * Returns 0 if @hdl == NULL.
+ */
+unsigned v4l2_ctrl_handler_cnt(struct v4l2_ctrl_handler *hdl);
+
/** v4l2_ctrl_handler_free() - Free all controls owned by the handler and free
* the control list.
* @hdl: The control handler.
@@ -446,11 +454,28 @@ s32 v4l2_ctrl_g_ctrl(struct v4l2_ctrl *ctrl);
*/
int v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val);
+/* Internal helper functions that deal with control events. */
void v4l2_ctrl_add_fh(struct v4l2_ctrl_handler *hdl,
struct v4l2_ctrl_fh *ctrl_fh,
struct v4l2_event_subscription *sub);
void v4l2_ctrl_del_fh(struct v4l2_ctrl *ctrl, struct v4l2_fh *fh);
+/** v4l2_ctrl_sub_fh() - Helper function that subscribes a control event.
+ * @fh: The file handler that subscribed the control event.
+ * @sub: The event to subscribe (type must be V4L2_EVENT_CTRL).
+ * @n:How many events should be allocated? (Passed to
v4l2_event_alloc).
+ *Recommended to set to twice the number of controls plus whatever
+ *is needed for other events.
+ *
+ * A helper function that initializes the fh for events, allocates the
+ * list of events and subscribes the control event.
+ *
+ * Typically called in the handler of VIDIOC_SUBSCRIBE_EVENT in the
+ * V4L2_EVENT_CTRL case.
+ */
+int v4l2_ctrl_sub_fh(struct v4l2_fh *fh, struct v4l2_event_subscription *sub,
+unsigned n);
+
/* Helpers for ioctl_ops. If hdl == NULL then they will all return -EINVAL. */
int v4l2_queryctrl(struct v4l2_ctrl_handler *hdl, struct v4l2_queryctrl *qc);
int v4l2_querymenu(struct v4l2_ctrl_handler *hdl, struct v4l2_querymenu *qm);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 04/11] v4l2-ctrls: Replace v4l2_ctrl_activate/grab with v4l2_ctrl_flags.
From: Hans Verkuil hans.verk...@cisco.com
This more generic function makes it possible to have a single function
that takes care of flags handling, in particular with regards to sending
a control event when the flags change.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
Documentation/video4linux/v4l2-controls.txt | 28 +++--
drivers/media/video/cx2341x.c | 58 --
drivers/media/video/saa7115.c |3 +-
drivers/media/video/v4l2-ctrls.c| 33 ---
include/media/v4l2-ctrls.h | 34 +++-
5 files changed, 76 insertions(+), 80 deletions(-)
diff --git a/Documentation/video4linux/v4l2-controls.txt
b/Documentation/video4linux/v4l2-controls.txt
index 881e7f4..bc24be4 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -381,24 +381,26 @@ Active and Grabbed Controls
===
If you get more complex relationships between controls, then you may have to
-activate and deactivate controls. For example, if the Chroma AGC control is
-on, then the Chroma Gain control is inactive. That is, you may set it, but
-the value will not be used by the hardware as long as the automatic gain
-control is on. Typically user interfaces can disable such input fields.
+activate and deactivate controls. For example, depending on the chosen MPEG
+audio codec only the audio bitrate control correspending to that audio codec
+is marked 'active', all other audio bitrate controls will be marked 'inactive'.
+That is, you may set it, but the value will not be used by the hardware.
+Typically user interfaces will disable inactive input fields.
-You can set the 'active' status using v4l2_ctrl_activate(). By default all
-controls are active. Note that the framework does not check for this flag.
-It is meant purely for GUIs. The function is typically called from within
-s_ctrl.
+By default all controls are active. Note that the framework does not check
+for this flag. It is meant purely for GUIs.
-The other flag is the 'grabbed' flag. A grabbed control means that you cannot
+You may also have to grab controls. A grabbed control means that you cannot
change it because it is in use by some resource. Typical examples are MPEG
bitrate controls that cannot be changed while capturing is in progress.
-If a control is set to 'grabbed' using v4l2_ctrl_grab(), then the framework
-will return -EBUSY if an attempt is made to set this control. The
-v4l2_ctrl_grab() function is typically called from the driver when it
-starts or stops streaming.
+If a control is set to 'grabbed', then the framework will return -EBUSY if
+an attempt is made to set this control. You typically change the 'grabbed'
+status from the driver when it starts or stops streaming.
+
+You can change the control's status using the v4l2_ctrl_flags() or
+v4l2_ctrl_flags_lock() calls. The first can be called from within s_ctrl,
+the second can be called from elsewhere and will lock first.
Control Clusters
diff --git a/drivers/media/video/cx2341x.c b/drivers/media/video/cx2341x.c
index 103ef6b..2781889 100644
--- a/drivers/media/video/cx2341x.c
+++ b/drivers/media/video/cx2341x.c
@@ -1307,6 +1307,12 @@ static int cx2341x_try_ctrl(struct v4l2_ctrl *ctrl)
return 0;
}
+static void cx2341x_activate(struct v4l2_ctrl *ctrl, bool activate)
+{
+ v4l2_ctrl_flags(ctrl, V4L2_CTRL_FLAG_INACTIVE,
+ activate ? 0 : V4L2_CTRL_FLAG_INACTIVE);
+}
+
static int cx2341x_s_ctrl(struct v4l2_ctrl *ctrl)
{
static const int mpeg_stream_type[] = {
@@ -1380,10 +1386,10 @@ static int cx2341x_s_ctrl(struct v4l2_ctrl *ctrl)
int is_ac3 = hdl-audio_encoding-val ==
V4L2_MPEG_AUDIO_ENCODING_AC3;
- v4l2_ctrl_activate(hdl-audio_ac3_bitrate, is_ac3);
- v4l2_ctrl_activate(hdl-audio_l2_bitrate, !is_ac3);
+ cx2341x_activate(hdl-audio_ac3_bitrate, is_ac3);
+ cx2341x_activate(hdl-audio_l2_bitrate, !is_ac3);
}
- v4l2_ctrl_activate(hdl-audio_mode_extension,
+ cx2341x_activate(hdl-audio_mode_extension,
hdl-audio_mode-val ==
V4L2_MPEG_AUDIO_MODE_JOINT_STEREO);
if (cx2341x_neq(hdl-audio_sampling_freq)
hdl-ops hdl-ops-s_audio_sampling_freq)
@@ -1413,9 +1419,9 @@ static int cx2341x_s_ctrl(struct v4l2_ctrl *ctrl)
if (err)
return err;
- v4l2_ctrl_activate(hdl-video_bitrate_mode,
+ cx2341x_activate(hdl-video_bitrate_mode,
hdl-video_encoding-val !=
V4L2_MPEG_VIDEO_ENCODING_MPEG_1);
- v4l2_ctrl_activate(hdl-video_bitrate_peak,
+ cx2341x_activate(hdl-video_bitrate_peak,
[RFCv2 PATCH 02/11] v4l2-ctrls: drivers should be able to ignore READ_ONLY and GRABBED flags
From: Hans Verkuil hans.verk...@cisco.com
When applications try to set READ_ONLY or GRABBED controls an error should
be returned. However, when drivers do that it should be accepted.
Those controls could reflect some driver status which the application
can't change but the driver obviously has to be able to change it.
This is needed among others for future HDMI status controls.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 59 +-
1 files changed, 39 insertions(+), 20 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 8b5f67f..2afd632 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1673,11 +1673,6 @@ static int try_or_set_control_cluster(struct v4l2_ctrl
*master, bool set)
continue;
if (ctrl-is_new) {
- /* Double check this: it may have changed since the
- last check in try_or_set_ext_ctrls(). */
- if (set (ctrl-flags V4L2_CTRL_FLAG_GRABBED))
- return -EBUSY;
-
/* Validate if required */
if (!set)
ret = validate_new(ctrl);
@@ -1707,6 +1702,25 @@ static int try_or_set_control_cluster(struct v4l2_ctrl
*master, bool set)
return ret;
}
+/* Check if the flags allow you to set the modified controls. */
+static int check_flags_cluster(struct v4l2_ctrl *master)
+{
+ int i;
+
+ for (i = 0; i master-ncontrols; i++) {
+ struct v4l2_ctrl *ctrl = master-cluster[i];
+
+ if (ctrl == NULL || !ctrl-is_new)
+ continue;
+
+ if (ctrl-flags V4L2_CTRL_FLAG_READ_ONLY)
+ return -EACCES;
+ if (ctrl-flags V4L2_CTRL_FLAG_GRABBED)
+ return -EBUSY;
+ }
+ return 0;
+}
+
/* Try or set controls. */
static int try_or_set_ext_ctrls(struct v4l2_ctrl_handler *hdl,
struct v4l2_ext_controls *cs,
@@ -1716,24 +1730,23 @@ static int try_or_set_ext_ctrls(struct
v4l2_ctrl_handler *hdl,
unsigned i, j;
int ret = 0;
- cs-error_idx = cs-count;
for (i = 0; i cs-count; i++) {
struct v4l2_ctrl *ctrl = helpers[i].ctrl;
- if (!set)
- cs-error_idx = i;
+ cs-error_idx = i;
+ /* These tests are also done later in check_flags_cluster()
+ which is called in atomic context, so that has the
+ final say, but it makes sense to do an up-front
+ check as well. Once an error occurs below some other
+ controls may have been set already and we want to
+ do a best-effort to avoid that. */
if (ctrl-flags V4L2_CTRL_FLAG_READ_ONLY)
return -EACCES;
- /* This test is also done in try_set_control_cluster() which
- is called in atomic context, so that has the final say,
- but it makes sense to do an up-front check as well. Once
- an error occurs in try_set_control_cluster() some other
- controls may have been set already and we want to do a
- best-effort to avoid that. */
if (set (ctrl-flags V4L2_CTRL_FLAG_GRABBED))
return -EBUSY;
}
+ cs-error_idx = cs-count;
for (i = 0; !ret i cs-count; i++) {
struct v4l2_ctrl *ctrl = helpers[i].ctrl;
@@ -1755,6 +1768,9 @@ static int try_or_set_ext_ctrls(struct v4l2_ctrl_handler
*hdl,
user_to_new() sets 'is_new' to 1. */
ret = cluster_walk(i, cs, helpers, user_to_new);
+ if (!ret set)
+ ret = check_flags_cluster(master);
+
if (!ret)
ret = try_or_set_control_cluster(master, set);
@@ -1841,15 +1857,12 @@ int v4l2_subdev_s_ext_ctrls(struct v4l2_subdev *sd,
struct v4l2_ext_controls *cs
EXPORT_SYMBOL(v4l2_subdev_s_ext_ctrls);
/* Helper function for VIDIOC_S_CTRL compatibility */
-static int set_ctrl(struct v4l2_ctrl *ctrl, s32 *val)
+static int set_ctrl(struct v4l2_ctrl *ctrl, s32 *val, bool check_flags)
{
struct v4l2_ctrl *master = ctrl-cluster[0];
int ret;
int i;
- if (ctrl-flags V4L2_CTRL_FLAG_READ_ONLY)
- return -EACCES;
-
v4l2_ctrl_lock(ctrl);
/* Reset the 'is_new' flags of the cluster */
@@ -1860,6 +1873,8 @@ static int set_ctrl(struct v4l2_ctrl *ctrl, s32 *val)
ctrl-val = *val;
ctrl-is_new = 1;
ret = try_or_set_control_cluster(master, false);
+ if (!ret check_flags)
+ ret = check_flags_cluster(master);
[RFCv2 PATCH 11/11] v4l2-subdev: implement per-filehandle control handlers.
From: Hans Verkuil hans.verk...@cisco.com
To be consistent with v4l2-ioctl.c.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-device.c |1 +
drivers/media/video/v4l2-subdev.c | 14 +++---
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/v4l2-device.c
b/drivers/media/video/v4l2-device.c
index 4aae501..c72856c 100644
--- a/drivers/media/video/v4l2-device.c
+++ b/drivers/media/video/v4l2-device.c
@@ -209,6 +209,7 @@ int v4l2_device_register_subdev_nodes(struct v4l2_device
*v4l2_dev)
vdev-v4l2_dev = v4l2_dev;
vdev-fops = v4l2_subdev_fops;
vdev-release = video_device_release_empty;
+ vdev-ctrl_handler = sd-ctrl_handler;
err = __video_register_device(vdev, VFL_TYPE_SUBDEV, -1, 1,
sd-owner);
if (err 0)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index be4cbdd..fd5dcca 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -155,25 +155,25 @@ static long subdev_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
switch (cmd) {
case VIDIOC_QUERYCTRL:
- return v4l2_queryctrl(sd-ctrl_handler, arg);
+ return v4l2_queryctrl(vfh-ctrl_handler, arg);
case VIDIOC_QUERYMENU:
- return v4l2_querymenu(sd-ctrl_handler, arg);
+ return v4l2_querymenu(vfh-ctrl_handler, arg);
case VIDIOC_G_CTRL:
- return v4l2_g_ctrl(sd-ctrl_handler, arg);
+ return v4l2_g_ctrl(vfh-ctrl_handler, arg);
case VIDIOC_S_CTRL:
- return v4l2_s_ctrl(vfh, sd-ctrl_handler, arg);
+ return v4l2_s_ctrl(vfh, vfh-ctrl_handler, arg);
case VIDIOC_G_EXT_CTRLS:
- return v4l2_g_ext_ctrls(sd-ctrl_handler, arg);
+ return v4l2_g_ext_ctrls(vfh-ctrl_handler, arg);
case VIDIOC_S_EXT_CTRLS:
- return v4l2_s_ext_ctrls(vfh, sd-ctrl_handler, arg);
+ return v4l2_s_ext_ctrls(vfh, vfh-ctrl_handler, arg);
case VIDIOC_TRY_EXT_CTRLS:
- return v4l2_try_ext_ctrls(sd-ctrl_handler, arg);
+ return v4l2_try_ext_ctrls(vfh-ctrl_handler, arg);
case VIDIOC_DQEVENT:
if (!(sd-flags V4L2_SUBDEV_FL_HAS_EVENTS))
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 06/11] vb2_poll: don't start DMA, leave that to the first read().
From: Hans Verkuil hans.verk...@cisco.com
The vb2_poll function would start read-DMA if called without any streaming
in progress. This unfortunately does not work if the application just wants
to poll for exceptions. This information of what the application is polling
for is sadly unavailable in the driver.
Andy Walls suggested to just return POLLIN | POLLRDNORM and let the first
call to read() start the DMA. This initial read() call will return EAGAIN
since no actual data is available yet, but it does start the DMA.
Applications must handle EAGAIN in any case since there can be other reasons
for EAGAIN as well.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/videobuf2-core.c | 17 +++--
1 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 6ba1461..ad75c95 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -1372,27 +1372,16 @@ static int __vb2_cleanup_fileio(struct vb2_queue *q);
unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait)
{
unsigned long flags;
- unsigned int ret;
struct vb2_buffer *vb = NULL;
/*
* Start file I/O emulator only if streaming API has not been used yet.
*/
if (q-num_buffers == 0 q-fileio == NULL) {
- if (!V4L2_TYPE_IS_OUTPUT(q-type) (q-io_modes VB2_READ)) {
- ret = __vb2_init_fileio(q, 1);
- if (ret)
- return POLLERR;
- }
- if (V4L2_TYPE_IS_OUTPUT(q-type) (q-io_modes VB2_WRITE)) {
- ret = __vb2_init_fileio(q, 0);
- if (ret)
- return POLLERR;
- /*
-* Write to OUTPUT queue can be done immediately.
-*/
+ if (!V4L2_TYPE_IS_OUTPUT(q-type) (q-io_modes VB2_READ))
+ return POLLIN | POLLRDNORM;
+ if (V4L2_TYPE_IS_OUTPUT(q-type) (q-io_modes VB2_WRITE))
return POLLOUT | POLLWRNORM;
- }
}
/*
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.
Op 25 mei 2011, om 13:16 heeft Javier Martin het volgende geschreven: It includes several fixes pointed out by Laurent Pinchart. However, the BUG which shows artifacts in the image (horizontal lines) still persists. It won't happen if 1v8 regulator is not disabled (i.e. comment line where it is disabled in function mt9p031_power_off). I know there can be some other details to fix but I would like someone could help in the power management issue. I tried this + your beagle patch on 2.6.39 and both ISP and sensor being builtin to the kernel, I get the following: root@beagleboardxMC:~# media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1 ], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] root@beagleboardxMC:~# media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' Setting up format SGRBG12 320x240 on pad mt9p031 2-0048/0 Format set: SGRBG12 320x240 Setting up format SGRBG12 320x240 on pad OMAP3 ISP CCDC/0 Format set: SGRBG12 320x240 Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/0 Format set: SGRBG8 320x240 Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/1 Format set: SGRBG8 320x240 oot@beagleboardxMC:~# yavta -f SGRBG8 -s 320x240 -n 4 --capture=10 --skip 3 -F `media-ctl -e OMAP3 ISP CCDC output` Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG8 (47425247) 320x240 buffer size 76800 Video format: SGRBG8 (47425247) 320x240 buffer size 76800 4 buffers requested. length: 76800 offset: 0 Buffer 0 mapped at address 0x4030d000. length: 76800 offset: 77824 Buffer 1 mapped at address 0x4033. length: 76800 offset: 155648 Buffer 2 mapped at address 0x4042d000. length: 76800 offset: 233472 Buffer 3 mapped at address 0x40502000. [ 4131.459930] omap3isp omap3isp: CCDC won't become idle! [..] ^C[ 4134.919464] omap3isp omap3isp: CCDC won't become idle! [ 4135.926116] omap3isp omap3isp: Unable to stop OMAP3 ISP CCDC Do I need some extra ISP patches? Media-ctl -p output is listed below. regards, Koen root@beagleboardxMC:~# media-ctl -p Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev0 pad0: Input [SGRBG10 4096x4096] - 'OMAP3 ISP CCP2 input':pad0 [] pad1: Output [SGRBG10 4096x4096] - 'OMAP3 ISP CCDC':pad0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Output - 'OMAP3 ISP CCP2':pad0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Input [SGRBG10 4096x4096] pad1: Output [SGRBG10 4096x4096] - 'OMAP3 ISP CSI2a output':pad0 [] - 'OMAP3 ISP CCDC':pad0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Input - 'OMAP3 ISP CSI2a':pad1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [SGRBG8 320x240] - 'OMAP3 ISP CCP2':pad1 [] - 'OMAP3 ISP CSI2a':pad1 [] - 'mt9p031 2-0048':pad0 [ACTIVE] pad1: Output [SGRBG8 320x240] - 'OMAP3 ISP CCDC output':pad0 [ACTIVE] - 'OMAP3 ISP resizer':pad0 [] pad2: Output [SGRBG8 320x239] - 'OMAP3 ISP preview':pad0 [] - 'OMAP3 ISP AEWB':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP AF':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP histogram':pad0 [IMMUTABLE,ACTIVE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video2 pad0: Input - 'OMAP3 ISP CCDC':pad1 [ACTIVE] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Input [SGRBG10 4096x4096] - 'OMAP3 ISP CCDC':pad2 [] - 'OMAP3 ISP preview input':pad0 [] pad1: Output [YUYV 4082x4088] - 'OMAP3 ISP preview output':pad0 [] - 'OMAP3 ISP resizer':pad0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video3 pad0: Output - 'OMAP3 ISP preview':pad0 [] - entity 9: OMAP3 ISP preview output (1 pad, 1 link) type Node subtype V4L device node name /dev/video4 pad0:
Re: [PATCH 0/2] V4L: Extended crop/compose API
Hi Tomasz, On Tuesday 24 May 2011 14:28:49 Tomasz Stanislawski wrote: Laurent Pinchart wrote: On Wednesday 18 May 2011 18:55:51 Tomasz Stanislawski wrote: Laurent Pinchart wrote: On Saturday 14 May 2011 12:50:32 Hans Verkuil wrote: On Friday, May 13, 2011 14:43:08 Laurent Pinchart wrote: On Saturday 07 May 2011 13:52:25 Hans Verkuil wrote: On Thursday, May 05, 2011 11:39:54 Tomasz Stanislawski wrote: [snip] Solution I (more restrictive): 0 - driver is free to adjust size, it is recommended to choose the crop/compose rectangle as close as possible to desired one SEL_SIZE_GE - drive is not allowed to shrink the rectangle. If no such a rectangle exists ERANGE is returned (EINVAL is used for not-understandable configuration) SEL_SIZE_LE - drive is not allowed to grow the rectangle. If no such a rectangle exists ERANGE is returned (EINVAL is used for not-understandable configuration) SEL_SIZE_EQ = SEL_SIZE_GE | SEL_SIZE_LE - choose size exactly the same as in desired rectangle. Return ERANGE if such a configuration is not possible. So SEL_SIZE_EQ would be identical to 0, except that ERANGE would be returned if the resulting configuration is not equal to the requested configuration. - Solution II (less restrictive). Proposed in this RFC. 0 - apply rectangle as close as possible to desired one like the default behavior of VIDIOC_S_CROP. SEL_SIZE_GE - suggestion to increase or keep size of both coordinates SEL_SIZE_LE - suggestion to decrease or keep size of both coordinates SEL_SIZE_GE | SEL_SIZE_LE - technically suggestion to increase or keep or decrease sizes. Basically, it means that driver is completely free to choose coordinates. It works like saying give me a crop similar to this one to the driver. I agree that it is not a very useful combination of flags. I don't see any difference between that and 0. Drivers will implement both the same way. In both solutions, the driver is recommended to keep the center of the rectangle in the same place. Personally, I prefer 'solution I' because it is more logical one. One day, the SEL_SIZE_GE could be expanded to LEFT_LE | RIGHT_GE | TOP_LE | BOTTOM_GE flags if drivers could support it. But why return ERANGE ? That's one extra check in the driver that could easily be done in userspace. And it won't be very useful to applications, knowing that the driver doesn't support one exact configuration won't help the application finding out how to use the hardware. Applications will likely use 0 instead of SEL_SIZE_EQ. If we got for solution I, I think we should disallow SEL_SIZE_LE | SEL_SIZE_GE. It's just not useful. Hi Laurent, You are right that the check could be done in the userspace. However I think it is better to do it in driver or V4L2 framework because of following reasons: 1. Checking by an application is a redundant work: - application specifies constraint flags - application checks if returned coordinates suit to the flags, so demands are implemented twice by passing flags and making checks, it may lead to error prone code and difficult to detect bugs. - the code for checking of coordinates would be duplicated in every application that would use SELECTION 2. Coordinate checking could be done by v4l2 framework. I mean adding a function like one below: int v4l2_selection_check_rect(const struct v4l2_rect *adjusted, const struct v4l2_rect *desired, int flags) The function whould be called by driver after initial adjustments. The function returns -ERANGE if coordinates of adjusted rectangle do not suit to desired one basing on constraint flags. 3. It is easier to add new flags if checking is controlled by driver/v4l2 framework (including libv4l2). 4. Successful S_SELECTION may change format set by S_FMT - if adjusted rectangle does not suit to application's demands then falling back to other crop resolution requires to reconfigure the pipeline (calling S_FMT again). - therefore S_SELECTION should fail if it not possible to satisfy applications constraints and leave the hardware configuration intact We need to define how S_SELECTION and S_FMT will interact before I can answer this :-) The LE | GE behaviour is a detail though, so I think we can postpone the decision and work on S_SELECTION/S_FMT/S_WHATEVER interaction first. 5. Some application may want to have a fixed crop resolution, others may allow adjustment. I think that API should let applications explicitly decide which treatment they prefer and using SIZE_EQ is an intuitive way to force fixed coordinates. If the application if forced to use a fixed crop resolution. Without SIZE_EQ the application has to to a lot of checks only to detect that the resolution is not applicable. The application that use SIZE_* flags knows failure may happen. (In response to 1-3 and 5) Our current
Re: [PATCH] Add remote control support for mantis
Christoph Pinkl christoph.pi...@gmail.com writes: X-Mailer: Microsoft Office Outlook 12.0 This will not work. Use git-send-email or a working email client. See http://www.kernel.org/doc/Documentation/email-clients.txt for further hints. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[bug report] cxd2820r: dynamically allocated arrays
This driver has several places that use dynamically sized arrays.
It's dangerous to do that in the kernel because the kernel has a
very small stack. A bug could cause the stack to overflow and
corrupt memory. I seem to recall i2c transfers can be triggered by
the users but I don't know the details (ie security implications).
Here is an example of what I mean:
static int cxd2820r_tuner_i2c_xfer(struct i2c_adapter *i2c_adap,
struct i2c_msg msg[], int num)
{
struct cxd2820r_priv *priv = i2c_get_adapdata(i2c_adap);
u8 obuf[msg[0].len + 2];
^^
struct i2c_msg msg2[2] = {
If msg[0].len is too long it will overflow.
Here is the sparse output for the file:
CHECK drivers/media/dvb/frontends/cxd2820r_core.c
drivers/media/dvb/frontends/cxd2820r.h:58:30: error: dubious one-bit signed
bitfield
drivers/media/dvb/frontends/cxd2820r.h:64:23: error: dubious one-bit signed
bitfield
drivers/media/dvb/frontends/cxd2820r_priv.h:58:26: error: dubious one-bit
signed bitfield
drivers/media/dvb/frontends/cxd2820r_priv.h:64:31: error: dubious one-bit
signed bitfield
drivers/media/dvb/frontends/cxd2820r_core.c:33:19: error: bad constant
expression
drivers/media/dvb/frontends/cxd2820r_core.c:38:32: error: cannot size expression
drivers/media/dvb/frontends/cxd2820r_core.c:61:16: error: bad constant
expression
drivers/media/dvb/frontends/cxd2820r_core.c:71:32: error: cannot size expression
drivers/media/dvb/frontends/cxd2820r_core.c:743:28: error: bad constant
expression
drivers/media/dvb/frontends/cxd2820r_core.c:748:32: error: cannot size
expression
drivers/media/dvb/frontends/cxd2820r_core.c:762:31: error: cannot size
expression
CC [M] drivers/media/dvb/frontends/cxd2820r_core.o
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [bug report] cxd2820r: dynamically allocated arrays
Hello Dan,
I am just fixing those and also some other fixes.
regards,
Antti
On 05/25/2011 05:42 PM, Dan Carpenter wrote:
This driver has several places that use dynamically sized arrays.
It's dangerous to do that in the kernel because the kernel has a
very small stack. A bug could cause the stack to overflow and
corrupt memory. I seem to recall i2c transfers can be triggered by
the users but I don't know the details (ie security implications).
Here is an example of what I mean:
static int cxd2820r_tuner_i2c_xfer(struct i2c_adapter *i2c_adap,
struct i2c_msg msg[], int num)
{
struct cxd2820r_priv *priv = i2c_get_adapdata(i2c_adap);
u8 obuf[msg[0].len + 2];
^^
struct i2c_msg msg2[2] = {
If msg[0].len is too long it will overflow.
Here is the sparse output for the file:
CHECK drivers/media/dvb/frontends/cxd2820r_core.c
drivers/media/dvb/frontends/cxd2820r.h:58:30: error: dubious one-bit signed
bitfield
drivers/media/dvb/frontends/cxd2820r.h:64:23: error: dubious one-bit signed
bitfield
drivers/media/dvb/frontends/cxd2820r_priv.h:58:26: error: dubious one-bit
signed bitfield
drivers/media/dvb/frontends/cxd2820r_priv.h:64:31: error: dubious one-bit
signed bitfield
drivers/media/dvb/frontends/cxd2820r_core.c:33:19: error: bad constant
expression
drivers/media/dvb/frontends/cxd2820r_core.c:38:32: error: cannot size expression
drivers/media/dvb/frontends/cxd2820r_core.c:61:16: error: bad constant
expression
drivers/media/dvb/frontends/cxd2820r_core.c:71:32: error: cannot size expression
drivers/media/dvb/frontends/cxd2820r_core.c:743:28: error: bad constant
expression
drivers/media/dvb/frontends/cxd2820r_core.c:748:32: error: cannot size
expression
drivers/media/dvb/frontends/cxd2820r_core.c:762:31: error: cannot size
expression
CC [M] drivers/media/dvb/frontends/cxd2820r_core.o
regards,
dan carpenter
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb: one demux per tuner or one demux per demod?
Le mardi 24 mai 2011 16:00:14 Antti Palosaari, vous avez écrit : Yes I did, since I didn't know there is better way. Is there any other driver which implements it differently? I think all current MFE drivers does it like I did. For example look NetUP cx23885 + stv0367. /dev/dvb/adapter0/ crw-rw+ 1 root video 212, 2 May 24 15:51 demux0 crw-rw+ 1 root video 212, 3 May 24 15:51 dvr0 crw-rw+ 1 root video 212, 0 May 24 15:51 frontend0 crw-rw+ 1 root video 212, 1 May 24 15:51 frontend1 crw-rw+ 1 root video 212, 4 May 24 15:51 net0 So there is always only one demux per adapter then? That would work for me, but it contradicts the example code at Documentation/DocBook/dvb/examples.xml -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] [media] Documentation/DocBook: Rename media fops xml files
By convention, the name of the XML file should match the references declared at media-entities.tmpl, as, otherwise, some validation scripts break. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index c8abb23..5c44aa7 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -373,9 +373,9 @@ !ENTITY sub-media-indices SYSTEM media-indices.tmpl !ENTITY sub-media-controller SYSTEM v4l/media-controller.xml -!ENTITY sub-media-open SYSTEM v4l/media-func-open.xml -!ENTITY sub-media-close SYSTEM v4l/media-func-close.xml -!ENTITY sub-media-ioctl SYSTEM v4l/media-func-ioctl.xml +!ENTITY sub-media-func-open SYSTEM v4l/media-func-open.xml +!ENTITY sub-media-func-close SYSTEM v4l/media-func-close.xml +!ENTITY sub-media-func-ioctl SYSTEM v4l/media-func-ioctl.xml !ENTITY sub-media-ioc-device-info SYSTEM v4l/media-ioc-device-info.xml !ENTITY sub-media-ioc-enum-entities SYSTEM v4l/media-ioc-enum-entities.xml !ENTITY sub-media-ioc-enum-links SYSTEM v4l/media-ioc-enum-links.xml diff --git a/Documentation/DocBook/v4l/media-controller.xml b/Documentation/DocBook/v4l/media-controller.xml index 2dc25e1..873ac3a 100644 --- a/Documentation/DocBook/v4l/media-controller.xml +++ b/Documentation/DocBook/v4l/media-controller.xml @@ -78,9 +78,9 @@ appendix id=media-user-func titleFunction Reference/title !-- Keep this alphabetically sorted. -- - sub-media-open; - sub-media-close; - sub-media-ioctl; + sub-media-func-open; + sub-media-func-close; + sub-media-func-ioctl; !-- All ioctls go here. -- sub-media-ioc-device-info; sub-media-ioc-enum-entities; -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [media] add V4L2-PIX-FMT-SRGGB12 friends to docbook
The xml with those guys are there, but they weren't included on the docbook. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 5c44aa7..e5fe094 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -293,6 +293,7 @@ !ENTITY sub-yuyv SYSTEM v4l/pixfmt-yuyv.xml !ENTITY sub-yvyu SYSTEM v4l/pixfmt-yvyu.xml !ENTITY sub-srggb10 SYSTEM v4l/pixfmt-srggb10.xml +!ENTITY sub-srggb12 SYSTEM v4l/pixfmt-srggb12.xml !ENTITY sub-srggb8 SYSTEM v4l/pixfmt-srggb8.xml !ENTITY sub-y10 SYSTEM v4l/pixfmt-y10.xml !ENTITY sub-y12 SYSTEM v4l/pixfmt-y12.xml diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml index dbfe3b0..deb6602 100644 --- a/Documentation/DocBook/v4l/pixfmt.xml +++ b/Documentation/DocBook/v4l/pixfmt.xml @@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API. sub-srggb8; sub-sbggr16; sub-srggb10; +sub-srggb12; /section section id=yuv-formats -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap3isp - H3A auto white balance
Hello, I am developing a camera sensor driver for the Aptina MT9V034. I am only using it in snapshot mode and I can successfully trigger the sensor and receive pictures using the latest omap3isp driver from git://linuxtv.org/pinchartl/media.git branch omap3isp-next-sensors with kernel 2.6.38. I configure the sensor with media-ctl: media-ctl -r -l 'mt9v034 3-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -f 'mt9v034 3-0048:0[SGRBG10 752x480], OMAP3 ISP CCDC:1[SGRBG10 752x480]' And take pictures with yavta: ./yavta -f SGRBG10 -s 752x480 -n 6 --capture=6 -F /dev/video2 My trouble is that I am always receiving whiter pictures when I wait a moment before triggering the sensor to take a picture. If I take several pictures in a row with for instance 20 ms between them, they all look ok. But if I wait for 100 ms the picture will get much whiter. I have turned off auto exposure and auto gain in the sensor and the LED_OUT signal always have the same length (in this case 8 msec). Why would the pictures become whiter if I wait a moment before taking a picture? If I set the sensor in streaming mode all pictures look like they should. Could there be something with the H3A auto white balance or auto exposure? Regards, Daniel Lundborg -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] V4L: Extended crop/compose API
Laurent Pinchart wrote: Hi Tomasz, On Tuesday 24 May 2011 14:28:49 Tomasz Stanislawski wrote: Laurent Pinchart wrote: On Wednesday 18 May 2011 18:55:51 Tomasz Stanislawski wrote: Laurent Pinchart wrote: On Saturday 14 May 2011 12:50:32 Hans Verkuil wrote: On Friday, May 13, 2011 14:43:08 Laurent Pinchart wrote: On Saturday 07 May 2011 13:52:25 Hans Verkuil wrote: On Thursday, May 05, 2011 11:39:54 Tomasz Stanislawski wrote: [snip] Solution I (more restrictive): 0 - driver is free to adjust size, it is recommended to choose the crop/compose rectangle as close as possible to desired one SEL_SIZE_GE - drive is not allowed to shrink the rectangle. If no such a rectangle exists ERANGE is returned (EINVAL is used for not-understandable configuration) SEL_SIZE_LE - drive is not allowed to grow the rectangle. If no such a rectangle exists ERANGE is returned (EINVAL is used for not-understandable configuration) SEL_SIZE_EQ = SEL_SIZE_GE | SEL_SIZE_LE - choose size exactly the same as in desired rectangle. Return ERANGE if such a configuration is not possible. So SEL_SIZE_EQ would be identical to 0, except that ERANGE would be returned if the resulting configuration is not equal to the requested configuration. - Solution II (less restrictive). Proposed in this RFC. 0 - apply rectangle as close as possible to desired one like the default behavior of VIDIOC_S_CROP. SEL_SIZE_GE - suggestion to increase or keep size of both coordinates SEL_SIZE_LE - suggestion to decrease or keep size of both coordinates SEL_SIZE_GE | SEL_SIZE_LE - technically suggestion to increase or keep or decrease sizes. Basically, it means that driver is completely free to choose coordinates. It works like saying give me a crop similar to this one to the driver. I agree that it is not a very useful combination of flags. I don't see any difference between that and 0. Drivers will implement both the same way. In both solutions, the driver is recommended to keep the center of the rectangle in the same place. Personally, I prefer 'solution I' because it is more logical one. One day, the SEL_SIZE_GE could be expanded to LEFT_LE | RIGHT_GE | TOP_LE | BOTTOM_GE flags if drivers could support it. But why return ERANGE ? That's one extra check in the driver that could easily be done in userspace. And it won't be very useful to applications, knowing that the driver doesn't support one exact configuration won't help the application finding out how to use the hardware. Applications will likely use 0 instead of SEL_SIZE_EQ. If we got for solution I, I think we should disallow SEL_SIZE_LE | SEL_SIZE_GE. It's just not useful. Hi Laurent, You are right that the check could be done in the userspace. However I think it is better to do it in driver or V4L2 framework because of following reasons: 1. Checking by an application is a redundant work: - application specifies constraint flags - application checks if returned coordinates suit to the flags, so demands are implemented twice by passing flags and making checks, it may lead to error prone code and difficult to detect bugs. - the code for checking of coordinates would be duplicated in every application that would use SELECTION 2. Coordinate checking could be done by v4l2 framework. I mean adding a function like one below: int v4l2_selection_check_rect(const struct v4l2_rect *adjusted, const struct v4l2_rect *desired, int flags) The function whould be called by driver after initial adjustments. The function returns -ERANGE if coordinates of adjusted rectangle do not suit to desired one basing on constraint flags. 3. It is easier to add new flags if checking is controlled by driver/v4l2 framework (including libv4l2). 4. Successful S_SELECTION may change format set by S_FMT - if adjusted rectangle does not suit to application's demands then falling back to other crop resolution requires to reconfigure the pipeline (calling S_FMT again). - therefore S_SELECTION should fail if it not possible to satisfy applications constraints and leave the hardware configuration intact We need to define how S_SELECTION and S_FMT will interact before I can answer this :-) The LE | GE behaviour is a detail though, so I think we can postpone the decision and work on S_SELECTION/S_FMT/S_WHATEVER interaction first. 5. Some application may want to have a fixed crop resolution, others may allow adjustment. I think that API should let applications explicitly decide which treatment they prefer and using SIZE_EQ is an intuitive way to force fixed coordinates. If the application if forced to use a fixed crop resolution. Without SIZE_EQ the application has to to a lot of checks only to detect that the resolution is not applicable. The application that use SIZE_* flags knows failure may happen. 6. In order to compare an original and adjusted rectangle, an application must keep a copy of the original rectangle. It introduces a small memory overhead.
[PATCH] [media] fintek-cir: new driver for Fintek LPC SuperIO CIR function
This is a new driver for the Fintek LPC SuperIO CIR function, in the
Fintek F71809 chip. Hardware and datasheets were provided by Fintek, so
thanks go to them for supporting this effort.
This driver started out as a copy of the nuvoton-cir driver, and was
then modified as needed for the Fintek chip. The two share many
similaries, though the buffer handling for the Fintek chip is actually
nearly identical to the mceusb buffer handling, so the parser routine is
almost a drop-in copy of the mceusb buffer parser (a candidate for being
abstracted out into shared code at some point).
This initial code drop *only* supports receive, but the hardware does
support transmit as well. I really haven't even started to look at
what's required, but my guess is that its also pretty similar to mceusb.
Most people are probably only really interested in RX anyway though, so
I think its good to get this out there even with only RX.
(Nb: there are also Fintek-made mceusb receivers, which presumably, this
chip shares CIR hardware with).
This hardware can be found on at least Jetway NC98 boards and derivative
systems, and likely others as well. Functionality was tested with an
NC98 development board, in-kernel decode of RC6 (mce), RC5 (hauppauge)
and NEC-ish (tivo) remotes all successful, as was lirc userspace decode
of the RC6 remote.
CC: Aaron Huang aaron_hu...@fintek.com.tw
CC: Tom Tsai tom_t...@fintek.com.tw
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/rc/Kconfig | 12 +
drivers/media/rc/Makefile |1 +
drivers/media/rc/fintek-cir.c | 684 +
drivers/media/rc/fintek-cir.h | 243 +++
4 files changed, 940 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/rc/fintek-cir.c
create mode 100644 drivers/media/rc/fintek-cir.h
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 154c337..7d4bbc2 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -148,6 +148,18 @@ config IR_ITE_CIR
To compile this driver as a module, choose M here: the
module will be called ite-cir.
+config IR_FINTEK
+ tristate Fintek Consumer Infrared Transceiver
+ depends on PNP
+ depends on RC_CORE
+ ---help---
+ Say Y here to enable support for integrated infrared receiver
+ /transciever made by Fintek. This chip is found on assorted
+ Jetway motherboards (and of course, possibly others).
+
+ To compile this driver as a module, choose M here: the
+ module will be called fintek-cir.
+
config IR_NUVOTON
tristate Nuvoton w836x7hg Consumer Infrared Transceiver
depends on PNP
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 1f90a21..52830e5 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
obj-$(CONFIG_IR_IMON) += imon.o
obj-$(CONFIG_IR_ITE_CIR) += ite-cir.o
obj-$(CONFIG_IR_MCEUSB) += mceusb.o
+obj-$(CONFIG_IR_FINTEK) += fintek-cir.o
obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
obj-$(CONFIG_IR_ENE) += ene_ir.o
obj-$(CONFIG_IR_REDRAT3) += redrat3.o
diff --git a/drivers/media/rc/fintek-cir.c b/drivers/media/rc/fintek-cir.c
new file mode 100644
index 000..8fa539d
--- /dev/null
+++ b/drivers/media/rc/fintek-cir.c
@@ -0,0 +1,684 @@
+/*
+ * Driver for Feature Integration Technology Inc. (aka Fintek) LPC CIR
+ *
+ * Copyright (C) 2011 Jarod Wilson ja...@redhat.com
+ *
+ * Special thanks to Fintek for providing hardware and spec sheets.
+ * This driver is based upon the nuvoton, ite and ene drivers for
+ * similar hardware.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pnp.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/sched.h
+#include linux/slab.h
+#include media/rc-core.h
+#include linux/pci_ids.h
+
+#include fintek-cir.h
+
+/* write val to config reg */
+static inline void fintek_cr_write(struct fintek_dev *fintek, u8 val, u8 reg)
+{
+ fit_dbg(%s: reg 0x%02x, val 0x%02x (ip/dp: %02x/%02x),
+ __func__, reg, val, fintek-cr_ip, fintek-cr_dp);
+ outb(reg, fintek-cr_ip);
+ outb(val, fintek-cr_dp);
+}
+
+/* read val
[PATCH] Add remote control support for mantis
Signed-off-by: Christoph Pinkl christoph.pi...@gmail.com
---
drivers/media/dvb/mantis/hopper_cards.c|2 +-
drivers/media/dvb/mantis/mantis_cards.c| 27 +++-
drivers/media/dvb/mantis/mantis_common.h | 23 ++-
drivers/media/dvb/mantis/mantis_input.c| 168 +++-
drivers/media/dvb/mantis/mantis_input.h| 28
drivers/media/dvb/mantis/mantis_uart.c | 18 +--
drivers/media/dvb/mantis/mantis_vp1041.c | 20 +++
drivers/media/dvb/mantis/mantis_vp2033.c |4 +
drivers/media/dvb/mantis/mantis_vp2040.c |4 +
drivers/media/rc/keymaps/Makefile |3 +
.../media/rc/keymaps/rc-terratec-cinergy-c-pci.c | 85 ++
.../media/rc/keymaps/rc-terratec-cinergy-s2-hd.c | 85 ++
drivers/media/rc/keymaps/rc-twinhan-dtv-cab-ci.c | 95 +++
include/media/rc-map.h |3 +
14 files changed, 438 insertions(+), 127 deletions(-)
create mode 100644 drivers/media/dvb/mantis/mantis_input.h
create mode 100644 drivers/media/rc/keymaps/rc-terratec-cinergy-c-pci.c
create mode 100644 drivers/media/rc/keymaps/rc-terratec-cinergy-s2-hd.c
create mode 100644 drivers/media/rc/keymaps/rc-twinhan-dtv-cab-ci.c
diff --git a/drivers/media/dvb/mantis/hopper_cards.c
b/drivers/media/dvb/mantis/hopper_cards.c
index 1402062..0b76664 100644
--- a/drivers/media/dvb/mantis/hopper_cards.c
+++ b/drivers/media/dvb/mantis/hopper_cards.c
@@ -107,7 +107,7 @@ static irqreturn_t hopper_irq_handler(int irq, void *dev_id)
}
if (stat MANTIS_INT_IRQ1) {
dprintk(MANTIS_DEBUG, 0, %s, label[2]);
- schedule_work(mantis-uart_work);
+ tasklet_schedule(mantis-uart_tasklet);
}
if (stat MANTIS_INT_OCERR) {
dprintk(MANTIS_DEBUG, 0, %s, label[3]);
diff --git a/drivers/media/dvb/mantis/mantis_cards.c
b/drivers/media/dvb/mantis/mantis_cards.c
index 05cbb9d..8eca749 100644
--- a/drivers/media/dvb/mantis/mantis_cards.c
+++ b/drivers/media/dvb/mantis/mantis_cards.c
@@ -49,6 +49,7 @@
#include mantis_pci.h
#include mantis_i2c.h
#include mantis_reg.h
+#include mantis_input.h
static unsigned int verbose;
module_param(verbose, int, 0644);
@@ -115,7 +116,7 @@ static irqreturn_t mantis_irq_handler(int irq, void *dev_id)
}
if (stat MANTIS_INT_IRQ1) {
dprintk(MANTIS_DEBUG, 0, %s, label[2]);
- schedule_work(mantis-uart_work);
+ tasklet_schedule(mantis-uart_tasklet);
}
if (stat MANTIS_INT_OCERR) {
dprintk(MANTIS_DEBUG, 0, %s, label[3]);
@@ -180,6 +181,14 @@ static int __devinit mantis_pci_probe(struct pci_dev
*pdev, const struct pci_dev
config-irq_handler = mantis_irq_handler;
mantis-hwconfig= config;
+ if (mantis-hwconfig-config_init != NULL) {
+ dprintk(MANTIS_ERROR, 1,
+ Mantis-subsystem: vendor:0x%04x, device:0x%04x\n,
+ mantis-pdev-subsystem_vendor,
+ mantis-pdev-subsystem_device);
+ mantis-hwconfig-config_init(mantis);
+ }
+
err = mantis_pci_init(mantis);
if (err) {
dprintk(MANTIS_ERROR, 1, ERROR: Mantis PCI initialization
failed %d, err);
@@ -215,21 +224,32 @@ static int __devinit mantis_pci_probe(struct pci_dev
*pdev, const struct pci_dev
dprintk(MANTIS_ERROR, 1, ERROR: Mantis DVB initialization
failed %d, err);
goto fail4;
}
+
+ err = mantis_input_init(mantis);
+ if (err 0) {
+ dprintk(MANTIS_ERROR, 1, ERROR: Mantis INPUT initialization
failed %d, err);
+ goto fail6;
+ }
+
+
err = mantis_uart_init(mantis);
if (err 0) {
dprintk(MANTIS_ERROR, 1, ERROR: Mantis UART initialization
failed %d, err);
- goto fail6;
+ goto fail7;
}
devs++;
return err;
-
+fail7:
dprintk(MANTIS_ERROR, 1, ERROR: Mantis UART exit! %d, err);
mantis_uart_exit(mantis);
fail6:
+ dprintk(MANTIS_ERROR, 1, ERROR: Mantis INPUT exit! %d, err);
+ mantis_input_exit(mantis);
+
fail4:
dprintk(MANTIS_ERROR, 1, ERROR: Mantis DMA exit! %d, err);
mantis_dma_exit(mantis);
@@ -257,6 +277,7 @@ static void __devexit mantis_pci_remove(struct pci_dev
*pdev)
if (mantis) {
mantis_uart_exit(mantis);
+ mantis_input_exit(mantis);
mantis_dvb_exit(mantis);
mantis_dma_exit(mantis);
mantis_i2c_exit(mantis);
diff --git a/drivers/media/dvb/mantis/mantis_common.h
b/drivers/media/dvb/mantis/mantis_common.h
index bd400d2..a61046d 100644
--- a/drivers/media/dvb/mantis/mantis_common.h
+++ b/drivers/media/dvb/mantis/mantis_common.h
@@ -23,6 +23,9 @@
#include
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed May 25 19:00:34 CEST 2011 git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
h.264 web cam
I am trying to find the code for h.264 mentioned http://www.spinics.net/lists/linux-media/msg29129.html I downloaded the linux-media-2011-05.24 and it is not part of uvc_driver.c Where can I get the code? Thanks, Jerry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: h.264 web cam
Hi Jerry, On Wednesday 25 May 2011 21:44:59 Jerry Geis wrote: I am trying to find the code for h.264 mentioned http://www.spinics.net/lists/linux-media/msg29129.html I downloaded the linux-media-2011-05.24 and it is not part of uvc_driver.c Where can I get the code? That code only exists in the patches you've found. They haven't been applied to the uvcvideo driver, because we haven't decided yet how H.264 should be exposed to applications by the V4L2 API. We now have a better understanding of H.264. Hans, could you review the H.264 patch at the link above and tell me what you now think about the new fourcc ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: h.264 web cam
Laurent Pinchart wrote: Hi Jerry, On Wednesday 25 May 2011 21:44:59 Jerry Geis wrote: I am trying to find the code for h.264 mentioned http://www.spinics.net/lists/linux-media/msg29129.html I downloaded the linux-media-2011-05.24 and it is not part of uvc_driver.c Where can I get the code? That code only exists in the patches you've found. They haven't been applied to the uvcvideo driver, because we haven't decided yet how H.264 should be exposed to applications by the V4L2 API. We now have a better understanding of H.264. Hans, could you review the H.264 patch at the link above and tell me what you now think about the new fourcc ? Thanks I am trying to get an H.264 hardware encoded web cam from Facevsion E1 to work on linux. Its far superior to the the other web cams I was using. Jerry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy 1400 DVB-T RC not working anymore
On May 3, 2011, at 4:21 PM, Heiko Baums wrote: Am Tue, 3 May 2011 13:16:57 -0400 schrieb Jarod Wilson ja...@wilsonet.com: A quick look at the code suggests the 800i should indeed behave more or less the same, barring any hardware-specific implementation differences. Sure, might as well send one my way and I'll see what I can see. This RC indeed has the same issue. See this forums posting: https://bbs.archlinux.org/viewtopic.php?pid=924385#p924385 And this bug report: https://bugs.archlinux.org/task/23894 So... I have the card finally up and running in a test rig, but I don't yet have the necessary IR receiver cable. A glance at cx88-input.c and the default key table for the 800i gives some clues as to what is wrong though -- this is another case where the cx88 driver was only passing along the last byte of the remote's scancode, after the raw IR was decoded in cx88's private decoder. Now, we should be delivering the raw IR to the generic in-kernel IR decoders, which are then going to be passing along full scancodes for lookup table matching. If someone with the 800i (and/or the Terratec card) can load rc-core with debug=2, and provide dmesg output after punching a few buttons, it might be possible to get this squared away even before I have the necessary receiver cable. :) -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 2.6.40] PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C)
Moikka Mauro, Fixes... The following changes since commit 87cf028f3aa1ed51fe29c36df548aa714dc7438f: [media] dm1105: GPIO handling added, I2C on GPIO added, LNB control through GPIO reworked (2011-05-21 11:10:28 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git pctv_290e Antti Palosaari (7): em28xx-dvb: add module param options and use it for LNA cxd2820r: malloc buffers instead of stack cxd2820r: fix bitfields em28xx: EM28174 remote support em28xx: add remote for PCTV nanoStick T2 290e em28xx: correct PCTV nanoStick T2 290e device name cxd2820r: correct missing error checks drivers/media/dvb/frontends/cxd2820r.h |4 +- drivers/media/dvb/frontends/cxd2820r_core.c | 22 +--- drivers/media/dvb/frontends/cxd2820r_priv.h |4 +- drivers/media/video/em28xx/em28xx-cards.c |8 +++--- drivers/media/video/em28xx/em28xx-dvb.c | 37 --- drivers/media/video/em28xx/em28xx-input.c |1 + 6 files changed, 60 insertions(+), 16 deletions(-) Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: h.264 web cam
Hi Jerry, On Wednesday 25 May 2011 22:34:28 Jerry Geis wrote: Laurent Pinchart wrote: On Wednesday 25 May 2011 21:44:59 Jerry Geis wrote: I am trying to find the code for h.264 mentioned http://www.spinics.net/lists/linux-media/msg29129.html I downloaded the linux-media-2011-05.24 and it is not part of uvc_driver.c Where can I get the code? That code only exists in the patches you've found. They haven't been applied to the uvcvideo driver, because we haven't decided yet how H.264 should be exposed to applications by the V4L2 API. We now have a better understanding of H.264. Hans, could you review the H.264 patch at the link above and tell me what you now think about the new fourcc ? Thanks I am trying to get an H.264 hardware encoded web cam from Facevsion E1 to work on linux. Its far superior to the the other web cams I was using. Any chance I could get a sample from Facevision ? :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: h.264 web cam
Laurent Pinchart wrote: Hi Jerry, On Wednesday 25 May 2011 22:34:28 Jerry Geis wrote: Laurent Pinchart wrote: On Wednesday 25 May 2011 21:44:59 Jerry Geis wrote: I am trying to find the code for h.264 mentioned http://www.spinics.net/lists/linux-media/msg29129.html I downloaded the linux-media-2011-05.24 and it is not part of uvc_driver.c Where can I get the code? That code only exists in the patches you've found. They haven't been applied to the uvcvideo driver, because we haven't decided yet how H.264 should be exposed to applications by the V4L2 API. We now have a better understanding of H.264. Hans, could you review the H.264 patch at the link above and tell me what you now think about the new fourcc ? Thanks I am trying to get an H.264 hardware encoded web cam from Facevsion E1 to work on linux. Its far superior to the the other web cams I was using. Any chance I could get a sample from Facevision ? :-) I dont know I am not with them. You could always contact them. Where are you in the world? I can always connect it to a machine here and give you access? Let me know, Jerry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v1.88 DM04/QQBOX Move remote to use rc_core dvb-usb-remote.
driver to use dvb-usb-remote.
The remote(s) generates 24 bit NEC codes, lme2510 keymaps redefined.
Other minor fixes
fix le warning.
make sure frontend is detached on firmware change.
applied to v1.86
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/lmedm04.c | 107 +++
drivers/media/rc/keymaps/rc-lme2510.c | 134
2 files changed, 110 insertions(+), 131 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c
b/drivers/media/dvb/dvb-usb/lmedm04.c
index f36f471..37b1469 100644
--- a/drivers/media/dvb/dvb-usb/lmedm04.c
+++ b/drivers/media/dvb/dvb-usb/lmedm04.c
@@ -207,17 +207,6 @@ static int lme2510_stream_restart(struct dvb_usb_device *d)
rbuff, sizeof(rbuff));
return ret;
}
-static int lme2510_remote_keypress(struct dvb_usb_adapter *adap, u32 keypress)
-{
- struct dvb_usb_device *d = adap-dev;
-
- deb_info(1, INT Key Keypress =%04x, keypress);
-
- if (keypress 0)
- rc_keydown(d-rc_dev, keypress, 0);
-
- return 0;
-}
static int lme2510_enable_pid(struct dvb_usb_device *d, u8 index, u16 pid_out)
{
@@ -256,6 +245,7 @@ static void lme2510_int_response(struct urb *lme_urb)
struct lme2510_state *st = adap-dev-priv;
static u8 *ibuf, *rbuf;
int i = 0, offset;
+ u32 key;
switch (lme_urb-status) {
case 0:
@@ -282,10 +272,16 @@ static void lme2510_int_response(struct urb *lme_urb)
switch (ibuf[0]) {
case 0xaa:
- debug_data_snipet(1, INT Remote data snipet in, ibuf);
- lme2510_remote_keypress(adap,
- (u32)(ibuf[2] 24) + (ibuf[3] 16) +
- (ibuf[4] 8) + ibuf[5]);
+ debug_data_snipet(1, INT Remote data snipet, ibuf);
+ if ((ibuf[4] + ibuf[5]) == 0xff) {
+ key = ibuf[5];
+ key += (ibuf[3] 0)
+ ? (ibuf[3] ^ 0xff) 8 : 0;
+ key += (ibuf[2] ^ 0xff) 16;
+ deb_info(1, INT Key =%08x, key);
+ if (adap-dev-rc_dev != NULL)
+ rc_keydown(adap-dev-rc_dev, key, 0);
+ }
break;
case 0xbb:
switch (st-tuner_config) {
@@ -691,45 +687,6 @@ static int lme2510_streaming_ctrl(struct dvb_usb_adapter
*adap, int onoff)
return (ret 0) ? -ENODEV : 0;
}
-static int lme2510_int_service(struct dvb_usb_adapter *adap)
-{
- struct dvb_usb_device *d = adap-dev;
- struct rc_dev *rc;
- int ret;
-
- info(STA Configuring Remote);
-
- rc = rc_allocate_device();
- if (!rc)
- return -ENOMEM;
-
- usb_make_path(d-udev, d-rc_phys, sizeof(d-rc_phys));
- strlcat(d-rc_phys, /ir0, sizeof(d-rc_phys));
-
- rc-input_name = LME2510 Remote Control;
- rc-input_phys = d-rc_phys;
- rc-map_name = RC_MAP_LME2510;
- rc-driver_name = LME 2510;
- usb_to_input_id(d-udev, rc-input_id);
-
- ret = rc_register_device(rc);
- if (ret) {
- rc_free_device(rc);
- return ret;
- }
- d-rc_dev = rc;
-
- /* Start the Interrupt */
- ret = lme2510_int_read(adap);
- if (ret 0) {
- rc_unregister_device(rc);
- info(INT Unable to start Interrupt Service);
- return -ENODEV;
- }
-
- return 0;
-}
-
static u8 check_sum(u8 *p, u8 len)
{
u8 sum = 0;
@@ -831,7 +788,7 @@ static int lme_firmware_switch(struct usb_device *udev, int
cold)
cold_fw = !cold;
- if (udev-descriptor.idProduct == 0x1122) {
+ if (le16_to_cpu(udev-descriptor.idProduct) == 0x1122) {
switch (dvb_usb_lme2510_firmware) {
default:
dvb_usb_lme2510_firmware = TUNER_S0194;
@@ -1053,8 +1010,11 @@ static int dm04_lme2510_frontend_attach(struct
dvb_usb_adapter *adap)
end: if (ret) {
- kfree(adap-fe);
- adap-fe = NULL;
+ if (adap-fe) {
+ dvb_frontend_detach(adap-fe);
+ adap-fe = NULL;
+ }
+ adap-dev-props.rc.core.rc_codes = NULL;
return -ENODEV;
}
@@ -1097,8 +1057,12 @@ static int dm04_lme2510_tuner(struct dvb_usb_adapter
*adap)
return -ENODEV;
}
- /* Start the Interrupt Remote*/
- ret = lme2510_int_service(adap);
+ /* Start the Interrupt*/
+ ret = lme2510_int_read(adap);
+ if (ret 0) {
+ info(INT Unable to start Interrupt Service);
+ return -ENODEV;
+ }
return ret;
}
@@
[PATCH] [media] gspca/kinect: wrap gspca_debug with GSPCA_DEBUG
Fixes media_build, and presumably certain other upstream kernel build option combos. Before: CC [M] /home/jarod/src/media_build/v4l/kinect.o /home/jarod/src/media_build/v4l/kinect.c:38:19: error: 'D_ERR' undeclared here (not in a function) /home/jarod/src/media_build/v4l/kinect.c:38:27: error: 'D_PROBE' undeclared here (not in a function) /home/jarod/src/media_build/v4l/kinect.c:38:37: error: 'D_CONF' undeclared here (not in a function) /home/jarod/src/media_build/v4l/kinect.c:38:46: error: 'D_STREAM' undeclared here (not in a function) /home/jarod/src/media_build/v4l/kinect.c:38:57: error: 'D_FRAM' undeclared here (not in a function) /home/jarod/src/media_build/v4l/kinect.c:38:66: error: 'D_PACK' undeclared here (not in a function) /home/jarod/src/media_build/v4l/kinect.c:39:2: error: 'D_USBI' undeclared here (not in a function) /home/jarod/src/media_build/v4l/kinect.c:39:11: error: 'D_USBO' undeclared here (not in a function) /home/jarod/src/media_build/v4l/kinect.c:39:20: error: 'D_V4L2' undeclared here (not in a function) make[3]: *** [/home/jarod/src/media_build/v4l/kinect.o] Error 1 After: CC [M] /home/jarod/src/media_build/v4l/kinect.o ... LD [M] /home/jarod/src/media_build/v4l/gspca_kinect.ko ... profit Reported-by: Nicolas Will n...@youplala.net Signed-off-by: Jarod Wilson ja...@redhat.com --- drivers/media/video/gspca/kinect.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/gspca/kinect.c b/drivers/media/video/gspca/kinect.c index 66671a4..26fc206 100644 --- a/drivers/media/video/gspca/kinect.c +++ b/drivers/media/video/gspca/kinect.c @@ -34,7 +34,7 @@ MODULE_AUTHOR(Antonio Ospite osp...@studenti.unina.it); MODULE_DESCRIPTION(GSPCA/Kinect Sensor Device USB Camera Driver); MODULE_LICENSE(GPL); -#ifdef DEBUG +#ifdef GSPCA_DEBUG int gspca_debug = D_ERR | D_PROBE | D_CONF | D_STREAM | D_FRAM | D_PACK | D_USBI | D_USBO | D_V4L2; #endif -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: build errors on kinect and rc-main - 2.6.38 (mipi-csis not rc-main)
On May 25, 2011, at 3:01 AM, Nicolas WILL wrote: On Wed, 2011-05-25 at 07:43 +0100, Nicolas WILL wrote: The second one is on rc-main (I probably need that!): CC [M] /home/nico/src/media_build/v4l/rc-main.o /home/nico/src/media_build/v4l/rc-main.c: In function 'rc_allocate_device': /home/nico/src/media_build/v4l/rc-main.c:993:29: warning: assignment from incompatible pointer type /home/nico/src/media_build/v4l/rc-main.c:994:29: warning: assignment from incompatible pointer type CC [M] /home/nico/src/media_build/v4l/ir-raw.o CC [M] /home/nico/src/media_build/v4l/mipi-csis.o /home/nico/src/media_build/v4l/mipi-csis.c:29:28: fatal error: plat/mipi_csis.h: No such file or directory compilation terminated. Oh, not rc-main, but mipi-csis! True, but the rc-main warning is actually a valid issue that needs to be fixed as well. I'll get the necessary backport patch into media_build shortly, I hope... -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 2.6.40] Anysee
Moikka Mauro, Two new models and some fixes. The following changes since commit 87cf028f3aa1ed51fe29c36df548aa714dc7438f: [media] dm1105: GPIO handling added, I2C on GPIO added, LNB control through GPIO reworked (2011-05-21 11:10:28 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git anysee Antti Palosaari (4): anysee: return EOPNOTSUPP for unsupported I2C messages anysee: add support for Anysee E7 PTC anysee: add support for Anysee E7 PS2 anysee: style issues, comments, etc. drivers/media/dvb/dvb-usb/anysee.c | 86 ++-- drivers/media/dvb/dvb-usb/anysee.h | 16 --- 2 files changed, 71 insertions(+), 31 deletions(-) t. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] Fix the derot zig-zag to work with TT-USB2.0 TechnoTrend.
(This patch needs testing and review.)
From 5449f996bb340e4423b3146d1e0172dd635c0398 Mon Sep 17 00:00:00 2001
From: Hans Petter Selasky hsela...@c2i.net
Date: Tue, 24 May 2011 21:44:53 +0200
Subject: [PATCH] Fix the derot zig-zag to work with TT-USB2.0 TechnoTrend.
Signed-off-by: Hans Petter Selasky hsela...@c2i.net
---
drivers/media/dvb/frontends/stb0899_algo.c | 173
drivers/media/dvb/frontends/stb0899_drv.c |1 -
drivers/media/dvb/frontends/stb0899_priv.h |3 -
3 files changed, 75 insertions(+), 102 deletions(-)
diff --git a/drivers/media/dvb/frontends/stb0899_algo.c
b/drivers/media/dvb/frontends/stb0899_algo.c
index d70eee0..9156c3b 100644
--- a/drivers/media/dvb/frontends/stb0899_algo.c
+++ b/drivers/media/dvb/frontends/stb0899_algo.c
@@ -117,7 +117,7 @@ static u32 stb0899_set_srate(struct stb0899_state *state,
u32 master_clk, u32 sr
*/
static long stb0899_calc_derot_time(long srate)
{
- if (srate 0)
+ if (srate 999)
return (10 / (srate / 1000));
else
return 0;
@@ -200,6 +200,39 @@ static enum stb0899_status stb0899_check_tmg(struct
stb0899_state *state)
}
/*
+ * stb0899_set_derot
+ * set frequency derotor in HZ.
+ */
+static void
+stb0899_set_derot(struct stb0899_state *state, s16 derot)
+{
+ u8 cfr[2];
+
+ derot *= state-config-inversion;
+
+ cfr[0] = (u8)(derot 8);
+ cfr[1] = (u8)derot;
+
+ /* set derotator frequency in Hz */
+ stb0899_write_regs(state, STB0899_CFRM, cfr, 2);
+}
+
+/*
+ * stb0899_get_derot
+ * get frequency derotor in HZ.
+ */
+static s16
+stb0899_get_derot(struct stb0899_state *state)
+{
+ u8 cfr[2] = {0, 0};
+
+ /* get derotator frequency in Hz */
+ stb0899_read_regs(state, STB0899_CFRM, cfr, 2);
+
+ return (state-config-inversion * (s16)MAKEWORD16(cfr[0], cfr[1]));
+}
+
+/*
* stb0899_search_tmg
* perform a fs/2 zig-zag to find timing
*/
@@ -207,36 +240,22 @@ static enum stb0899_status stb0899_search_tmg(struct
stb0899_state *state)
{
struct stb0899_internal *internal = state-internal;
struct stb0899_params *params = state-params;
-
- short int derot_step, derot_freq = 0, derot_limit, next_loop = 3;
- int index = 0;
- u8 cfr[2];
+ int index;
internal-status = NOTIMING;
- /* timing loop computation symbol rate optimisation */
- derot_limit = (internal-sub_range / 2L) / internal-mclk;
- derot_step = (params-srate / 2L) / internal-mclk;
+ /* let the hardware figure out derot frequency */
+ stb0899_set_derot(state, 0);
- while ((stb0899_check_tmg(state) != TIMINGOK) next_loop) {
- index++;
- derot_freq += index * internal-direction * derot_step; /* next
derot zig zag position */
-
- if (abs(derot_freq) derot_limit)
- next_loop--;
+ for (index = 0; index 8; index++) {
+ if (stb0899_check_tmg(state) == TIMINGOK) {
+ /* get derotator frequency */
+ internal-derot_freq = stb0899_get_derot(state);
- if (next_loop) {
- STB0899_SETFIELD_VAL(CFRM, cfr[0],
MSB(state-config-inversion * derot_freq));
- STB0899_SETFIELD_VAL(CFRL, cfr[1],
LSB(state-config-inversion * derot_freq));
- stb0899_write_regs(state, STB0899_CFRM, cfr, 2); /*
derotator frequency */
+ dprintk(state-verbose, FE_DEBUG, 1, ---TIMING OK
!
+ Derot Freq = %d @ %d, internal-derot_freq,
index);
+ break;
}
- internal-direction = -internal-direction; /* Change
zigzag direction */
- }
-
- if (internal-status == TIMINGOK) {
- stb0899_read_regs(state, STB0899_CFRM, cfr, 2); /* get
derotator frequency */
- internal-derot_freq = state-config-inversion *
MAKEWORD16(cfr[0], cfr[1]);
- dprintk(state-verbose, FE_DEBUG, 1, ---TIMING OK ! Derot
Freq = %d, internal-derot_freq);
}
return internal-status;
@@ -277,50 +296,26 @@ static enum stb0899_status stb0899_check_carrier(struct
stb0899_state *state)
static enum stb0899_status stb0899_search_carrier(struct stb0899_state *state)
{
struct stb0899_internal *internal = state-internal;
-
- short int derot_freq = 0, last_derot_freq = 0, derot_limit, next_loop =
3;
- int index = 0;
- u8 cfr[2];
+ int index;
u8 reg;
internal-status = NOCARRIER;
- derot_limit = (internal-sub_range / 2L) / internal-mclk;
- derot_freq = internal-derot_freq;
+
+ /* let the hardware figure out derot frequency */
+ stb0899_set_derot(state, 0);
reg = stb0899_read_reg(state, STB0899_CFD);
STB0899_SETFIELD_VAL(CFD_ON, reg, 1);
Re: build errors on kinect and rc-main - 2.6.38 (mipi-csis not rc-main)
On May 25, 2011, at 5:41 PM, Jarod Wilson wrote: On May 25, 2011, at 3:01 AM, Nicolas WILL wrote: On Wed, 2011-05-25 at 07:43 +0100, Nicolas WILL wrote: The second one is on rc-main (I probably need that!): CC [M] /home/nico/src/media_build/v4l/rc-main.o /home/nico/src/media_build/v4l/rc-main.c: In function 'rc_allocate_device': /home/nico/src/media_build/v4l/rc-main.c:993:29: warning: assignment from incompatible pointer type /home/nico/src/media_build/v4l/rc-main.c:994:29: warning: assignment from incompatible pointer type CC [M] /home/nico/src/media_build/v4l/ir-raw.o CC [M] /home/nico/src/media_build/v4l/mipi-csis.o /home/nico/src/media_build/v4l/mipi-csis.c:29:28: fatal error: plat/mipi_csis.h: No such file or directory compilation terminated. Oh, not rc-main, but mipi-csis! True, but the rc-main warning is actually a valid issue that needs to be fixed as well. I'll get the necessary backport patch into media_build shortly, I hope... Patches pushed. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: build errors on kinect and rc-main - 2.6.38 (mipi-csis not rc-main)
On Wed, 2011-05-25 at 18:02 -0400, Jarod Wilson wrote: On May 25, 2011, at 5:41 PM, Jarod Wilson wrote: On May 25, 2011, at 3:01 AM, Nicolas WILL wrote: On Wed, 2011-05-25 at 07:43 +0100, Nicolas WILL wrote: The second one is on rc-main (I probably need that!): CC [M] /home/nico/src/media_build/v4l/rc-main.o /home/nico/src/media_build/v4l/rc-main.c: In function 'rc_allocate_device': /home/nico/src/media_build/v4l/rc-main.c:993:29: warning: assignment from incompatible pointer type /home/nico/src/media_build/v4l/rc-main.c:994:29: warning: assignment from incompatible pointer type CC [M] /home/nico/src/media_build/v4l/ir-raw.o CC [M] /home/nico/src/media_build/v4l/mipi-csis.o /home/nico/src/media_build/v4l/mipi-csis.c:29:28: fatal error: plat/mipi_csis.h: No such file or directory compilation terminated. Oh, not rc-main, but mipi-csis! True, but the rc-main warning is actually a valid issue that needs to be fixed as well. I'll get the necessary backport patch into media_build shortly, I hope... Patches pushed. :o) Thanks ! Nico -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH FOR 2.6.40] uvcvideo patches
Hi Mauro, Thanks for applying the patches. For the record, the compromise was to implement XU controls filtering to make sure that userspace applications won't have access to potentially dangerous controls, and to push vendors to properly document their XUs. On Tuesday 24 May 2011 16:13:01 Mauro Carvalho Chehab wrote: Em 23-05-2011 19:27, Laurent Pinchart escreveu: On Friday 20 May 2011 23:01:18 Mauro Carvalho Chehab wrote: Em 20-05-2011 16:47, Laurent Pinchart escreveu: On Friday 20 May 2011 21:16:49 Mauro Carvalho Chehab wrote: [snip] UVC compliance, using the Microsoft driver, is a requirement for webcams to receive the designed for Windows Vista/7 certification. Vendors are thus not trying to push all kind of proprietary, non UVC-compliant features for their devices (most of them don't have the necessary resources to implement a custom UVC driver). If you look on how MCE remote controllers are implemented, you'll see that this is a really bad example. I was told by one of the MCE manufacturers that even them don't know the MCE protocol used there. Microsoft doesn't care about open specs. They only care about having the device working with their drivers. Oh, for sure. That's why many UVC devices crash when you send them requests that are not used by the Windows UVC driver. Some vendors (namely Logitech) started testing their devices on Linux, hopefully that trend will catch up. My point was that, as devices need to work with the Windows UVC drivers, many manufacturers will not add non-compliant, undocumented features to their devices as they don't have the resources to implement a custom UVC driver. Bigger vendors still do that though. Can you imagine a vendor looking at the Linux driver, seeing that UVC XUs can be accessed directly, and then deciding to design their hardware based on that ? I can't :-) XUs are accessible in Windows through a documented API. If vendors want to design devices that expose XU controls, they will do it, regardless of whether Linux implements support for that or not. It is to fragile to assume that. At Windows, vendors write their own drivers, and are allowed to do whatever they want on a closed source. For proprietary protocols that what happens. For UVC the situation is a bit better, as the Microsoft UVC driver is widely used nowadays. The Windows driver model allows vendors to write filter drivers though, so I agree that they can add support for proprietary device features. We have several alternatives. One of them, that is being shipped in some systems, is a uvcvideo driver patched by the Evil Manufacturer(tm), incompatible with the mainline version. Another one is a closed-source userspace driver based on libusb shipped by the Evil Manufacturer(tm). Yet another one is webcams that work on Windows only. Which one do you prefer ? I prefer to ask the vendor about the XU controls that he needs and add a proper interface for them. And I would rather having Nvidia documenting their hardware, but that's not the world we live in :-) Some XU controls are variable-size binary chunks of data. We can't expose that as V4L2 controls, which is why I expose them using a documented UVC API. The V4L2 API allows string controls. Hans was very much against using string controls to pass raw binary data. [snip] Unfortunately, by being a generic driver for an USB class, and with vendors not quite following the specs, there's no way to avoid having device-specific stuff there. Other similar drivers like snd-usb-audio and sound hda driver has lots of quirks. In particular, the hda driver contains more lines to the patch-*.c drivers (with the device-specific stuff) than the driver core: [snip] So, I'm yet not convinced ;) In fact, I think we should just deprecate the XU private ioctls. http://www.quickcamteam.net/uvc-h264/USB_Video_Payload_H.264_0.87.pdf That's a brain-dead proposal for a new H.264 payload format pushed by Logitech and Microsoft. The document is a bit outdated, but the final version will likely be close. It requires direct XU access from applications. I don't like it either, and the alternative will be to not support H.264 UVC cameras at all (something I might consider, by blacklisting the product completely). Are you ready to refuse supporting large classes of USB hardware ? What's the difference between: 1) exposing XU access to userspace and having no applications using it; 2) just blacklisting them. The end result is the same. Why would there be no applications using it ? The UVC H.264 XUs are documented in the above spec, so application can use them. The Linux kernel were designed to abstract hardware differences. We should not move this task to userspace. I agree in principle, but we will have to rethink this at some point in the future. I don't think it will always be possible to handle all hardware
Re: [GIT PATCH FOR 2.6.40] uvcvideo patches
Em 25-05-2011 20:20, Laurent Pinchart escreveu: Hi Mauro, Thanks for applying the patches. For the record, the compromise was to implement XU controls filtering to make sure that userspace applications won't have access to potentially dangerous controls, and to push vendors to properly document their XUs. Ok, thanks! Some XU controls are variable-size binary chunks of data. We can't expose that as V4L2 controls, which is why I expose them using a documented UVC API. The V4L2 API allows string controls. Hans was very much against using string controls to pass raw binary data. Pass raw binary data is bad when we know nothing about what's passing there. A firmware update control-type however, is a different thing, as we really don't care about what's there. Yet, I agree that this may not be the best way of doing it. Why would there be no applications using it ? The UVC H.264 XUs are documented in the above spec, so application can use them. The Linux kernel were designed to abstract hardware differences. We should not move this task to userspace. I agree in principle, but we will have to rethink this at some point in the future. I don't think it will always be possible to handle all hardware abstractions in the kernel. Some hardware require floating point operations in their drivers for instance. I talked with Linus some years ago about float point ops in Kernel. He said he was not against that, but there are some issues, as float point processors are arch-dependent, and kernel doesn't save FP registers. So, if a driver really needs to use it, extra care should be taken. That's said, some drivers use fixed point operations for some specific usages. There's an industry trend there, and we need to think about solutions now otherwise we will be left without any way forward when too many devices will be impossible to support from kernelspace (OMAP4 is a good example there, some device drivers require communication with other cores, and the communication API is implemented in userspace). Needing to go to userspace to allow inter-core communication seems very bad. I seriously doubt that this is a trend. It seems more like a broken-by-design type of architecture. Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH FOR 2.6.40] uvcvideo patches
Hi Mauro, On Thursday 26 May 2011 01:34:10 Mauro Carvalho Chehab wrote: Em 25-05-2011 20:20, Laurent Pinchart escreveu: Hi Mauro, Thanks for applying the patches. For the record, the compromise was to implement XU controls filtering to make sure that userspace applications won't have access to potentially dangerous controls, and to push vendors to properly document their XUs. Ok, thanks! Some XU controls are variable-size binary chunks of data. We can't expose that as V4L2 controls, which is why I expose them using a documented UVC API. The V4L2 API allows string controls. Hans was very much against using string controls to pass raw binary data. Pass raw binary data is bad when we know nothing about what's passing there. A firmware update control-type however, is a different thing, as we really don't care about what's there. Yet, I agree that this may not be the best way of doing it. Why would there be no applications using it ? The UVC H.264 XUs are documented in the above spec, so application can use them. The Linux kernel were designed to abstract hardware differences. We should not move this task to userspace. I agree in principle, but we will have to rethink this at some point in the future. I don't think it will always be possible to handle all hardware abstractions in the kernel. Some hardware require floating point operations in their drivers for instance. I talked with Linus some years ago about float point ops in Kernel. He said he was not against that, but there are some issues, as float point processors are arch-dependent, and kernel doesn't save FP registers. So, if a driver really needs to use it, extra care should be taken. That's said, some drivers use fixed point operations for some specific usages. Issues arise when devices have floating point registers. And yes, that happens, I've learnt today about an I2C sensor with floating point registers (in this specific case it should probably be put in the broken design category, but it exists :-)). There's an industry trend there, and we need to think about solutions now otherwise we will be left without any way forward when too many devices will be impossible to support from kernelspace (OMAP4 is a good example there, some device drivers require communication with other cores, and the communication API is implemented in userspace). Needing to go to userspace to allow inter-core communication seems very bad. I seriously doubt that this is a trend. It seems more like a broken-by-design type of architecture. I'm inclined to agree with you, but we should address these issues now, while we have relatively few devices impacted by them. I fear that ignoring the problem and hoping it will go away by itself will bring us to a difficult position in the future. We should show the industry in which direction we would like it to go. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH FOR 2.6.40] uvcvideo patches
Em 25-05-2011 20:43, Laurent Pinchart escreveu: Issues arise when devices have floating point registers. And yes, that happens, I've learnt today about an I2C sensor with floating point registers (in this specific case it should probably be put in the broken design category, but it exists :-)). Huh! Yeah, an I2C sensor with FP registers sound weird. We need more details in order to address those. There's an industry trend there, and we need to think about solutions now otherwise we will be left without any way forward when too many devices will be impossible to support from kernelspace (OMAP4 is a good example there, some device drivers require communication with other cores, and the communication API is implemented in userspace). Needing to go to userspace to allow inter-core communication seems very bad. I seriously doubt that this is a trend. It seems more like a broken-by-design type of architecture. I'm inclined to agree with you, but we should address these issues now, while we have relatively few devices impacted by them. I fear that ignoring the problem and hoping it will go away by itself will bring us to a difficult position in the future. We should show the industry in which direction we would like it to go. I'm all about showing the industry in with direction we would like it to go. We want that all Linux-supported architectures/sub-architectures support inter-core communications in kernelspace, in a more efficient way that it would happen if such communication would happen in userspace. Thanks, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make code more readable by not using the return value of the WARN() macro. Set ret variable in an undefined case.
Em 23-05-2011 16:04, Hans Petter Selasky escreveu:
On Monday 23 May 2011 20:22:02 Guennadi Liakhovetski wrote:
Please, inline patches. Otherwise, this is what one gets, when replying.
On Mon, 23 May 2011, Hans Petter Selasky wrote:
--HPS
In any case, just throwing in my 2 cents - no idea how not using the
return value of WARN() makes code more readable. On the contrary, using it
is a standard practice. This patch doesn't seem like an improvement to me.
There is no strong reason for the WARN() part, you may ignore that, but the
ret = 0, part is still valid. Should I generate a new patch or can you handle
this?
Em 23-05-2011 08:07, Hans Petter Selasky escreveu:
--HPS
dvb-usb-0005.patch
From 94b88b92763f9309018ba04c200a8842ce1ff0ed Mon Sep 17 00:00:00 2001
From: Hans Petter Selasky hsela...@c2i.net
Date: Mon, 23 May 2011 13:07:08 +0200
Subject: [PATCH] Make code more readable by not using the return value of the
WARN() macro. Set ret variable in an undefined case.
Signed-off-by: Hans Petter Selasky hsela...@c2i.net
---
drivers/media/video/sr030pc30.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/sr030pc30.c b/drivers/media/video/sr030pc30.c
index c901721..6cc64c9 100644
--- a/drivers/media/video/sr030pc30.c
+++ b/drivers/media/video/sr030pc30.c
@@ -726,8 +726,10 @@ static int sr030pc30_s_power(struct v4l2_subdev *sd, int
on)
const struct sr030pc30_platform_data *pdata = info-pdata;
int ret;
- if (WARN(pdata == NULL, No platform data!\n))
+ if (pdata == NULL) {
+ WARN(1, No platform data!\n);
return -ENOMEM;
+ }
/*
* Put sensor into power sleep mode before switching off
@@ -746,6 +748,7 @@ static int sr030pc30_s_power(struct v4l2_subdev *sd, int
on)
if (on) {
ret = sr030pc30_base_config(sd);
} else {
+ ret = 0;
info-curr_win = NULL;
info-curr_fmt = NULL;
}
-- 1.7.1.1
IMHO, both hunks make sense, as, on the first hunk, it is returning an error
condition.
Yet, -ENOMEM seems to be the wrong return code. -EINVAL is probably more
appropriate.
However, the patch is badly described. It is not about making the code cleaner,
but
about avoiding to run s_power if no platform data is found, and to avoid having
ret undefined. Eventually, it should be broken into two different patches, as
they
fix different things.
Please, when sending us patches, provide a proper description with what
information
at the first line, and why and how at the patch descriptions. Please, also
avoid to
have any line bigger than 74 characters, otherwise they'll look weird when
seeing the
patch history.
Thanks,
Mauro.
information a
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5 v2] [media] ov9740: Fixed some settings
From: Andrew Chew ac...@nvidia.com
Based on vendor feedback, should issue a software reset at start of day.
Also, OV9740_ANALOG_CTRL15 needs to be changed so the sensor does not begin
streaming until it is ready (otherwise, results in a nonsense frame for the
initial frame).
For discontinuous clocks, need to change OV9740_MIPI_CTRL00.
Finally, OV9740_ISP_CTRL19 needs to be changed to really use YUYV ordering
(the previous value was for VYUY).
Signed-off-by: Andrew Chew ac...@nvidia.com
---
drivers/media/video/ov9740.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c
index d5c9061..9d7c74d 100644
--- a/drivers/media/video/ov9740.c
+++ b/drivers/media/video/ov9740.c
@@ -68,6 +68,7 @@
#define OV9740_ANALOG_CTRL04 0x3604
#define OV9740_ANALOG_CTRL10 0x3610
#define OV9740_ANALOG_CTRL12 0x3612
+#define OV9740_ANALOG_CTRL15 0x3615
#define OV9740_ANALOG_CTRL20 0x3620
#define OV9740_ANALOG_CTRL21 0x3621
#define OV9740_ANALOG_CTRL22 0x3622
@@ -222,6 +223,9 @@ struct ov9740_priv {
};
static const struct ov9740_reg ov9740_defaults[] = {
+ /* Software Reset */
+ { OV9740_SOFTWARE_RESET,0x01 },
+
/* Banding Filter */
{ OV9740_AEC_B50_STEP_HI, 0x00 },
{ OV9740_AEC_B50_STEP_LO, 0xe8 },
@@ -333,6 +337,7 @@ static const struct ov9740_reg ov9740_defaults[] = {
{ OV9740_ANALOG_CTRL10, 0xa1 },
{ OV9740_ANALOG_CTRL12, 0x24 },
{ OV9740_ANALOG_CTRL22, 0x9f },
+ { OV9740_ANALOG_CTRL15, 0xf0 },
/* Sensor Control */
{ OV9740_SENSOR_CTRL03, 0x42 },
@@ -385,7 +390,7 @@ static const struct ov9740_reg ov9740_defaults[] = {
{ OV9740_LN_LENGTH_PCK_LO, 0x62 },
/* MIPI Control */
- { OV9740_MIPI_CTRL00, 0x44 },
+ { OV9740_MIPI_CTRL00, 0x64 }, /* 0x44 for continuous clock */
{ OV9740_MIPI_3837, 0x01 },
{ OV9740_MIPI_CTRL01, 0x0f },
{ OV9740_MIPI_CTRL03, 0x05 },
@@ -393,6 +398,9 @@ static const struct ov9740_reg ov9740_defaults[] = {
{ OV9740_VFIFO_RD_CTRL, 0x16 },
{ OV9740_MIPI_CTRL_3012,0x70 },
{ OV9740_SC_CMMM_MIPI_CTR, 0x01 },
+
+ /* YUYV order */
+ { OV9740_ISP_CTRL19,0x02 },
};
static const struct ov9740_reg ov9740_regs_vga[] = {
--
1.7.5.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5 v2] [media] ov9740: Cleanup hex casing inconsistencies
From: Andrew Chew ac...@nvidia.com Made all hex number casing use lower-case throughout the entire driver for consistency. Signed-off-by: Andrew Chew ac...@nvidia.com --- drivers/media/video/ov9740.c | 111 +- 1 files changed, 55 insertions(+), 56 deletions(-) diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c index 4d4ee4f..96811e4 100644 --- a/drivers/media/video/ov9740.c +++ b/drivers/media/video/ov9740.c @@ -44,12 +44,12 @@ #define OV9740_Y_ADDR_START_LO 0x0347 #define OV9740_X_ADDR_END_HI 0x0348 #define OV9740_X_ADDR_END_LO 0x0349 -#define OV9740_Y_ADDR_END_HI 0x034A -#define OV9740_Y_ADDR_END_LO 0x034B -#define OV9740_X_OUTPUT_SIZE_HI0x034C -#define OV9740_X_OUTPUT_SIZE_LO0x034D -#define OV9740_Y_OUTPUT_SIZE_HI0x034E -#define OV9740_Y_OUTPUT_SIZE_LO0x034F +#define OV9740_Y_ADDR_END_HI 0x034a +#define OV9740_Y_ADDR_END_LO 0x034b +#define OV9740_X_OUTPUT_SIZE_HI0x034c +#define OV9740_X_OUTPUT_SIZE_LO0x034d +#define OV9740_Y_OUTPUT_SIZE_HI0x034e +#define OV9740_Y_OUTPUT_SIZE_LO0x034f /* IO Control Registers */ #define OV9740_IO_CREL00 0x3002 @@ -89,28 +89,28 @@ #define OV9740_TIMING_CTRL35 0x3835 /* Banding Filter */ -#define OV9740_AEC_MAXEXPO_60_H0x3A02 -#define OV9740_AEC_MAXEXPO_60_L0x3A03 -#define OV9740_AEC_B50_STEP_HI 0x3A08 -#define OV9740_AEC_B50_STEP_LO 0x3A09 -#define OV9740_AEC_B60_STEP_HI 0x3A0A -#define OV9740_AEC_B60_STEP_LO 0x3A0B -#define OV9740_AEC_CTRL0D 0x3A0D -#define OV9740_AEC_CTRL0E 0x3A0E -#define OV9740_AEC_MAXEXPO_50_H0x3A14 -#define OV9740_AEC_MAXEXPO_50_L0x3A15 +#define OV9740_AEC_MAXEXPO_60_H0x3a02 +#define OV9740_AEC_MAXEXPO_60_L0x3a03 +#define OV9740_AEC_B50_STEP_HI 0x3a08 +#define OV9740_AEC_B50_STEP_LO 0x3a09 +#define OV9740_AEC_B60_STEP_HI 0x3a0a +#define OV9740_AEC_B60_STEP_LO 0x3a0b +#define OV9740_AEC_CTRL0D 0x3a0d +#define OV9740_AEC_CTRL0E 0x3a0e +#define OV9740_AEC_MAXEXPO_50_H0x3a14 +#define OV9740_AEC_MAXEXPO_50_L0x3a15 /* AEC/AGC Control */ #define OV9740_AEC_ENABLE 0x3503 -#define OV9740_GAIN_CEILING_01 0x3A18 -#define OV9740_GAIN_CEILING_02 0x3A19 -#define OV9740_AEC_HI_THRESHOLD0x3A11 -#define OV9740_AEC_3A1A0x3A1A -#define OV9740_AEC_CTRL1B_WPT2 0x3A1B -#define OV9740_AEC_CTRL0F_WPT 0x3A0F -#define OV9740_AEC_CTRL10_BPT 0x3A10 -#define OV9740_AEC_CTRL1E_BPT2 0x3A1E -#define OV9740_AEC_LO_THRESHOLD0x3A1F +#define OV9740_GAIN_CEILING_01 0x3a18 +#define OV9740_GAIN_CEILING_02 0x3a19 +#define OV9740_AEC_HI_THRESHOLD0x3a11 +#define OV9740_AEC_3A1A0x3a1a +#define OV9740_AEC_CTRL1B_WPT2 0x3a1b +#define OV9740_AEC_CTRL0F_WPT 0x3a0f +#define OV9740_AEC_CTRL10_BPT 0x3a10 +#define OV9740_AEC_CTRL1E_BPT2 0x3a1e +#define OV9740_AEC_LO_THRESHOLD0x3a1f /* BLC Control */ #define OV9740_BLC_AUTO_ENABLE 0x4002 @@ -132,7 +132,7 @@ #define OV9740_VT_SYS_CLK_DIV 0x0303 #define OV9740_VT_PIX_CLK_DIV 0x0301 #define OV9740_PLL_CTRL30100x3010 -#define OV9740_VFIFO_CTRL000x460E +#define OV9740_VFIFO_CTRL000x460e /* ISP Control */ #define OV9740_ISP_CTRL00 0x5000 @@ -141,9 +141,9 @@ #define OV9740_ISP_CTRL05 0x5005 #define OV9740_ISP_CTRL12 0x5012 #define OV9740_ISP_CTRL19 0x5019 -#define OV9740_ISP_CTRL1A 0x501A -#define OV9740_ISP_CTRL1E 0x501E -#define OV9740_ISP_CTRL1F 0x501F +#define OV9740_ISP_CTRL1A 0x501a +#define OV9740_ISP_CTRL1E 0x501e +#define OV9740_ISP_CTRL1F 0x501f #define OV9740_ISP_CTRL20 0x5020 #define OV9740_ISP_CTRL21 0x5021 @@ -158,12 +158,12 @@ #define OV9740_AWB_ADV_CTRL04 0x5187 #define OV9740_AWB_ADV_CTRL05 0x5188 #define OV9740_AWB_ADV_CTRL06 0x5189 -#define OV9740_AWB_ADV_CTRL07 0x518A -#define OV9740_AWB_ADV_CTRL08 0x518B -#define OV9740_AWB_ADV_CTRL09 0x518C -#define OV9740_AWB_ADV_CTRL10 0x518D -#define OV9740_AWB_ADV_CTRL11 0x518E -#define OV9740_AWB_CTRL0F 0x518F +#define OV9740_AWB_ADV_CTRL07 0x518a +#define OV9740_AWB_ADV_CTRL08 0x518b +#define OV9740_AWB_ADV_CTRL09 0x518c +#define OV9740_AWB_ADV_CTRL10 0x518d +#define
Re: [PATCH] Make nchg variable signed because the code compares this variable against negative values.
Jean-François,
This patch looks ok to me, although the description is not 100%.
The sonixj driver compares the value for nchg with
if (sd-nchg -6 || sd-nchg = 12) {
With u8, negative values won't work.
Please check.
Thanks!
Mauro
Em 23-05-2011 08:09, Hans Petter Selasky escreveu:
--HPS
dvb-usb-0006.patch
From b05d4913df24f11c7b7a2e07201bb87a04a949bc Mon Sep 17 00:00:00 2001
From: Hans Petter Selasky hsela...@c2i.net
Date: Mon, 23 May 2011 13:09:18 +0200
Subject: [PATCH] Make nchg variable signed because the code compares this
variable against negative values.
Signed-off-by: Hans Petter Selasky hsela...@c2i.net
---
drivers/media/video/gspca/sonixj.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/gspca/sonixj.c
b/drivers/media/video/gspca/sonixj.c
index 6415aff..81b8a60 100644
--- a/drivers/media/video/gspca/sonixj.c
+++ b/drivers/media/video/gspca/sonixj.c
@@ -60,7 +60,7 @@ struct sd {
u32 pktsz; /* (used by pkt_scan) */
u16 npkt;
- u8 nchg;
+ s8 nchg;
s8 short_mark;
u8 quality; /* image quality */
-- 1.7.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5 v2] [media] ov9740: Remove hardcoded resolution regs
From: Andrew Chew ac...@nvidia.com
Derive resolution-dependent register settings programmatically.
Signed-off-by: Andrew Chew ac...@nvidia.com
---
drivers/media/video/ov9740.c | 210 +++---
1 files changed, 114 insertions(+), 96 deletions(-)
diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c
index 9d7c74d..6c28ae8 100644
--- a/drivers/media/video/ov9740.c
+++ b/drivers/media/video/ov9740.c
@@ -181,27 +181,8 @@
#define OV9740_MIPI_CTRL_3012 0x3012
#define OV9740_SC_CMMM_MIPI_CTR0x3014
-/* supported resolutions */
-enum {
- OV9740_VGA,
- OV9740_720P,
-};
-
-struct ov9740_resolution {
- unsigned int width;
- unsigned int height;
-};
-
-static struct ov9740_resolution ov9740_resolutions[] = {
- [OV9740_VGA] = {
- .width = 640,
- .height = 480,
- },
- [OV9740_720P] = {
- .width = 1280,
- .height = 720,
- },
-};
+#define OV9740_MAX_WIDTH 1280
+#define OV9740_MAX_HEIGHT 720
/* Misc. structures */
struct ov9740_reg {
@@ -403,54 +384,6 @@ static const struct ov9740_reg ov9740_defaults[] = {
{ OV9740_ISP_CTRL19,0x02 },
};
-static const struct ov9740_reg ov9740_regs_vga[] = {
- { OV9740_X_ADDR_START_HI, 0x00 },
- { OV9740_X_ADDR_START_LO, 0xa0 },
- { OV9740_Y_ADDR_START_HI, 0x00 },
- { OV9740_Y_ADDR_START_LO, 0x00 },
- { OV9740_X_ADDR_END_HI, 0x04 },
- { OV9740_X_ADDR_END_LO, 0x63 },
- { OV9740_Y_ADDR_END_HI, 0x02 },
- { OV9740_Y_ADDR_END_LO, 0xd3 },
- { OV9740_X_OUTPUT_SIZE_HI, 0x02 },
- { OV9740_X_OUTPUT_SIZE_LO, 0x80 },
- { OV9740_Y_OUTPUT_SIZE_HI, 0x01 },
- { OV9740_Y_OUTPUT_SIZE_LO, 0xe0 },
- { OV9740_ISP_CTRL1E,0x03 },
- { OV9740_ISP_CTRL1F,0xc0 },
- { OV9740_ISP_CTRL20,0x02 },
- { OV9740_ISP_CTRL21,0xd0 },
- { OV9740_VFIFO_READ_START_HI, 0x01 },
- { OV9740_VFIFO_READ_START_LO, 0x40 },
- { OV9740_ISP_CTRL00,0xff },
- { OV9740_ISP_CTRL01,0xff },
- { OV9740_ISP_CTRL03,0xff },
-};
-
-static const struct ov9740_reg ov9740_regs_720p[] = {
- { OV9740_X_ADDR_START_HI, 0x00 },
- { OV9740_X_ADDR_START_LO, 0x00 },
- { OV9740_Y_ADDR_START_HI, 0x00 },
- { OV9740_Y_ADDR_START_LO, 0x00 },
- { OV9740_X_ADDR_END_HI, 0x05 },
- { OV9740_X_ADDR_END_LO, 0x03 },
- { OV9740_Y_ADDR_END_HI, 0x02 },
- { OV9740_Y_ADDR_END_LO, 0xd3 },
- { OV9740_X_OUTPUT_SIZE_HI, 0x05 },
- { OV9740_X_OUTPUT_SIZE_LO, 0x00 },
- { OV9740_Y_OUTPUT_SIZE_HI, 0x02 },
- { OV9740_Y_OUTPUT_SIZE_LO, 0xd0 },
- { OV9740_ISP_CTRL1E,0x05 },
- { OV9740_ISP_CTRL1F,0x00 },
- { OV9740_ISP_CTRL20,0x02 },
- { OV9740_ISP_CTRL21,0xd0 },
- { OV9740_VFIFO_READ_START_HI, 0x02 },
- { OV9740_VFIFO_READ_START_LO, 0x30 },
- { OV9740_ISP_CTRL00,0xff },
- { OV9740_ISP_CTRL01,0xef },
- { OV9740_ISP_CTRL03,0xff },
-};
-
static enum v4l2_mbus_pixelcode ov9740_codes[] = {
V4L2_MBUS_FMT_YUYV8_2X8,
};
@@ -727,39 +660,124 @@ static int ov9740_set_register(struct v4l2_subdev *sd,
/* select nearest higher resolution for capture */
static void ov9740_res_roundup(u32 *width, u32 *height)
{
- int i;
+ /* Width must be a multiple of 4 pixels. */
+ *width += *width % 4;
- for (i = 0; i ARRAY_SIZE(ov9740_resolutions); i++)
- if ((ov9740_resolutions[i].width = *width)
- (ov9740_resolutions[i].height = *height)) {
- *width = ov9740_resolutions[i].width;
- *height = ov9740_resolutions[i].height;
- return;
- }
+ /* Max resolution is 1280x720 (720p). */
+ if (*width OV9740_MAX_WIDTH)
+ *width = OV9740_MAX_WIDTH;
- *width = ov9740_resolutions[OV9740_720P].width;
- *height = ov9740_resolutions[OV9740_720P].height;
+ if (*height OV9740_MAX_HEIGHT)
+ *height = OV9740_MAX_HEIGHT;
}
/* Setup registers according to resolution and color encoding */
-static int ov9740_set_res(struct i2c_client *client, u32 width)
+static int ov9740_set_res(struct i2c_client *client, u32 width, u32 height)
{
+ u32 x_start;
+ u32 y_start;
+ u32 x_end;
+ u32 y_end;
+ bool scaling = 0;
+ u32 scale_input_x;
+ u32 scale_input_y;
int ret;
- /* select register configuration for given resolution */
- if (width ==
[PATCH 2/5 v2] [media] ov9740: Correct print in ov9740_reg_rmw()
From: Andrew Chew ac...@nvidia.com
The register width of the ov9740 is 16-bits, so correct the debug print
to reflect this.
Signed-off-by: Andrew Chew ac...@nvidia.com
---
drivers/media/video/ov9740.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c
index 96811e4..d5c9061 100644
--- a/drivers/media/video/ov9740.c
+++ b/drivers/media/video/ov9740.c
@@ -537,7 +537,8 @@ static int ov9740_reg_rmw(struct i2c_client *client, u16
reg, u8 set, u8 unset)
ret = ov9740_reg_read(client, reg, val);
if (ret 0) {
dev_err(client-dev,
- [Read]-Modify-Write of register %02x failed!\n, reg);
+ [Read]-Modify-Write of register 0x%04x failed!\n,
+ reg);
return ret;
}
@@ -547,7 +548,8 @@ static int ov9740_reg_rmw(struct i2c_client *client, u16
reg, u8 set, u8 unset)
ret = ov9740_reg_write(client, reg, val);
if (ret 0) {
dev_err(client-dev,
- Read-Modify-[Write] of register %02x failed!\n, reg);
+ Read-Modify-[Write] of register 0x%04x failed!\n,
+ reg);
return ret;
}
--
1.7.5.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5 v2] [media] ov9740: Add suspend/resume
From: Andrew Chew ac...@nvidia.com
On suspend, remember whether we are streaming or not, and at what frame format,
so that on resume, we can start streaming again.
Signed-off-by: Andrew Chew ac...@nvidia.com
---
drivers/media/video/ov9740.c | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c
index 6c28ae8..4abe943 100644
--- a/drivers/media/video/ov9740.c
+++ b/drivers/media/video/ov9740.c
@@ -201,6 +201,10 @@ struct ov9740_priv {
boolflag_vflip;
boolflag_hflip;
+
+ /* For suspend/resume. */
+ struct v4l2_mbus_framefmt current_mf;
+ int current_enable;
};
static const struct ov9740_reg ov9740_defaults[] = {
@@ -551,6 +555,8 @@ static int ov9740_s_stream(struct v4l2_subdev *sd, int
enable)
0x00);
}
+ priv-current_enable = enable;
+
return ret;
}
@@ -786,6 +792,7 @@ static int ov9740_s_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov9740_priv *priv = to_ov9740(sd);
enum v4l2_colorspace cspace;
enum v4l2_mbus_pixelcode code = mf-code;
int ret;
@@ -812,6 +819,8 @@ static int ov9740_s_fmt(struct v4l2_subdev *sd,
mf-code= code;
mf-colorspace = cspace;
+ memcpy(priv-current_mf, mf, sizeof(struct v4l2_mbus_framefmt));
+
return ret;
}
@@ -922,7 +931,37 @@ err:
return ret;
}
+static int ov9740_suspend(struct soc_camera_device *icd, pm_message_t state)
+{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ struct ov9740_priv *priv = to_ov9740(sd);
+
+ if (priv-current_enable) {
+ int current_enable = priv-current_enable;
+
+ ov9740_s_stream(sd, 0);
+ priv-current_enable = current_enable;
+ }
+
+ return 0;
+}
+
+static int ov9740_resume(struct soc_camera_device *icd)
+{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ struct ov9740_priv *priv = to_ov9740(sd);
+
+ if (priv-current_enable) {
+ ov9740_s_fmt(sd, priv-current_mf);
+ ov9740_s_stream(sd, priv-current_enable);
+ }
+
+ return 0;
+}
+
static struct soc_camera_ops ov9740_ops = {
+ .suspend= ov9740_suspend,
+ .resume = ov9740_resume,
.set_bus_param = ov9740_set_bus_param,
.query_bus_param= ov9740_query_bus_param,
.controls = ov9740_controls,
--
1.7.5.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] The USB_SPEED... keywords are already defined by the USB stack. Rename currently unused macros to avoid possible future warnings and errors.
Em 23-05-2011 08:19, Hans Petter Selasky escreveu: --HPS dvb-usb-0001.patch From f7a0f7254da47ff88f69314f14043b01ba0764eb Mon Sep 17 00:00:00 2001 From: Hans Petter Selasky hsela...@c2i.net Date: Mon, 23 May 2011 12:43:50 +0200 Subject: [PATCH] The USB_SPEED_XXX keywords are already defined by the USB stack. Rename currently unused macros to avoid possible future warnings and errors. Signed-off-by: Hans Petter Selasky hsela...@c2i.net --- drivers/media/dvb/dvb-usb/gp8psk.h |6 +++--- drivers/media/dvb/dvb-usb/vp7045.h |6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/gp8psk.h b/drivers/media/dvb/dvb-usb/gp8psk.h index 831749a..c271b68 100644 --- a/drivers/media/dvb/dvb-usb/gp8psk.h +++ b/drivers/media/dvb/dvb-usb/gp8psk.h @@ -78,9 +78,9 @@ extern int dvb_usb_gp8psk_debug; #define ADV_MOD_DVB_BPSK 9 /* DVB-S BPSK */ #define GET_USB_SPEED 0x07 - #define USB_SPEED_LOW0 - #define USB_SPEED_FULL 1 - #define USB_SPEED_HIGH 2 + #define TH_USB_SPEED_LOW 0 + #define TH_USB_SPEED_FULL1 + #define TH_USB_SPEED_HIGH2 #define RESET_FX2 0x13 diff --git a/drivers/media/dvb/dvb-usb/vp7045.h b/drivers/media/dvb/dvb-usb/vp7045.h index 969688f..7ce6c00 100644 --- a/drivers/media/dvb/dvb-usb/vp7045.h +++ b/drivers/media/dvb/dvb-usb/vp7045.h @@ -36,9 +36,9 @@ #define Tuner_Power_OFF 0 #define GET_USB_SPEED 0x07 - #define USB_SPEED_LOW0 - #define USB_SPEED_FULL 1 - #define USB_SPEED_HIGH 2 + #define TH_USB_SPEED_LOW 0 + #define TH_USB_SPEED_FULL1 + #define TH_USB_SPEED_HIGH2 #define LOCK_TUNER_COMMAND0x09 Nah. Those vars are unused on those drivers. Just remove them. Thanks! Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Define parameter description after the parameter itself.
Em 23-05-2011 08:27, Hans Petter Selasky escreveu: --HPS dvb-usb-0008.patch From 2f5378e5c5cc5528473f77321879fb075005d3dd Mon Sep 17 00:00:00 2001 From: Hans Petter Selasky hsela...@c2i.net Date: Mon, 23 May 2011 13:26:04 +0200 Subject: [PATCH] Define parameter description after the parameter itself. Signed-off-by: Hans Petter Selasky hsela...@c2i.net --- drivers/media/video/tda7432.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/tda7432.c b/drivers/media/video/tda7432.c index 3941f95..398b9fb 100644 --- a/drivers/media/video/tda7432.c +++ b/drivers/media/video/tda7432.c @@ -50,8 +50,8 @@ static int loudness; /* disable loudness by default */ static int debug; /* insmod parameter */ module_param(debug, int, S_IRUGO | S_IWUSR); module_param(loudness, int, S_IRUGO); -MODULE_PARM_DESC(maxvol,Set maximium volume to +20db (0), default is 0db(1)); module_param(maxvol, int, S_IRUGO | S_IWUSR); +MODULE_PARM_DESC(maxvol,Set maximium volume to +20db (0), default is 0db(1)); Ok, but this doesn't change the fact that debug and loudness aren't commented. Could you please also add descriptions for those parameters where no descriptions were provided? Thanks! Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] [resend] radio-sf16fmr2: convert to generic TEA575x interface
Em 23-05-2011 09:17, Ondrej Zary escreveu:
Convert radio-sf16fmr2 to use generic TEA575x implementation. Most of the
driver code goes away as SF16-FMR2 is basically just a TEA5757 tuner
connected to ISA bus.
The card can optionally be equipped with PT2254A volume control (equivalent
of TC9154AP) - the volume setting is completely reworked (with balance control
added) and tested.
Ondrej,
As your first series went via alsa tree, and we are close to the end of the
merge window,
and assuming that Takashi didn't apply those patches on his tree, as you're
re-sending it,
I think that the better is to wait for the end of the merge window, in order to
allow us
to sync our development tree with 2.6.40-rc1, and then review and apply it on
the top of it.
Thanks,
Mauro.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/sound/pci/Kconfig 2011-05-15 18:50:18.0
+0200
+++ linux-2.6.39-rc2/sound/pci/Kconfig2011-05-17 23:35:30.0
+0200
@@ -565,8 +565,8 @@ config SND_FM801_TEA575X_BOOL
config SND_TEA575X
tristate
- depends on SND_FM801_TEA575X_BOOL || SND_ES1968_RADIO
- default SND_FM801 || SND_ES1968
+ depends on SND_FM801_TEA575X_BOOL || SND_ES1968_RADIO || RADIO_SF16FMR2
+ default SND_FM801 || SND_ES1968 || RADIO_SF16FMR2
source sound/pci/hda/Kconfig
--- linux-2.6.39-rc2-/drivers/media/radio/radio-sf16fmr2.c2011-04-06
03:30:43.0 +0200
+++ linux-2.6.39-rc2/drivers/media/radio/radio-sf16fmr2.c 2011-05-19
17:56:08.0 +0200
@@ -1,441 +1,209 @@
-/* SF16FMR2 radio driver for Linux radio support
- * heavily based on fmi driver...
- * (c) 2000-2002 Ziglio Frediano, fredd...@angelfire.com
+/* SF16-FMR2 radio driver for Linux
+ * Copyright (c) 2011 Ondrej Zary
*
- * Notes on the hardware
- *
- * Frequency control is done digitally -- ie out(port,encodefreq(95.8));
- * No volume control - only mute/unmute - you have to use line volume
- *
- * For read stereo/mono you must wait 0.1 sec after set frequency and
- * card unmuted so I set frequency on unmute
- * Signal handling seem to work only on autoscanning (not implemented)
- *
- * Converted to V4L2 API by Mauro Carvalho Chehab mche...@infradead.org
+ * Original driver was (c) 2000-2002 Ziglio Frediano, fredd...@angelfire.com
+ * but almost nothing remained here after conversion to generic TEA575x
+ * implementation
*/
+#include linux/delay.h
#include linux/module.h/* Modules */
#include linux/init.h /* Initdata */
#include linux/ioport.h/* request_region */
-#include linux/delay.h /* udelay */
-#include linux/videodev2.h /* kernel radio structs */
-#include linux/mutex.h
-#include linux/version.h /* for KERNEL_VERSION MACRO */
#include linux/io.h/* outb, outb_p */
-#include media/v4l2-device.h
-#include media/v4l2-ioctl.h
+#include sound/tea575x-tuner.h
-MODULE_AUTHOR(Ziglio Frediano, fredd...@angelfire.com);
-MODULE_DESCRIPTION(A driver for the SF16FMR2 radio.);
+MODULE_AUTHOR(Ondrej Zary);
+MODULE_DESCRIPTION(MediaForte SF16-FMR2 FM radio card driver);
MODULE_LICENSE(GPL);
-static int io = 0x384;
-static int radio_nr = -1;
-
-module_param(io, int, 0);
-MODULE_PARM_DESC(io, I/O address of the SF16FMR2 card (should be 0x384, if
do not work try 0x284));
-module_param(radio_nr, int, 0);
-
-#define RADIO_VERSION KERNEL_VERSION(0,0,2)
-
-#define AUD_VOL_INDEX 1
-
-#undef DEBUG
-//#define DEBUG 1
-
-#ifdef DEBUG
-# define debug_print(s) printk s
-#else
-# define debug_print(s)
-#endif
-
-/* this should be static vars for module size */
-struct fmr2
-{
- struct v4l2_device v4l2_dev;
- struct video_device vdev;
- struct mutex lock;
+struct fmr2 {
int io;
- int curvol; /* 0-15 */
- int mute;
- int stereo; /* card is producing stereo audio */
- unsigned long curfreq; /* freq in kHz */
- int card_type;
+ struct snd_tea575x tea;
+ struct v4l2_ctrl *volume;
+ struct v4l2_ctrl *balance;
};
+/* the port is hardwired so no need to support multiple cards */
+#define FMR2_PORT0x384
static struct fmr2 fmr2_card;
-/* hw precision is 12.5 kHz
- * It is only useful to give freq in interval of 200 (=0.0125Mhz),
- * other bits will be truncated
- */
-#define RSF16_ENCODE(x) ((x) / 200 + 856)
-#define RSF16_MINFREQ (87 * 16000)
-#define RSF16_MAXFREQ (108 * 16000)
-
-static inline void wait(int n, int io)
-{
- for (; n; --n)
- inb(io);
-}
-
-static void outbits(int bits, unsigned int data, int nWait, int io)
-{
- int bit;
-
- for (; --bits = 0;) {
- bit = (data bits) 1;
- outb(bit, io);
- wait(nWait, io);
- outb(bit | 2, io);
-
Re: [GIT PATCHES FOR 2.6.40] Fixes
Em 25-05-2011 05:27, Hans Verkuil escreveu: On Tuesday, May 24, 2011 08:28:32 Hans Verkuil wrote: On Tuesday, May 24, 2011 03:42:32 Mauro Carvalho Chehab wrote: Em 23-05-2011 08:06, Hans Verkuil escreveu: Hi Mauro, Here are a few fixes: the first fixes a bug in the wl12xx drivers (I hope Matti's email is still correct). The second fixes a few DocBook validation errors, and the last fixes READ_ONLY and GRABBED handling in the control framework. Regards, Hans The following changes since commit 87cf028f3aa1ed51fe29c36df548aa714dc7438f: [media] dm1105: GPIO handling added, I2C on GPIO added, LNB control through GPIO reworked (2011-05-21 11:10:28 -0300) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git fixes Hans Verkuil (3): wl12xx: g_volatile_ctrl fix: wrong field set. Media DocBook: fix validation errors. The two above are fixes... v4l2-ctrls: drivers should be able to ignore READ_ONLY and GRABBED flags But this one is a change at the behaviour. I need to analyse it better. The idea of a read only control that it is not read only seems too weird on my tired eyes. It's read-only for *applications*. But if you have a read-only control that reflects a driver state, then it should be possible for a *driver* to change it. It's something that is needed for the upcoming Flash and HDMI APIs. The userspace behavior does not change. BTW, if you prefer to move this last patch to 2.6.41, then that's OK by me. It's not really necessary for 2.6.40. I'm going to move this patch to 2.6.41, so there is no need for you to review this. I'll include it in another patch series I'm working on. Ok, I'll remove it from my queue. Thanks, Mauro Regards, Hans Regards, Hans I'll take a more careful look on it tomorrow. Thanks, Mauro. Documentation/DocBook/dvb/dvbproperty.xml|5 ++- Documentation/DocBook/v4l/subdev-formats.xml | 10 ++-- drivers/media/radio/radio-wl1273.c |2 +- drivers/media/radio/wl128x/fmdrv_v4l2.c |2 +- drivers/media/video/v4l2-ctrls.c | 59 +- 5 files changed, 50 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About RFC of HDMI-CEC
Hello,
On 05/25/2011 06:13 PM, Martin Bugge (marbugge) wrote:
Hello
To be honest I became a bit disengaded after all the discussion.
What caused me a lot of problems was the request for AV link support
(which is used in SCART connectors).
Something I never plan to implement.
But after the v4l2 Warsaw Brainstroming meeting it was sort of approved.
It only need to be reworked to be a subdev level api.
(for that I need some help from Hans Verkuil)
But it is great that someone else also need an API for this.
I include the latest version here so you can see if you agree, and
together we will get it in.
Yes, sure.
We currently have two drivers which uses this API for CEC.
* Analog Devices adv7604
* TMS320DM8x
i want to see source code of these two drivers.From where i can get
source code of these drivers??
Thanks and Regards
Vipul Kumar Samar
At least the adv7604 is planned to be upstreamed.
Best regards
Martin Bugge
On 05/25/2011 01:52 PM, vipul kumar samar wrote:
Hello,
I am working on HDMI-CEC and planning to implement it in v4l2
framework.I came to know that a RFC is going on for the same driver.
I want to know is their any friezed version of that RFC or discussion
is still going on?? Is it included in kernel??
Thanks and Regards
Vipul Kumar Samar
--
You won't skid if you stay in a rut. -- Frank Hubbard
Author: Martin Bugge marbu...@cisco.com
Date: Thu, 17th of March 2011
==
This is a proposal for adding a Consumer Electronic Control (CEC) API to V4L2.
This document describes the changes and new ioctls needed.
Version 1.
Initial version.
Version 2.
Added support for AV.link EN 50157-2-[123].
Version 3.
Rework of mode 1.
Mode 3 is to be decided (TDB).
Minor cleanup.
Background
==
CEC is a protocol that provides high-level control functions between various
audiovisual products.
It is an optional supplement to the High-Definition Multimedia Interface
Specification (HDMI).
In short: CEC uses pin 13 on the HDMI connector to transmit and receive small
data-packets
(maximum 16 bytes including a 1 byte header) at low data rates (~400
bits/s).
A CEC device may have any of 15 logical addresses (0 - 14).
(address 15 is broadcast and some addresses are reserved)
Physical layer is a one-wire bidirectional serial bus that uses the
industry-standard AV.link, see [3].
Due to this the proposed ioctls and events are meant to cover expansion for the
protocols in [3].
Note that AV.link mode 3 is still TBD.
References
==
[1] High-Definition Multimedia Interface Specification version 1.3a,
Supplement 1 Consumer Electronic Control (CEC).
http://www.hdmi.org/manufacturer/specification.aspx
[2] http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
[3] Domestic and similar electronic equipment interconnection requirements
AV.link. EN 50157-2-[123]
Proposed solution
=
Two new ioctls:
VIDIOC_AV_LINK_CAP (read)
VIDIOC_AV_LINK_CMD (read/write)
VIDIOC_AV_LINK_CAP:
---
#define AV_LINK_CAP_MODE_CEC (1 0)
#define AV_LINK_CAP_MODE_1 (1 1)
#define AV_LINK_CAP_MODE_2 (1 2)
#define AV_LINK_CAP_MODE_3 (1 3)
Note about AV.Link Mode 3: TBD
Different manufactures might have different implementations and an option is to
have a mode per implementation.
struct vl2_av_link_cap {
__u32 capabilities;
__u32 logicaldevices;
__u32 reserved[14];
};
The capabilities field will indicate which protocols/formats this HW supports.
* AV link mode CEC:
logicaldevices: 1 - 14, this HW supports n logical devices simultaneously.
* AV link mode 1:
logicaldevices: not used.
* AV link mode 2:
Same as AV link mode CEC.
* AV link mode 3: TBD
reserved: for future use.
VIDIOC_AV_LINK_CMD:
---
The command ioctl is used both for configuration and to receive/transmit data.
/* mode 1 */
struct avl_mode1_conf {
__u32 enable;
__u32 upstream_arb_mask;
__u32 downstream_arb_mask;
};
struct avl_mode1 {
__u32 ctrl_signal_frame;
__u32 tx_frame_arb;
__u32 tx_status;
};
/* mode 2, CEC and possible mode 3 */
struct avl_conf {
__u32 enable;
__u32 index;
__u32 addr;
};
struct avl {
__u32 len;
__u8 msg[16];
__u32 tx_status;
};
struct v4l2_av_link_cmd {
__u32 command;
__u32 mode;
__u32 reserved[2];
union {
struct avl_mode1_conf avlm1_conf;
struct avl_mode1 avlm1;
struct avl_conf conf;
struct avl avl;
__u32 raw[12];
};
};
/* command */
#define V4L2_AV_LINK_CMD_CONF (1)
#define V4L2_AV_LINK_CMD_TX (2)
#define V4L2_AV_LINK_CMD_RX (3)
/* mode */
#define AV_LINK_CMD_MODE_CEC (1)
#define AV_LINK_CMD_MODE_1 (2)
#define AV_LINK_CMD_MODE_2 (3)
#define AV_LINK_CMD_MODE_3 (4)
/* Tx status */
#define V4L2_AV_LINK_STAT_TX_OK
