[PATCH] Add CHIP ID of the uPD61151
Hi Add CHIP ID of the NEC MPEG2 encoders uPD61151 and uPD61152. diff -r b6b82258cf5e linux/include/media/v4l2-chip-ident.h --- a/linux/include/media/v4l2-chip-ident.h Thu Dec 31 19:14:54 2009 -0200 +++ b/linux/include/media/v4l2-chip-ident.h Wed Mar 17 04:53:52 2010 +0900 @@ -278,6 +278,11 @@ /* module cs53132a: just ident 53132 */ V4L2_IDENT_CS53l32A = 53132, + /* modules upd61151 MPEG2 encoder: just ident 54000 */ + V4L2_IDENT_UPD61161 = 54000, + /* modules upd61152 MPEG2 encoder with AC3: just ident 54001 */ + V4L2_IDENT_UPD61162 = 54001, + /* module upd64031a: just ident 64031 */ V4L2_IDENT_UPD64031A = 64031, Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com With my best regards, Dmitry. diff -r b6b82258cf5e linux/include/media/v4l2-chip-ident.h --- a/linux/include/media/v4l2-chip-ident.h Thu Dec 31 19:14:54 2009 -0200 +++ b/linux/include/media/v4l2-chip-ident.h Wed Mar 17 04:53:52 2010 +0900 @@ -278,6 +278,11 @@ /* module cs53132a: just ident 53132 */ V4L2_IDENT_CS53l32A = 53132, + /* modules upd61151 MPEG2 encoder: just ident 54000 */ + V4L2_IDENT_UPD61161 = 54000, + /* modules upd61152 MPEG2 encoder with AC3: just ident 54001 */ + V4L2_IDENT_UPD61162 = 54001, + /* module upd64031a: just ident 64031 */ V4L2_IDENT_UPD64031A = 64031, Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
[GIT PATCHES FOR 2.6.35] gspca for_2.6.35
Hi Mauro, The following changes since commit 52744e816710ed65e6fc34b79149268d95b2ebdf: Hans Verkuil (1): V4L/DVB: v4l2: sort chip IDs in v4l2-chip-ident.h are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_2.6.35 Jean-François Moine (2): gspca - sonixj: More static const and better array initialization. gspca - sonixj: Add webcam 0c45:6142 with sensors gc0307 and po2030n. Documentation/video4linux/gspca.txt |1 + drivers/media/video/gspca/sonixj.c | 433 +-- 2 files changed, 368 insertions(+), 66 deletions(-) Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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} V4L: do not autoselect components on embedded systems
Tuner, DVB frontend and video helper chip drivers are by default autoselected by their respective host cards, this, however, doesn't make much sense on SoC-based systems. Disable autoselection on EMBEDDED systems. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- We have discussed this in length yesterday on IRC with Mauro, still, I feel a bit uncomfortable about this. I think, many x86- or other PCI- or USB-host-enabled systems will select ENABLED to finetune their kernel options, and now suddenly their v4l (USB or PCI) devices will stop working... Don't think this would please them. Maybe we need a better option or just drop this idea altogether... Added embedded ML to cc. diff --git a/drivers/media/common/tuners/Kconfig b/drivers/media/common/tuners/Kconfig index 409a426..b3ed5da 100644 --- a/drivers/media/common/tuners/Kconfig +++ b/drivers/media/common/tuners/Kconfig @@ -34,7 +34,7 @@ config MEDIA_TUNER menuconfig MEDIA_TUNER_CUSTOMISE bool Customize analog and hybrid tuner modules to build depends on MEDIA_TUNER - default n + default y if EMBEDDED help This allows the user to deselect tuner drivers unnecessary for their hardware from the build. Use this option with care diff --git a/drivers/media/dvb/frontends/Kconfig b/drivers/media/dvb/frontends/Kconfig index cd7f9b7..bed1a83 100644 --- a/drivers/media/dvb/frontends/Kconfig +++ b/drivers/media/dvb/frontends/Kconfig @@ -1,7 +1,7 @@ config DVB_FE_CUSTOMISE bool Customise the frontend modules to build depends on DVB_CORE - default N + default y if EMBEDDED help This allows the user to select/deselect frontend drivers for their hardware from the build. diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 73d1465..dc63311 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -83,7 +83,7 @@ config VIDEO_HELPER_CHIPS_AUTO_DISABLE config VIDEO_HELPER_CHIPS_AUTO bool Autoselect pertinent encoders/decoders and other helper chips depends on !VIDEO_HELPER_CHIPS_AUTO_DISABLE - default y + default y if !EMBEDDED ---help--- Most video cards may require additional modules to encode or decode audio/video standards. This option will autoselect -- 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
sending log
Hello, I inserted my USB Video Grabber labeled Extreme Video Grabber - Model DK-8701 and got the attached log. Thank you for your attention Viviano Guastalla [15931.796364] usb 1-4.4.1: new high speed USB device using ehci_hcd and address 10 [15931.888352] usb 1-4.4.1: New USB device found, idVendor=eb1a, idProduct=2861 [15931.888391] usb 1-4.4.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [15931.888593] usb 1-4.4.1: configuration #1 chosen from 1 choice [15932.017207] Linux video capture interface: v2.00 [15932.072176] em28xx: New device @ 480 Mbps (eb1a:2861, interface 0, class 0) [15932.072329] em28xx #0: chip ID is em2860 [15932.200896] em28xx #0: board has no eeprom [15932.212388] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [15932.245260] em28xx #0: found i2c device @ 0xb8 [tvp5150a] [15932.257378] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [15932.257393] em28xx #0: You may try to use card=n insmod option to workaround that. [15932.257403] em28xx #0: Please send an email with this log to: [15932.257411] em28xx #0: V4L Mailing List linux-media@vger.kernel.org [15932.257420] em28xx #0: Board eeprom hash is 0x [15932.257429] em28xx #0: Board i2c devicelist hash is 0x77800080 [15932.257437] em28xx #0: Here is a list of valid choices for the card=n insmod option: [15932.257448] em28xx #0: card=0 - Unknown EM2800 video grabber [15932.257457] em28xx #0: card=1 - Unknown EM2750/28xx video grabber [15932.257466] em28xx #0: card=2 - Terratec Cinergy 250 USB [15932.257475] em28xx #0: card=3 - Pinnacle PCTV USB 2 [15932.257484] em28xx #0: card=4 - Hauppauge WinTV USB 2 [15932.257492] em28xx #0: card=5 - MSI VOX USB 2.0 [15932.257501] em28xx #0: card=6 - Terratec Cinergy 200 USB [15932.257510] em28xx #0: card=7 - Leadtek Winfast USB II [15932.257518] em28xx #0: card=8 - Kworld USB2800 [15932.257527] em28xx #0: card=9 - Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker [15932.257538] em28xx #0: card=10 - Hauppauge WinTV HVR 900 [15932.257547] em28xx #0: card=11 - Terratec Hybrid XS [15932.257556] em28xx #0: card=12 - Kworld PVR TV 2800 RF [15932.257564] em28xx #0: card=13 - Terratec Prodigy XS [15932.257573] em28xx #0: card=14 - SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 [15932.257583] em28xx #0: card=15 - V-Gear PocketTV [15932.257592] em28xx #0: card=16 - Hauppauge WinTV HVR 950 [15932.257601] em28xx #0: card=17 - Pinnacle PCTV HD Pro Stick [15932.257610] em28xx #0: card=18 - Hauppauge WinTV HVR 900 (R2) [15932.257619] em28xx #0: card=19 - EM2860/SAA711X Reference Design [15932.257628] em28xx #0: card=20 - AMD ATI TV Wonder HD 600 [15932.257637] em28xx #0: card=21 - eMPIA Technology, Inc. GrabBeeX+ Video Encoder [15932.257647] em28xx #0: card=22 - EM2710/EM2750/EM2751 webcam grabber [15932.257656] em28xx #0: card=23 - Huaqi DLCW-130 [15932.257665] em28xx #0: card=24 - D-Link DUB-T210 TV Tuner
Re: Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)
Hello, We are now able to reproduce the problem faster and easier (using the patched version of szap-s2 and the scripts included in the tar.gz : http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/17334 and http://cache.gmane.org//gmane/linux/drivers/video-input-infrastructure/17334-001.bin ) 0) su -c rmmod ngene modprobe ngene one_adapter=0 1) ./run_szap-s2_adapter0.sh | grep Delay 2) in parallel to 1) szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -r -Q 7 (better: by adding -Q the program is terminated, and all devices are closed after approx. 8 to 9 secs) = while 2) is running 1) will show increased tuning times Delay : 0.541970 Delay : 0.606943 Delay : 1.410069 [ HERE 2) was started ] Delay : 1.369592 Delay : 1.261879 Delay : 1.766680 3) after 2) has terminated simply let 1) continue for 30-40 iterations. you will see .. Delay : 1.845793 Delay : 1.772285 Delay : 2.045703 Delay : 1.817985 Delay : 0.982030 Delay : 1.769856 Delay : 1.769782 Delay : 0.537857 Delay : 21.628382 4) At this point, immediately press Ctrl-C and restart 1) - you will see Delay : 0.577599 Delay : 0.549717 Delay : 0.593816 Delay : 0.593758 Delay : 0.549584 Delay : 0.546012 == BAD: Problem seems to happen due to one adapter being opened and closed again == GOOD: we are now able to easily and quickly reproduce both problems without Ctrl-C thanks for your help, Andreas Besse Andreas Besse wrote: Hello, we discovered several problems with the ngene based dual DVB cards. The problems occur with the Digital Devices Cine S2 Dual DVB-S2 device (Linux4Media cineS2 DVB-S2 Twin Tuner), the clones like Mystique SaTiX S2 Dual should also be affected. We are using the ngene drivers from the linuxtv repository http://linuxtv.org/hg/v4l-dvb and the firmware version 15 provided by Digital Devices. *Setup* *** OpenSuse Linux 11.0 Linux anna 2.6.25.20-0.5-pae #1 SMP 2009-08-14 01:48:11 +0200 i686 i686 i386 GNU/Linux DVB drivers: http://linuxtv.org/hg/v4l-dvb (ngene) 2e0444bf93a4 (changeset 14233:2e0444bf93a4, date: Mon Feb 22 10:58:43 2010 -0300) module loaded with modprobe ngene one_adapter=0 *Usage* *** We slightly modified the latest version of szap-s2 (available from http://mercurial.intuxication.org/hg/szap-s2/ ); see attached .tar.gz tar xvfz modified_szap_s2.tar.gz make Most importantly, the modified version prints out the total delay in seconds of main() to allow for easier debugging. *Problem A* *** Two running instance of szap-s2 are used: a) one for changing channels between Das Erste (Astra 19.2E) and ZDF (Astra 19.2E) b) the other one for recording from Das Erste (or any other channel) Result: When only a) is running, channel tuning times between the two different transponders of Das Erste and ZDF are around 0.5 secs. This is really good. However, when b) is started in parallel, these times increase to 1.5 to 1.8 seconds. This is not good. How to reproduce? 1) in one shell, run ./run_szap-s2_adapter0.sh | grep Delay You will see Delay : 0.560508 Delay : 0.545771 Delay : 0.609781 Delay : 0.593796 Delay : 0.649772 Delay : 0.614023 .. 2) in parallel in another shell, run ./szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -r Immediately, you will see in 1) Delay : 1.525178 Delay : 1.781971 .. *Problem B* *** After reproducing Problem A, we terminate process 2) by hitting Ctrl-C. Even then, channel tuning time stay high in process 1), you will still see Delay : 1.773303 Delay : 1.781734 Delay : 1.749948 .. This is not good. *Problem C* *** What is even worse: Very often, you will soon run into trouble: After a very iterations, you will see: Delay : 21.616521 Delay : 21.773475 Delay : 21.765678 This means that tuning was not possible anymore at all. In this situation, it always helps to re-load the module by runing: su -c rmmod ngene modprobe ngene one_adapter=0 *Problem D* *** When terminating process 1) and immediately restarting it, channel tuning times - again - stay high. This is not good. Often you will also see Problem C then. *Problem E* *** Go back to reproducing Problem A (process 1 and 2 are running), and the continuously start and terminate process 2) by hitting Ctrl-C again and again. Sooner or later, you will see Problem C occur then. *Remark* *** It _seems_ that, after terminating all szap-s2 processes, and waiting 1 to 2 minutes, and then restarting szap-s2 again, the failures/problems seem to be gone _without_ reloading the module. thanks for your help, Andreas Besse -- To unsubscribe from this
[PATCH 1/3 v2] V4L: SuperH Video Output Unit (VOU) driver
A number of SuperH SoCs, including sh7724, include a Video Output Unit. This
patch adds a video (V4L2) output driver for it. The driver uses v4l2-subdev and
mediabus APIs to interface to TV encoders.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v1 - v2:
1. removed overlay, it is actually not needed for gstreamer, sorry for
confusion
2. made scaling coefficient arrays const
3. switched to using V4L2_STD_525_60 instead of V4L2_STD_NTSC
4. improved platform bus configuration
5. added .vidioc_g_chip_ident, .vidioc_g_register, .vidioc_s_register to
support ak881x
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile |2 +
drivers/media/video/sh_vou.c | 1476 ++
include/media/sh_vou.h | 34 +
4 files changed, 1519 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/sh_vou.c
create mode 100644 include/media/sh_vou.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 64682bf..be6d016 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -511,6 +511,13 @@ config DISPLAY_DAVINCI_DM646X_EVM
To compile this driver as a module, choose M here: the
module will be called vpif_display.
+config VIDEO_SH_VOU
+ tristate SuperH VOU video output driver
+ depends on VIDEO_DEV (SUPERH || ARCH_SHMOBILE)
+ select VIDEOBUF_DMA_CONTIG
+ help
+ Support for the Video Output Unit (VOU) on SuperH SoCs.
+
config CAPTURE_DAVINCI_DM646X_EVM
tristate DM646x EVM Video Capture
depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 2af68ee..2669d34 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -160,6 +160,8 @@ obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) +=
sh_mobile_ceu_camera.o
obj-$(CONFIG_ARCH_DAVINCI) += davinci/
+obj-$(CONFIG_VIDEO_SH_VOU) += sh_vou.o
+
obj-$(CONFIG_VIDEO_AU0828) += au0828/
obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/
diff --git a/drivers/media/video/sh_vou.c b/drivers/media/video/sh_vou.c
new file mode 100644
index 000..f5b892a
--- /dev/null
+++ b/drivers/media/video/sh_vou.c
@@ -0,0 +1,1476 @@
+/*
+ * SuperH Video Output Unit (VOU) driver
+ *
+ * Copyright (C) 2010, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * 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/dma-mapping.h
+#include linux/delay.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/version.h
+#include linux/videodev2.h
+
+#include media/sh_vou.h
+#include media/v4l2-common.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-mediabus.h
+#include media/videobuf-dma-contig.h
+
+/* Mirror addresses are not available for all registers */
+#define VOUER 0
+#define VOUCR 4
+#define VOUSTR 8
+#define VOUVCR 0xc
+#define VOUISR 0x10
+#define VOUBCR 0x14
+#define VOUDPR 0x18
+#define VOUDSR 0x1c
+#define VOUVPR 0x20
+#define VOUIR 0x24
+#define VOUSRR 0x28
+#define VOUMSR 0x2c
+#define VOUHIR 0x30
+#define VOUDFR 0x34
+#define VOUAD1R0x38
+#define VOUAD2R0x3c
+#define VOUAIR 0x40
+#define VOUSWR 0x44
+#define VOURCR 0x48
+#define VOURPR 0x50
+
+enum sh_vou_status {
+ SH_VOU_IDLE,
+ SH_VOU_INITIALISING,
+ SH_VOU_RUNNING,
+};
+
+#define VOU_MAX_IMAGE_WIDTH720
+#define VOU_MAX_IMAGE_HEIGHT 480
+
+struct sh_vou_device {
+ struct v4l2_device v4l2_dev;
+ struct video_device *vdev;
+ atomic_t use_count;
+ struct sh_vou_pdata *pdata;
+ spinlock_t lock;
+ void __iomem *base;
+ /* State information */
+ struct v4l2_pix_format pix;
+ struct v4l2_rect rect;
+ struct list_head queue;
+ v4l2_std_id std;
+ int pix_idx;
+ struct videobuf_buffer *active;
+ enum sh_vou_status status;
+};
+
+struct sh_vou_file {
+ struct videobuf_queue vbq;
+};
+
+/* Register access routines for sides A, B and mirror addresses */
+static void sh_vou_reg_a_write(struct sh_vou_device *vou_dev, unsigned int reg,
+ u32 value)
+{
+ __raw_writel(value, vou_dev-base + reg);
+}
+
+static void sh_vou_reg_ab_write(struct sh_vou_device *vou_dev, unsigned int
reg,
+ u32 value)
+{
+ __raw_writel(value, vou_dev-base + reg);
+ __raw_writel(value, vou_dev-base + reg + 0x1000);
+}
+
+static void sh_vou_reg_m_write(struct sh_vou_device *vou_dev, unsigned int reg,
+ u32 value)
+{
+ __raw_writel(value, vou_dev-base + reg + 0x2000);
+}
+
+static u32
[PATCH 3/3 v2] sh: add Video Output Unit (VOU) and AK8813 TV-encoder support to ms7724se
Add platform bindings, GPIO initialisation and allocation and AK8813 reset code
to ms7724se.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v1 - v2
1. VOU bus type name changed
arch/sh/boards/mach-se/7724/setup.c | 88 ---
1 files changed, 81 insertions(+), 7 deletions(-)
diff --git a/arch/sh/boards/mach-se/7724/setup.c
b/arch/sh/boards/mach-se/7724/setup.c
index c7dbbec..5a3b6da 100644
--- a/arch/sh/boards/mach-se/7724/setup.c
+++ b/arch/sh/boards/mach-se/7724/setup.c
@@ -489,6 +489,52 @@ static struct platform_device sdhi1_cn8_device = {
},
};
+#include media/ak881x.h
+#include media/sh_vou.h
+
+struct ak881x_pdata ak881x_pdata = {
+ .flags = AK881X_IF_MODE_SLAVE,
+};
+
+static struct i2c_board_info ak8813 = {
+ /* With open J18 jumper address is 0x21 */
+ I2C_BOARD_INFO(ak8813, 0x20),
+ .platform_data = ak881x_pdata,
+};
+
+struct sh_vou_pdata sh_vou_pdata = {
+ .bus_fmt= SH_VOU_BUS_8BIT,
+ .flags = SH_VOU_HSYNC_LOW | SH_VOU_VSYNC_LOW,
+ .board_info = ak8813,
+ .i2c_adap = 0,
+ .module_name= ak881x,
+};
+
+static struct resource sh_vou_resources[] = {
+ [0] = {
+ .start = 0xfe96,
+ .end= 0xfe962043,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = 55,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device vou_device = {
+ .name = sh-vou,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(sh_vou_resources),
+ .resource = sh_vou_resources,
+ .dev= {
+ .platform_data = sh_vou_pdata,
+ },
+ .archdata = {
+ .hwblk_id = HWBLK_VOU,
+ },
+};
+
static struct platform_device *ms7724se_devices[] __initdata = {
heartbeat_device,
smc91x_eth_device,
@@ -503,6 +549,7 @@ static struct platform_device *ms7724se_devices[]
__initdata = {
fsi_device,
sdhi0_cn7_device,
sdhi1_cn8_device,
+ vou_device,
};
/* I2C device */
@@ -587,6 +634,7 @@ static int __init devices_setup(void)
{
u16 sw = __raw_readw(SW4140); /* select camera, monitor */
struct clk *fsia_clk;
+ u16 fpga_out;
/* register board specific self-refresh code */
sh_mobile_register_self_refresh(SUSP_SH_STANDBY | SUSP_SH_SF,
@@ -595,13 +643,25 @@ static int __init devices_setup(void)
ms7724se_sdram_leave_start,
ms7724se_sdram_leave_end);
/* Reset Release */
- __raw_writew(__raw_readw(FPGA_OUT)
- ~((1 1) | /* LAN */
- (1 6) | /* VIDEO DAC */
- (1 7) | /* AK4643 */
- (1 12) | /* USB0 */
- (1 14)), /* RMII */
- FPGA_OUT);
+ fpga_out = __raw_readw(FPGA_OUT);
+ /* bit4: NTSC_PDN, bit5: NTSC_RESET */
+ fpga_out = ~((1 1) | /* LAN */
+ (1 4) | /* AK8813 PDN */
+ (1 5) | /* AK8813 RESET */
+ (1 6) | /* VIDEO DAC */
+ (1 7) | /* AK4643 */
+ (1 12) | /* USB0 */
+ (1 14)); /* RMII */
+ __raw_writew(fpga_out | (1 4), FPGA_OUT);
+
+ udelay(10);
+
+ /* AK8813 RESET */
+ __raw_writew(fpga_out | (1 5), FPGA_OUT);
+
+ udelay(10);
+
+ __raw_writew(fpga_out, FPGA_OUT);
/* turn on USB clocks, use external clock */
__raw_writew((__raw_readw(PORT_MSELCRB) ~0xc000) | 0x8000,
PORT_MSELCRB);
@@ -837,6 +897,20 @@ static int __init devices_setup(void)
lcdc_info.ch[0].flags = LCDC_FLAGS_DWPOL;
}
+ /* VOU */
+ gpio_request(GPIO_FN_DV_D15, NULL);
+ gpio_request(GPIO_FN_DV_D14, NULL);
+ gpio_request(GPIO_FN_DV_D13, NULL);
+ gpio_request(GPIO_FN_DV_D12, NULL);
+ gpio_request(GPIO_FN_DV_D11, NULL);
+ gpio_request(GPIO_FN_DV_D10, NULL);
+ gpio_request(GPIO_FN_DV_D9, NULL);
+ gpio_request(GPIO_FN_DV_D8, NULL);
+ gpio_request(GPIO_FN_DV_CLKI, NULL);
+ gpio_request(GPIO_FN_DV_CLK, NULL);
+ gpio_request(GPIO_FN_DV_VSYNC, NULL);
+ gpio_request(GPIO_FN_DV_HSYNC, NULL);
+
return platform_add_devices(ms7724se_devices,
ARRAY_SIZE(ms7724se_devices));
}
--
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 2/3 v2] V4L: v4l2-subdev driver for AK8813 and AK8814 TV-encoders from AKM
AK8814 only differs from AK8813 by included Macrovision Copy Protection
function. This patch adds a driver for AK8813 and AK8814 I2C PAL/NTSC TV
encoders.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v1 - v2
1. switched to using v4l2_get_subdevdata(sd) instead of sd-priv
2. changed maximum height to 576 for PAL
3. removed a superfluous call to i2c_set_clientdata()
4. added a call to v4l2_device_unregister_subdev(sd)
5. moved IDs to preserve the ordering
What I haven't done:
1. kept dev_{dbg,info} instead of switching to v4l2_* analogs - Hans
wanted to rethink the current policy
2. didn't modify the chip found line - partially because of unclarities
with v4l2_info and double I2C address, partially because for
configurations, where chips are on CPU's i2c bus printing adapter name
doesn't make much sense, and the proposed line doesn't include the chip
ID, only its revision.
I would sugest to apply the patch as is and to adjust these remaining
points later when we have a better consensus about them.
drivers/media/video/Kconfig |6 +
drivers/media/video/Makefile|2 +
drivers/media/video/ak881x.c| 375 +++
include/media/ak881x.h | 25 +++
include/media/v4l2-chip-ident.h |4 +
5 files changed, 412 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/ak881x.c
create mode 100644 include/media/ak881x.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index be6d016..f7b1f89 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -471,6 +471,12 @@ config VIDEO_ADV7343
To compile this driver as a module, choose M here: the
module will be called adv7343.
+config VIDEO_AK881X
+ tristate AK8813/AK8814 video encoders
+ depends on I2C
+ help
+ Video output driver for AKM AK8813 and AK8814 TV encoders
+
comment Video improvement chips
config VIDEO_UPD64031A
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 2669d34..6790051 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -149,6 +149,8 @@ obj-$(CONFIG_VIDEO_CX18) += cx18/
obj-$(CONFIG_VIDEO_VIVI) += vivi.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
+obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
+
obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o
obj-$(CONFIG_SOC_CAMERA) += soc_camera.o soc_mediabus.o
obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
diff --git a/drivers/media/video/ak881x.c b/drivers/media/video/ak881x.c
new file mode 100644
index 000..16fe025
--- /dev/null
+++ b/drivers/media/video/ak881x.c
@@ -0,0 +1,375 @@
+/*
+ * Driver for AK8813 / AK8814 TV-ecoders from Asahi Kasei Microsystems Co.,
Ltd. (AKM)
+ *
+ * Copyright (C) 2010, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * 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/i2c.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+
+#include media/ak881x.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-common.h
+#include media/v4l2-device.h
+
+#define AK881X_INTERFACE_MODE 0
+#define AK881X_VIDEO_PROCESS1 1
+#define AK881X_VIDEO_PROCESS2 2
+#define AK881X_VIDEO_PROCESS3 3
+#define AK881X_DAC_MODE5
+#define AK881X_STATUS 0x24
+#define AK881X_DEVICE_ID 0x25
+#define AK881X_DEVICE_REVISION 0x26
+
+struct ak881x {
+ struct v4l2_subdev subdev;
+ struct ak881x_pdata *pdata;
+ unsigned int lines;
+ int id; /* DEVICE_ID code V4L2_IDENT_AK881X code from v4l2-chip-ident.h
*/
+ char revision; /* DEVICE_REVISION content */
+};
+
+static int reg_read(struct i2c_client *client, const u8 reg)
+{
+ return i2c_smbus_read_byte_data(client, reg);
+}
+
+static int reg_write(struct i2c_client *client, const u8 reg,
+const u8 data)
+{
+ return i2c_smbus_write_byte_data(client, reg, data);
+}
+
+static int reg_set(struct i2c_client *client, const u8 reg,
+ const u8 data, u8 mask)
+{
+ int ret = reg_read(client, reg);
+ if (ret 0)
+ return ret;
+ return reg_write(client, reg, (ret ~mask) | (data mask));
+}
+
+static struct ak881x *to_ak881x(const struct i2c_client *client)
+{
+ return container_of(i2c_get_clientdata(client), struct ak881x, subdev);
+}
+
+static int ak881x_g_chip_ident(struct v4l2_subdev *sd,
+ struct v4l2_dbg_chip_ident *id)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ak881x *ak881x = to_ak881x(client);
+
+ if (id-match.type != V4L2_CHIP_MATCH_I2C_ADDR)
+ return -EINVAL;
+
+ if (id-match.addr != client-addr)
+ return -ENODEV;
Re: DMX Input selection
On Wed, 2010-03-17 at 11:44 +0100, The Duke Forever wrote: Hello, I'm currently developing a DVB test application without real hardware, instead, I'm using dvb_dummy_adapter (+dvb-core and dvb_dummy_fe) Testing PES filtering is OK, since I have read/write operations on the logical dvr device /dev/dvb/adapter0/dvr0 I have problems with section filtering, I can't find a way to read data from a TS file. Methods I've tried : - Write data to DVR, set the demux to read data from DVR using ioctl DMX_SET_SOURCE - seems that this ioctl is not implemented - As the section filter reads data from frontend, I've tried to write data to /dev/dvb/adapter0/frontend0 so they can be read by the demux, but no luck, no writing operation available Any suggestions please ?! My dvb_dummy_adapter patch was a 1-hour hack just for fun. It does nothing non-standard (hopefully) and adds no APIs. IIRC, writing to the frontend is not a valid operation in the DVB API. I would suggest looking around for the dvbloopback (dvb_loopback ?) patches. They create a more complete dummy adapater and provide a special (non-standard) character device node for injecting data as if it came from the frontend. Regards, Andy -- 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 1/3 v2] V4L: SuperH Video Output Unit (VOU) driver
Hey Guennadi, On Thu, Mar 18, 2010 at 7:28 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: A number of SuperH SoCs, including sh7724, include a Video Output Unit. This patch adds a video (V4L2) output driver for it. The driver uses v4l2-subdev and mediabus APIs to interface to TV encoders. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Thanks for your work on this. The VOU block is actually used by the SH-Mobile series of SoCs. So you may want to throw in a mobile there in you description to avoid future name space collisions. I'll make sure that people test your V2 patch. Is both NTSC and PAL known to be ok with v2? Thanks, / magnus -- 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] ivtv: sizeof() = ARRAY_SIZE()
On Wed, 2010-03-17 at 18:11 +0300, Dan Carpenter wrote:
This fixes a smatch warning:
drivers/media/video/ivtv/ivtv-vbi.c +138 ivtv_write_vbi(43)
error: buffer overflow 'vi-cc_payload' 256 = 1023
Signed-off-by: Dan Carpenter erro...@gmail.com
Looks good.
Reviewed-by: Andy Walls awa...@radix.net
And, if needed
Signed-off-by: Andy Walls awa...@radix.net
Regards,
Andy
diff --git a/drivers/media/video/ivtv/ivtv-vbi.c
b/drivers/media/video/ivtv/ivtv-vbi.c
index f420d31..d73af45 100644
--- a/drivers/media/video/ivtv/ivtv-vbi.c
+++ b/drivers/media/video/ivtv/ivtv-vbi.c
@@ -134,7 +134,7 @@ void ivtv_write_vbi(struct ivtv *itv, const struct
v4l2_sliced_vbi_data *sliced,
}
}
}
- if (found_cc vi-cc_payload_idx sizeof(vi-cc_payload)) {
+ if (found_cc vi-cc_payload_idx ARRAY_SIZE(vi-cc_payload)) {
vi-cc_payload[vi-cc_payload_idx++] = cc;
set_bit(IVTV_F_I_UPDATE_CC, itv-i_flags);
}
--
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 0/2] Add iris absolute and relative control CIDs
Hi everybody, Here's a patch set that add two new standard V4L2 CIDs to control aperture setting on cameras. The first patch adds the control definitions (including documentation update) while the second patch adds support for those controls in the uvcvideo driver. I can send a pull request for those after the CIDs definitions patch has been reviewed. Laurent Pinchart (2): v4l: Add V4L2_CID_IRIS_ABSOLUTE and V4L2_CID_IRIS_RELATIVE controls uvcvideo: Support iris absolute and relative controls Documentation/DocBook/v4l/compat.xml | 11 +++ Documentation/DocBook/v4l/controls.xml| 19 +++ Documentation/DocBook/v4l/videodev2.h.xml |3 +++ drivers/media/video/uvc/uvc_ctrl.c| 20 include/linux/videodev2.h |3 +++ 5 files changed, 56 insertions(+), 0 deletions(-) -- 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
[PATCH 2/2] uvcvideo: Support iris absolute and relative controls
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_ctrl.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c
index 3b2e780..3697d72 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -561,6 +561,26 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
.data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
},
{
+ .id = V4L2_CID_IRIS_ABSOLUTE,
+ .name = Iris, Absolute,
+ .entity = UVC_GUID_UVC_CAMERA,
+ .selector = UVC_CT_IRIS_ABSOLUTE_CONTROL,
+ .size = 16,
+ .offset = 0,
+ .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
+ .data_type = UVC_CTRL_DATA_TYPE_UNSIGNED,
+ },
+ {
+ .id = V4L2_CID_IRIS_RELATIVE,
+ .name = Iris, Relative,
+ .entity = UVC_GUID_UVC_CAMERA,
+ .selector = UVC_CT_IRIS_RELATIVE_CONTROL,
+ .size = 8,
+ .offset = 0,
+ .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
+ .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
+ },
+ {
.id = V4L2_CID_ZOOM_ABSOLUTE,
.name = Zoom, Absolute,
.entity = UVC_GUID_UVC_CAMERA,
--
1.6.4.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 1/2] v4l: Add V4L2_CID_IRIS_ABSOLUTE and V4L2_CID_IRIS_RELATIVE controls
Those control, as their names imply, control the camera aperture
settings.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/DocBook/v4l/compat.xml | 11 +++
Documentation/DocBook/v4l/controls.xml| 19 +++
Documentation/DocBook/v4l/videodev2.h.xml |3 +++
include/linux/videodev2.h |3 +++
4 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/v4l/compat.xml
b/Documentation/DocBook/v4l/compat.xml
index b9dbdf9..854235b 100644
--- a/Documentation/DocBook/v4l/compat.xml
+++ b/Documentation/DocBook/v4l/compat.xml
@@ -2332,6 +2332,17 @@ more information./para
/listitem
/orderedlist
/section
+section
+ titleV4L2 in Linux 2.6.34/title
+ orderedlist
+ listitem
+ paraAdded
+constantV4L2_CID_IRIS_ABSOLUTE/constant and
+constantV4L2_CID_IRIS_RELATIVE/constant controls to the
+ link linkend=camera-controlsCamera controls class/link.
+ /para
+ /listitem
+ /orderedlist
/section
section id=other
diff --git a/Documentation/DocBook/v4l/controls.xml
b/Documentation/DocBook/v4l/controls.xml
index f464506..c412e89 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1825,6 +1825,25 @@ wide-angle direction. The zoom speed unit is
driver-specific./entry
rowentry/entry/row
row
+ entry
spanname=idconstantV4L2_CID_IRIS_ABSOLUTE/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control sets the
+camera aperture's to the specified value. The unit is undefined.
+Positive values open the iris, negative close it./entry
+ /row
+ rowentry/entry/row
+
+ row
+ entry
spanname=idconstantV4L2_CID_IRIS_RELATIVE/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control modifies the
+camera aperture's by the specified amount. The unit is undefined.
+Positive values open the iris one step further, negative values close
+it one step further. This is a write-only control./entry
+ /row
+ rowentry/entry/row
+
+ row
entry
spanname=idconstantV4L2_CID_PRIVACY/constantnbsp;/entry
entryboolean/entry
/rowrowentry spanname=descrPrevent video from being acquired
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml
b/Documentation/DocBook/v4l/videodev2.h.xml
index 0683259..c18dfeb 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -1271,6 +1271,9 @@ enum link
linkend=v4l2-exposure-auto-typev4l2_exposure_auto_type/link {
#define V4L2_CID_PRIVACY(V4L2_CID_CAMERA_CLASS_BASE+16)
+#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
+#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS(V4L2_CTRL_CLASS_FM_TX | 1)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 3c26560..c9d2120 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1277,6 +1277,9 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
+#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
--
1.6.4.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
RE: [PATCH 2/4] Add a macro to properly create IR tables
Hi Mauro, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab Sent: Friday, March 12, 2010 8:40 AM To: Linux Media Mailing List Subject: [PATCH 2/4] Add a macro to properly create IR tables This one is missing it's respective V4L2/DVB: prefix, as the other patches In the series has. Regards, Sergio Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com snip -- 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.34] gspca development
Jean-Francois Moine wrote: Hi Mauro, The following changes since commit 942ab4762505a51a7a433a7608ba5d3eed6e4f8b: Jean Delvare (1): V4L/DVB: saa7134: Fix IR support of some ASUS TV-FM 7135 variants are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_2.6.34 Applied, thanks. Please, next time, base your fixes patches on fixes.git tree. -- Cheers, 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 2/4] Add a macro to properly create IR tables
Aguirre, Sergio wrote: Hi Mauro, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab Sent: Friday, March 12, 2010 8:40 AM To: Linux Media Mailing List Subject: [PATCH 2/4] Add a macro to properly create IR tables This one is missing it's respective V4L2/DVB: prefix, as the other patches In the series has. Thanks, Sergio. I've already fixed it when I've applied the patch: Subject: V4L/DVB: ir-core: Add a macro to properly create IR tables Author: Mauro Carvalho Chehab mche...@redhat.com Date:Fri Mar 12 11:40:13 2010 -0300 I generally review the subjects and the comments during the patch import procedure, fixing them when needed. (btw, the name of the affected file were also missed on the patch I've posted). Regards, Sergio Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com snip -- 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 -- Cheers, 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/RFC 0/2] Fix DQBUF behavior for recoverable streaming errors
Hi Hans, Pavel, On Wednesday 17 March 2010 21:05:19 Hans Verkuil wrote: On Wednesday 17 March 2010 15:29:48 Pawel Osciak wrote: Hello, during the V4L2 brainstorm meeting in Norway we have concluded that streaming error handling in dqbuf is lacking a bit and might result in the application losing video buffers. V4L2 specification states that DQBUF should set errno to EIO in such cases: EIO VIDIOC_DQBUF failed due to an internal error. Can also indicate temporary problems like signal loss. Note the driver might dequeue an (empty) buffer despite returning an error, or even stop capturing. There is a problem with this though. v4l2-ioctl.c code does not copy back v4l2_buffer fields to userspace on a failed ioctl invocation, i.e. when __video_do_ioctl() does not return 0, it jumps over the copy_to_user() code: /* ... */ err = __video_do_ioctl(file, cmd, parg); /* ... */ if (err 0) goto out; /* ... */ if (copy_to_user((void __user *)arg, parg, _IOC_SIZE(cmd))) err = -EFAULT; /* ... */ out: This is fine in general, but in the case of DQBUF errors, the v4l2_buffer fields are not copied back. Because of that, the application does not have any means of discovering on which buffer the operation failed. So it cannot reuse that buffer, even despite the fact that the spec allows such behavior. This RFC proposes a modification to the DQBUF behavior in cases of internal (recoverable) errors to allow recovery from such situations. We propose a new flag for the v4l2_buffer flags field, V4L2_BUF_FLAG_ERROR. There already exists a V4L2_BUF_FLAG_DONE flag, so to support older applications, the new flag should always be set together with it. Applications unaware of the new flag would simply display a corrupted frame, but we believe it is still a better solution than failing altogether. Old EIO behavior remains so the change is backwards compatible. I will post relevant V4L2 documentation updates after (if) this change is accepted. This series is rebased onto my recent videobuf clean-up and poll behavior patches. The series contains: [PATCH 1/2] v4l: Add a new ERROR flag for DQBUF after recoverable streaming errors [PATCH 2/2] v4l: videobuf: Add support for V4L2_BUF_FLAG_ERROR Reviewed-by: Hans Verkuil hverk...@xs4all.nl I think this is a very sensible change. After all, DQBUF succeeds, even though the buffer itself contains errors. But that is not the fault of DQBUF. It is enough to flag that the buffer does have an error. Without this you actually loose the buffer completely from the point of view of the application. And that's really nasty. Especially with the current wording of the spec: Note the driver might dequeue an (empty) buffer despite returning an error, or even stop capturing. That's pretty bad. Because of video_ioctl2 the application won't know which buffer has been dequeued, if any, and will thus have no way to requeue it. Pavel, could you update the Docbook documentation as well in your patch set ? The behaviour of DQBUF needs to be properly documented. -- 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 1/2] v4l: Add V4L2_CID_IRIS_ABSOLUTE and V4L2_CID_IRIS_RELATIVE controls
Hi Laurent, Just a minor grammar issue. -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Thursday, March 18, 2010 6:55 AM To: linux-media@vger.kernel.org Subject: [PATCH 1/2] v4l: Add V4L2_CID_IRIS_ABSOLUTE and V4L2_CID_IRIS_RELATIVE controls snip section id=other diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index f464506..c412e89 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -1825,6 +1825,25 @@ wide-angle direction. The zoom speed unit is driver-specific./entry rowentry/entry/row row + entry spanname=idconstantV4L2_CID_IRIS_ABSOLUTE/constantnbsp;/entry + entryinteger/entry + /rowrowentry spanname=descrThis control sets the +camera aperture's to the specified value. The unit is undefined. camera's aperture +Positive values open the iris, negative close it./entry + /row + rowentry/entry/row + + row + entry spanname=idconstantV4L2_CID_IRIS_RELATIVE/constantnbsp;/entry + entryinteger/entry + /rowrowentry spanname=descrThis control modifies the +camera aperture's by the specified amount. The unit is undefined. camera's aperture Regards, Sergio snip -- 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 1/2] v4l: Add V4L2_CID_IRIS_ABSOLUTE and V4L2_CID_IRIS_RELATIVE controls
Laurent Pinchart wrote: Those control, as their names imply, control the camera aperture settings. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/DocBook/v4l/compat.xml | 11 +++ Documentation/DocBook/v4l/controls.xml| 19 +++ Documentation/DocBook/v4l/videodev2.h.xml |3 +++ include/linux/videodev2.h |3 +++ 4 files changed, 36 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml index b9dbdf9..854235b 100644 --- a/Documentation/DocBook/v4l/compat.xml +++ b/Documentation/DocBook/v4l/compat.xml @@ -2332,6 +2332,17 @@ more information./para /listitem /orderedlist /section +section + titleV4L2 in Linux 2.6.34/title + orderedlist + listitem + paraAdded +constantV4L2_CID_IRIS_ABSOLUTE/constant and +constantV4L2_CID_IRIS_RELATIVE/constant controls to the + link linkend=camera-controlsCamera controls class/link. + /para + /listitem + /orderedlist /section section id=other diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index f464506..c412e89 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -1825,6 +1825,25 @@ wide-angle direction. The zoom speed unit is driver-specific./entry rowentry/entry/row row + entry spanname=idconstantV4L2_CID_IRIS_ABSOLUTE/constantnbsp;/entry + entryinteger/entry + /rowrowentry spanname=descrThis control sets the +camera aperture's to the specified value. The unit is undefined. +Positive values open the iris, negative close it./entry + /row + rowentry/entry/row + + row + entry spanname=idconstantV4L2_CID_IRIS_RELATIVE/constantnbsp;/entry + entryinteger/entry + /rowrowentry spanname=descrThis control modifies the +camera aperture's by the specified amount. The unit is undefined. +Positive values open the iris one step further, negative values close +it one step further. This is a write-only control./entry + /row + rowentry/entry/row + + row entry spanname=idconstantV4L2_CID_PRIVACY/constantnbsp;/entry entryboolean/entry /rowrowentry spanname=descrPrevent video from being acquired Seems ok to me, but it would be good to add some sort of scale for those controls. Cheers, 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: Pull request: http://linuxtv.org/hg/~hgoede/gspca
Hans de Goede wrote: Hi Mauro, Please pull from: http://linuxtv.org/hg/~hgoede/gspca For the following changes: gspca_spca561: Fix LED on rev12a cameras gspca_spca561: Add support for camera button sn9c102: Make hv7131d sensor code also recognize the HV7131E gspca: make usb id 0461:0815 get handled by the right driver Hmm... something got wrong here: # Mercurial patches imported from http://linuxtv.org/hg/~hgoede/gspca hg_14494_gspca_mr97310a_simplify_sensor_detection.patch hg_14495_gspca_sq905c_add_an_additional_usb_id.patch hg_14496_gscpa_documentation_add_cpia1_cameras.patch hg_14497_gscpa_pac207_add_support_for_camera_button.patch hg_14498_gscpa_pac7311_add_support_for_camera_button.patch hg_14499_gscpa_zc3xx_add_support_for_camera_button.patch hg_14500_gspca_sonixb_add_support_for_camera_button.patch hg_14501_gspca_sonixj_add_camera_button_support.patch hg_14502_gspca_sonixb_leave_bridge_gain_at_1_0_when_we_have_a_sensor_gain.patch hg_14503_gscpa_sonixb_differentiate_between_sensors_with_a_coarse_and_fine_expo_ctrl.patch hg_14504_gspca_sonixb_pas202_fixup_brightness_ctrl_and_add_gain_and_exposure_ctrls.patch hg_14505_gscpa_sonixb_limit_ov7630_max_framerate_at_640x480.patch hg_14506_gspca_mr97310a_add_support_for_the_sakar_1638x_cyberpix.patch hg_14507_documentation_gspca_txt_update_known_mr97310a_cams.patch hg_14508_gspca_sonixb_pas106_fixup_brightness_ctrl_and_add_gain_and_exposure_ctrls.patch hg_14509_gspca_sonixb_make_sonixb_driver_handle_pas106_and_pas202_cameras.patch hg_14510_gspca_pac7302_much_improved_exposure_control.patch hg_14511_gspca_main_allow_use_of_input_device_creation_code_for_non_int_inputs.patch hg_14512_gspca_main_some_input_error_handling_fixes.patch hg_14513_gspca_main_fix_a_compile_error_when_config_input_is_not_set.patch hg_14514_gspca_ov519_add_support_for_the_button_on_ov519_based_cams.patch hg_14515_gspca_ov519_add_support_for_the_button_on_ov518_based_cams.patch hg_14516_gspca_ov519_add_support_for_the_button_on_ov511_based_cams.patch hg_14517_gspca_stv06xx_add_support_for_camera_button.patch hg_14518_gspca_spca561_fix_led_on_rev12a_cameras.patch hg_14519_gspca_spca561_add_support_for_camera_button.patch hg_14520_sn9c102_make_hv7131d_sensor_code_also_recognize_the_hv7131e.patch hg_14521_gspca_make_usb_id_0461_0815_get_handled_by_the_right_driver.patch Maybe Douglas had to directly import some patches from -git, instead of pulling from -hg (or maybe you're just faster than Douglas, sending a new patch series before he finish the import of the older ones). Anyway, please, rebase your tree. This time, I just applied the last patches from the series. The last one is marked as high priority, as it should go to 2.6.34 . Thanks, Hans -- Cheers, 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 1/2] v4l: Add V4L2_CID_IRIS_ABSOLUTE and V4L2_CID_IRIS_RELATIVE controls
Hi Mauro, On Thursday 18 March 2010 13:19:57 Mauro Carvalho Chehab wrote: Laurent Pinchart wrote: Those control, as their names imply, control the camera aperture settings. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/DocBook/v4l/compat.xml | 11 +++ Documentation/DocBook/v4l/controls.xml| 19 +++ Documentation/DocBook/v4l/videodev2.h.xml |3 +++ include/linux/videodev2.h |3 +++ 4 files changed, 36 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml index b9dbdf9..854235b 100644 --- a/Documentation/DocBook/v4l/compat.xml +++ b/Documentation/DocBook/v4l/compat.xml @@ -2332,6 +2332,17 @@ more information./para /listitem /orderedlist /section +section + titleV4L2 in Linux 2.6.34/title + orderedlist + listitem + paraAdded +constantV4L2_CID_IRIS_ABSOLUTE/constant and +constantV4L2_CID_IRIS_RELATIVE/constant controls to the + link linkend=camera-controlsCamera controls class/link. + /para + /listitem + /orderedlist /section section id=other diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index f464506..c412e89 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -1825,6 +1825,25 @@ wide-angle direction. The zoom speed unit is driver-specific./entry rowentry/entry/row row + entry spanname=idconstantV4L2_CID_IRIS_ABSOLUTE/constantnbsp;/entry + entryinteger/entry + /rowrowentry spanname=descrThis control sets the +camera aperture's to the specified value. The unit is undefined. +Positive values open the iris, negative close it./entry + /row + rowentry/entry/row + + row + entry spanname=idconstantV4L2_CID_IRIS_RELATIVE/constantnbsp;/entry + entryinteger/entry + /rowrowentry spanname=descrThis control modifies the +camera aperture's by the specified amount. The unit is undefined. +Positive values open the iris one step further, negative values close +it one step further. This is a write-only control./entry + /row + rowentry/entry/row + + row entry spanname=idconstantV4L2_CID_PRIVACY/constantnbsp;/entry entryboolean/entry /rowrowentry spanname=descrPrevent video from being acquired Seems ok to me, but it would be good to add some sort of scale for those controls. I'd love to, but most iris controllers will just let you specify a value in an arbitrary scale (0 for closed, 255 for fully opened for instance). In that case do we want to force driver developers to measure the aperture in µm units with a micrometer caliper ? :-) -- 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 1/2] v4l: Add V4L2_CID_IRIS_ABSOLUTE and V4L2_CID_IRIS_RELATIVE controls
Laurent Pinchart wrote: Hi Mauro, On Thursday 18 March 2010 13:19:57 Mauro Carvalho Chehab wrote: Laurent Pinchart wrote: Those control, as their names imply, control the camera aperture settings. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/DocBook/v4l/compat.xml | 11 +++ Documentation/DocBook/v4l/controls.xml| 19 +++ Documentation/DocBook/v4l/videodev2.h.xml |3 +++ include/linux/videodev2.h |3 +++ 4 files changed, 36 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml index b9dbdf9..854235b 100644 --- a/Documentation/DocBook/v4l/compat.xml +++ b/Documentation/DocBook/v4l/compat.xml @@ -2332,6 +2332,17 @@ more information./para /listitem /orderedlist /section +section + titleV4L2 in Linux 2.6.34/title + orderedlist + listitem + paraAdded +constantV4L2_CID_IRIS_ABSOLUTE/constant and +constantV4L2_CID_IRIS_RELATIVE/constant controls to the + link linkend=camera-controlsCamera controls class/link. + /para + /listitem + /orderedlist /section section id=other diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index f464506..c412e89 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -1825,6 +1825,25 @@ wide-angle direction. The zoom speed unit is driver-specific./entry rowentry/entry/row row + entry spanname=idconstantV4L2_CID_IRIS_ABSOLUTE/constantnbsp;/entry + entryinteger/entry + /rowrowentry spanname=descrThis control sets the +camera aperture's to the specified value. The unit is undefined. +Positive values open the iris, negative close it./entry + /row + rowentry/entry/row + + row + entry spanname=idconstantV4L2_CID_IRIS_RELATIVE/constantnbsp;/entry + entryinteger/entry + /rowrowentry spanname=descrThis control modifies the +camera aperture's by the specified amount. The unit is undefined. +Positive values open the iris one step further, negative values close +it one step further. This is a write-only control./entry + /row + rowentry/entry/row + + row entry spanname=idconstantV4L2_CID_PRIVACY/constantnbsp;/entry entryboolean/entry /rowrowentry spanname=descrPrevent video from being acquired Seems ok to me, but it would be good to add some sort of scale for those controls. I'd love to, but most iris controllers will just let you specify a value in an arbitrary scale (0 for closed, 255 for fully opened for instance). In that case do we want to force driver developers to measure the aperture in µm units with a micrometer caliper ? :-) :) Well, maybe then you could just comment that higher values means more opened apertures. -- Cheers, 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 1/2] v4l: Add V4L2_CID_IRIS_ABSOLUTE and V4L2_CID_IRIS_RELATIVE controls
Hi Mauro, On Thursday 18 March 2010 13:41:36 Mauro Carvalho Chehab wrote: Laurent Pinchart wrote: On Thursday 18 March 2010 13:19:57 Mauro Carvalho Chehab wrote: Laurent Pinchart wrote: Those control, as their names imply, control the camera aperture settings. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/DocBook/v4l/compat.xml | 11 +++ Documentation/DocBook/v4l/controls.xml| 19 +++ Documentation/DocBook/v4l/videodev2.h.xml |3 +++ include/linux/videodev2.h |3 +++ 4 files changed, 36 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml index b9dbdf9..854235b 100644 --- a/Documentation/DocBook/v4l/compat.xml +++ b/Documentation/DocBook/v4l/compat.xml @@ -2332,6 +2332,17 @@ more information./para /listitem /orderedlist /section +section + titleV4L2 in Linux 2.6.34/title + orderedlist + listitem + paraAdded +constantV4L2_CID_IRIS_ABSOLUTE/constant and +constantV4L2_CID_IRIS_RELATIVE/constant controls to the + link linkend=camera-controlsCamera controls class/link. + /para + /listitem + /orderedlist /section section id=other diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index f464506..c412e89 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -1825,6 +1825,25 @@ wide-angle direction. The zoom speed unit is driver-specific./entry rowentry/entry/row row + entry spanname=idconstantV4L2_CID_IRIS_ABSOLUTE/constantnbsp;/entry + entryinteger/entry + /rowrowentry spanname=descrThis control sets the +camera aperture's to the specified value. The unit is undefined. +Positive values open the iris, negative close it./entry + /row + rowentry/entry/row + + row + entry spanname=idconstantV4L2_CID_IRIS_RELATIVE/constantnbsp;/entry + entryinteger/entry + /rowrowentry spanname=descrThis control modifies the +camera aperture's by the specified amount. The unit is undefined. +Positive values open the iris one step further, negative values close +it one step further. This is a write-only control./entry + /row + rowentry/entry/row + + row entry spanname=idconstantV4L2_CID_PRIVACY/constantnbsp;/entry entryboolean/entry /rowrowentry spanname=descrPrevent video from being acquired Seems ok to me, but it would be good to add some sort of scale for those controls. I'd love to, but most iris controllers will just let you specify a value in an arbitrary scale (0 for closed, 255 for fully opened for instance). In that case do we want to force driver developers to measure the aperture in µm units with a micrometer caliper ? :-) : :) Well, maybe then you could just comment that higher values means more opened apertures. Could point, I will do. -- 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 1/2] v4l: Add V4L2_CID_IRIS_ABSOLUTE and V4L2_CID_IRIS_RELATIVE controls
Hi Mauro, On Thursday 18 March 2010 13:50:50 Laurent Pinchart wrote: On Thursday 18 March 2010 13:41:36 Mauro Carvalho Chehab wrote: Laurent Pinchart wrote: On Thursday 18 March 2010 13:19:57 Mauro Carvalho Chehab wrote: Laurent Pinchart wrote: Those control, as their names imply, control the camera aperture settings. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/DocBook/v4l/compat.xml | 11 +++ Documentation/DocBook/v4l/controls.xml| 19 +++ Documentation/DocBook/v4l/videodev2.h.xml |3 +++ include/linux/videodev2.h |3 +++ 4 files changed, 36 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml index b9dbdf9..854235b 100644 --- a/Documentation/DocBook/v4l/compat.xml +++ b/Documentation/DocBook/v4l/compat.xml @@ -2332,6 +2332,17 @@ more information./para /listitem /orderedlist /section +section + titleV4L2 in Linux 2.6.34/title + orderedlist + listitem + paraAdded +constantV4L2_CID_IRIS_ABSOLUTE/constant and +constantV4L2_CID_IRIS_RELATIVE/constant controls to the + link linkend=camera-controlsCamera controls class/link. + /para + /listitem + /orderedlist /section section id=other diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index f464506..c412e89 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -1825,6 +1825,25 @@ wide-angle direction. The zoom speed unit is driver-specific./entry rowentry/entry/row row + entry spanname=idconstantV4L2_CID_IRIS_ABSOLUTE/constantnbsp;/entr y +entryinteger/entry + /rowrowentry spanname=descrThis control sets the +camera aperture's to the specified value. The unit is undefined. +Positive values open the iris, negative close it./entry + /row + rowentry/entry/row + + row + entry spanname=idconstantV4L2_CID_IRIS_RELATIVE/constantnbsp;/entr y +entryinteger/entry + /rowrowentry spanname=descrThis control modifies the +camera aperture's by the specified amount. The unit is undefined. +Positive values open the iris one step further, negative values close +it one step further. This is a write-only control./entry + /row + rowentry/entry/row + + row entry spanname=idconstantV4L2_CID_PRIVACY/constantnbsp;/entr y entryboolean/entry /rowrowentry spanname=descrPrevent video from being acquired Seems ok to me, but it would be good to add some sort of scale for those controls. I'd love to, but most iris controllers will just let you specify a value in an arbitrary scale (0 for closed, 255 for fully opened for instance). In that case do we want to force driver developers to measure the aperture in µm units with a micrometer caliper ? :-) : :) Well, maybe then you could just comment that higher values means more opened apertures. Could point, I will do. I spoke too fast, it's already there :-) -- 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
[PATCH v2 0/2] Add iris absolute and relative control CIDs
Hi everybody, Here's a second version of the iris control patch set that incorporates comments from Sergio and Mauro (I modified the documentation to make the relationship between control values and iris opening clearer). I can send a pull request for those patches after review. Laurent Pinchart (2): v4l: Add V4L2_CID_IRIS_ABSOLUTE and V4L2_CID_IRIS_RELATIVE controls uvcvideo: Support iris absolute and relative controls Documentation/DocBook/v4l/compat.xml | 11 +++ Documentation/DocBook/v4l/controls.xml| 19 +++ Documentation/DocBook/v4l/videodev2.h.xml |3 +++ drivers/media/video/uvc/uvc_ctrl.c| 20 include/linux/videodev2.h |3 +++ 5 files changed, 56 insertions(+), 0 deletions(-) -- 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
[PATCH v2 1/2] v4l: Add V4L2_CID_IRIS_ABSOLUTE and V4L2_CID_IRIS_RELATIVE controls
Those control, as their names imply, control the camera aperture
settings.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/DocBook/v4l/compat.xml | 11 +++
Documentation/DocBook/v4l/controls.xml| 19 +++
Documentation/DocBook/v4l/videodev2.h.xml |3 +++
include/linux/videodev2.h |3 +++
4 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/v4l/compat.xml
b/Documentation/DocBook/v4l/compat.xml
index b9dbdf9..854235b 100644
--- a/Documentation/DocBook/v4l/compat.xml
+++ b/Documentation/DocBook/v4l/compat.xml
@@ -2332,6 +2332,17 @@ more information./para
/listitem
/orderedlist
/section
+section
+ titleV4L2 in Linux 2.6.34/title
+ orderedlist
+ listitem
+ paraAdded
+constantV4L2_CID_IRIS_ABSOLUTE/constant and
+constantV4L2_CID_IRIS_RELATIVE/constant controls to the
+ link linkend=camera-controlsCamera controls class/link.
+ /para
+ /listitem
+ /orderedlist
/section
section id=other
diff --git a/Documentation/DocBook/v4l/controls.xml
b/Documentation/DocBook/v4l/controls.xml
index f464506..e47999d 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1825,6 +1825,25 @@ wide-angle direction. The zoom speed unit is
driver-specific./entry
rowentry/entry/row
row
+ entry
spanname=idconstantV4L2_CID_IRIS_ABSOLUTE/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control sets the
+camera's aperture to the specified value. The unit is undefined.
+Larger values open the iris wider, smaller values close it./entry
+ /row
+ rowentry/entry/row
+
+ row
+ entry
spanname=idconstantV4L2_CID_IRIS_RELATIVE/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control modifies the
+camera's aperture by the specified amount. The unit is undefined.
+Positive values open the iris one step further, negative values close
+it one step further. This is a write-only control./entry
+ /row
+ rowentry/entry/row
+
+ row
entry
spanname=idconstantV4L2_CID_PRIVACY/constantnbsp;/entry
entryboolean/entry
/rowrowentry spanname=descrPrevent video from being acquired
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml
b/Documentation/DocBook/v4l/videodev2.h.xml
index 0683259..c18dfeb 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -1271,6 +1271,9 @@ enum link
linkend=v4l2-exposure-auto-typev4l2_exposure_auto_type/link {
#define V4L2_CID_PRIVACY(V4L2_CID_CAMERA_CLASS_BASE+16)
+#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
+#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS(V4L2_CTRL_CLASS_FM_TX | 1)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 3c26560..c9d2120 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1277,6 +1277,9 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
+#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
--
1.6.4.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 v2 2/2] uvcvideo: Support iris absolute and relative controls
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_ctrl.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c
index 3b2e780..3697d72 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -561,6 +561,26 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
.data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
},
{
+ .id = V4L2_CID_IRIS_ABSOLUTE,
+ .name = Iris, Absolute,
+ .entity = UVC_GUID_UVC_CAMERA,
+ .selector = UVC_CT_IRIS_ABSOLUTE_CONTROL,
+ .size = 16,
+ .offset = 0,
+ .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
+ .data_type = UVC_CTRL_DATA_TYPE_UNSIGNED,
+ },
+ {
+ .id = V4L2_CID_IRIS_RELATIVE,
+ .name = Iris, Relative,
+ .entity = UVC_GUID_UVC_CAMERA,
+ .selector = UVC_CT_IRIS_RELATIVE_CONTROL,
+ .size = 8,
+ .offset = 0,
+ .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
+ .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
+ },
+ {
.id = V4L2_CID_ZOOM_ABSOLUTE,
.name = Zoom, Absolute,
.entity = UVC_GUID_UVC_CAMERA,
--
1.6.4.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
Re: Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)
On Thu, Mar 18, 2010 at 6:00 AM, Andreas Besse be...@motama.com wrote: Hello, We are now able to reproduce the problem faster and easier (using the patched version of szap-s2 and the scripts included in the tar.gz : http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/17334 and http://cache.gmane.org//gmane/linux/drivers/video-input-infrastructure/17334-001.bin ) This is pretty interesting. I'm doing some ngene work over the next few weeks, so I will see if I can reproduce the behavior you are seeing here. I noticed that you are manually setting the one_adapter=0 modprobe setting. Does this have any bearing on the test results? Dvein -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: Pull request: http://linuxtv.org/hg/~hgoede/gspca
Hi, On 03/18/2010 09:25 AM, Mauro Carvalho Chehab wrote: Hans de Goede wrote: Hi Mauro, Please pull from: http://linuxtv.org/hg/~hgoede/gspca For the following changes: gspca_spca561: Fix LED on rev12a cameras gspca_spca561: Add support for camera button sn9c102: Make hv7131d sensor code also recognize the HV7131E gspca: make usb id 0461:0815 get handled by the right driver Hmm... something got wrong here: # Mercurial patches imported from http://linuxtv.org/hg/~hgoede/gspca hg_14494_gspca_mr97310a_simplify_sensor_detection.patch hg_14495_gspca_sq905c_add_an_additional_usb_id.patch hg_14496_gscpa_documentation_add_cpia1_cameras.patch hg_14497_gscpa_pac207_add_support_for_camera_button.patch hg_14498_gscpa_pac7311_add_support_for_camera_button.patch hg_14499_gscpa_zc3xx_add_support_for_camera_button.patch hg_14500_gspca_sonixb_add_support_for_camera_button.patch hg_14501_gspca_sonixj_add_camera_button_support.patch hg_14502_gspca_sonixb_leave_bridge_gain_at_1_0_when_we_have_a_sensor_gain.patch hg_14503_gscpa_sonixb_differentiate_between_sensors_with_a_coarse_and_fine_expo_ctrl.patch hg_14504_gspca_sonixb_pas202_fixup_brightness_ctrl_and_add_gain_and_exposure_ctrls.patch hg_14505_gscpa_sonixb_limit_ov7630_max_framerate_at_640x480.patch hg_14506_gspca_mr97310a_add_support_for_the_sakar_1638x_cyberpix.patch hg_14507_documentation_gspca_txt_update_known_mr97310a_cams.patch hg_14508_gspca_sonixb_pas106_fixup_brightness_ctrl_and_add_gain_and_exposure_ctrls.patch hg_14509_gspca_sonixb_make_sonixb_driver_handle_pas106_and_pas202_cameras.patch hg_14510_gspca_pac7302_much_improved_exposure_control.patch hg_14511_gspca_main_allow_use_of_input_device_creation_code_for_non_int_inputs.patch hg_14512_gspca_main_some_input_error_handling_fixes.patch hg_14513_gspca_main_fix_a_compile_error_when_config_input_is_not_set.patch hg_14514_gspca_ov519_add_support_for_the_button_on_ov519_based_cams.patch hg_14515_gspca_ov519_add_support_for_the_button_on_ov518_based_cams.patch hg_14516_gspca_ov519_add_support_for_the_button_on_ov511_based_cams.patch hg_14517_gspca_stv06xx_add_support_for_camera_button.patch hg_14518_gspca_spca561_fix_led_on_rev12a_cameras.patch hg_14519_gspca_spca561_add_support_for_camera_button.patch hg_14520_sn9c102_make_hv7131d_sensor_code_also_recognize_the_hv7131e.patch hg_14521_gspca_make_usb_id_0461_0815_get_handled_by_the_right_driver.patch Maybe Douglas had to directly import some patches from -git, instead of pulling from -hg (or maybe you're just faster than Douglas, sending a new patch series before he finish the import of the older ones). I remember to took these patches from git, sorry Hans. I will took your new patches from you new hg tree. Cheers Douglas -- 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] V4L - vpfe capture - fix for kernel crash
From: Muralidharan Karicheri m-kariche...@ti.com
As part of upstream merge, set_params() function was removed from isif.c.
This requires removal of BUG_ON() and check for set_params ptr in
vpfe_capture.c. Without this kernel crash dump is seen while bootup on DM365
Also made following changes:-
1) converted error messages to debug messages since it is not right to flood
the console with error messages for user mistakes.
2) returns -EINVAL if ioctl is not supported
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c | 33 +---
1 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 91f665b..1d46210 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -222,7 +222,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
BUG_ON(!dev-hw_ops.get_frame_format);
BUG_ON(!dev-hw_ops.get_pixel_format);
BUG_ON(!dev-hw_ops.set_pixel_format);
- BUG_ON(!dev-hw_ops.set_params);
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
@@ -1688,11 +1687,12 @@ static long vpfe_param_handler(struct file *file, void
*priv,
struct vpfe_device *vpfe_dev = video_drvdata(file);
int ret = 0;
- v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_param_handler\n);
+ v4l2_dbg(2, debug, vpfe_dev-v4l2_dev, vpfe_param_handler\n);
if (vpfe_dev-started) {
/* only allowed if streaming is not started */
- v4l2_err(vpfe_dev-v4l2_dev, device already started\n);
+ v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+ device already started\n);
return -EBUSY;
}
@@ -1704,16 +1704,23 @@ static long vpfe_param_handler(struct file *file, void
*priv,
case VPFE_CMD_S_CCDC_RAW_PARAMS:
v4l2_warn(vpfe_dev-v4l2_dev,
VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n);
- ret = ccdc_dev-hw_ops.set_params(param);
- if (ret) {
- v4l2_err(vpfe_dev-v4l2_dev,
- Error in setting parameters in CCDC\n);
- goto unlock_out;
- }
- if (vpfe_get_ccdc_image_format(vpfe_dev, vpfe_dev-fmt) 0) {
- v4l2_err(vpfe_dev-v4l2_dev,
- Invalid image format at CCDC\n);
- goto unlock_out;
+ if (ccdc_dev-hw_ops.set_params) {
+ ret = ccdc_dev-hw_ops.set_params(param);
+ if (ret) {
+ v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+ Error setting parameters in CCDC\n);
+ goto unlock_out;
+ }
+ if (vpfe_get_ccdc_image_format(vpfe_dev,
+ vpfe_dev-fmt) 0) {
+ v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+ Invalid image format at CCDC\n);
+ goto unlock_out;
+ }
+ } else {
+ ret = -EINVAL;
+ v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+ VPFE_CMD_S_CCDC_RAW_PARAMS not supported\n);
}
break;
default:
--
1.6.0.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
Re: Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)
On Thu, Mar 18, 2010 at 11:07 AM, Marco Lohse mlo...@motama.com wrote: Devin Heitmueller wrote: On Thu, Mar 18, 2010 at 6:00 AM, Andreas Besse be...@motama.com wrote: Hello, We are now able to reproduce the problem faster and easier (using the patched version of szap-s2 and the scripts included in the tar.gz : http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/17334 and http://cache.gmane.org//gmane/linux/drivers/video-input-infrastructure/17334-001.bin ) This is pretty interesting. I'm doing some ngene work over the next few weeks, so I will see if I can reproduce the behavior you are seeing here. I noticed that you are manually setting the one_adapter=0 modprobe setting. Does this have any bearing on the test results? I will try to answer this one: No, leaving out this parameter does not change the test results; you will only need to use different and additional parameters for szap-s2 for specifying the correct adapter and sub-devices. By now, we also found out that the problems can be reproduced much easier: 0) szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x | grep Delay Delay : 0.573021 1) szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -x | grep Delay Delay : 0.564667 2) szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x | grep Delay Delay : 1.741931 Instead of 2) you can also run the included script 2') ./run_szap-s2_adapter0.sh which will result in the device timeout after 30-40 iterations To summarize = When opening and closing adapter0, then opening and closing devices of adapter1, this will immediately result in problems. And there a lot more variations of this bug, for example: actually read data from adapter0, tune adapter1 using szap-s2, which will result in adapter0 to be 'blocked' and not produce any more data after around 60 secs. We are currently trying to dig into the source code of the driver to solve the problems and would appreciate any help. Hi Marco, Ok, great. Like I said, I will see if I can reproduce it here, as that will help narrow down whether it's really an issue with the ngene bridge, or whether it's got something to do with that particular bridge/demod/tuner combination. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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 0/2] Fix DQBUF behavior for recoverable streaming errors
Laurent Pinchart wrote: On Wednesday 17 March 2010 21:05:19 Hans Verkuil wrote: On Wednesday 17 March 2010 15:29:48 Pawel Osciak wrote: Hello, during the V4L2 brainstorm meeting in Norway we have concluded that streaming error handling in dqbuf is lacking a bit and might result in the application losing video buffers. V4L2 specification states that DQBUF should set errno to EIO in such cases: EIO VIDIOC_DQBUF failed due to an internal error. Can also indicate temporary problems like signal loss. Note the driver might dequeue an (empty) buffer despite returning an error, or even stop capturing. There is a problem with this though. v4l2-ioctl.c code does not copy back v4l2_buffer fields to userspace on a failed ioctl invocation, i.e. when __video_do_ioctl() does not return 0, it jumps over the copy_to_user() code: /* ... */ err = __video_do_ioctl(file, cmd, parg); /* ... */ if (err 0) goto out; /* ... */ if (copy_to_user((void __user *)arg, parg, _IOC_SIZE(cmd))) err = -EFAULT; /* ... */ out: This is fine in general, but in the case of DQBUF errors, the v4l2_buffer fields are not copied back. Because of that, the application does not have any means of discovering on which buffer the operation failed. So it cannot reuse that buffer, even despite the fact that the spec allows such behavior. This RFC proposes a modification to the DQBUF behavior in cases of internal (recoverable) errors to allow recovery from such situations. We propose a new flag for the v4l2_buffer flags field, V4L2_BUF_FLAG_ERROR. There already exists a V4L2_BUF_FLAG_DONE flag, so to support older applications, the new flag should always be set together with it. Applications unaware of the new flag would simply display a corrupted frame, but we believe it is still a better solution than failing altogether. Old EIO behavior remains so the change is backwards compatible. I will post relevant V4L2 documentation updates after (if) this change is accepted. This series is rebased onto my recent videobuf clean-up and poll behavior patches. The series contains: [PATCH 1/2] v4l: Add a new ERROR flag for DQBUF after recoverable streaming errors [PATCH 2/2] v4l: videobuf: Add support for V4L2_BUF_FLAG_ERROR Reviewed-by: Hans Verkuil hverk...@xs4all.nl I think this is a very sensible change. After all, DQBUF succeeds, even though the buffer itself contains errors. But that is not the fault of DQBUF. It is enough to flag that the buffer does have an error. Without this you actually loose the buffer completely from the point of view of the application. And that's really nasty. Especially with the current wording of the spec: Note the driver might dequeue an (empty) buffer despite returning an error, or even stop capturing. That's pretty bad. Because of video_ioctl2 the application won't know which buffer has been dequeued, if any, and will thus have no way to requeue it. Pavel, could you update the Docbook documentation as well in your patch set ? The behaviour of DQBUF needs to be properly documented. Sure. Although I just noticed something. The spec for V4L2_BUF_FLAG_DONE says: When this flag is set, the buffer is currently on the outgoing queue, ready to be dequeued from the driver. Drivers set or clear this flag when the VIDIOC_QUERYBUF ioctl is called. After calling the VIDIOC_QBUF or VIDIOC_DQBUF it is always cleared. Of course a buffer cannot be on both queues at the same time, the V4L2_BUF_FLAG_QUEUED and V4L2_BUF_FLAG_DONE flag are mutually exclusive. They can be both cleared however, then the buffer is in dequeued state, in the application domain to say so. So according to the spec, DONE means done but not yet returned to userspace. So it should be cleared during dequeueing. But videobuf actually sets that flag in dqbuf. And frankly, it seems more sensible to me. Could you confirm that this is how we want it and I should follow the specs? If so, I will fix videobuf to stop setting that flag. Best regards -- Pawel Osciak Linux Platform Group 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: Pull request: http://linuxtv.org/hg/~hgoede/gspca
Hi, On 03/18/2010 01:25 PM, Mauro Carvalho Chehab wrote: Hans de Goede wrote: Hi Mauro, Please pull from: http://linuxtv.org/hg/~hgoede/gspca For the following changes: gspca_spca561: Fix LED on rev12a cameras gspca_spca561: Add support for camera button sn9c102: Make hv7131d sensor code also recognize the HV7131E gspca: make usb id 0461:0815 get handled by the right driver Hmm... something got wrong here: snip Maybe Douglas had to directly import some patches from -git, instead of pulling from -hg (or maybe you're just faster than Douglas, sending a new patch series before he finish the import of the older ones). Anyway, please, rebase your tree. Will do. This time, I just applied the last patches from the series. Thanks, note that you seem to have forgotten the last one: gspca: make usb id 0461:0815 get handled by the right driver 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: [PATCH 1/2] v4l: Add V4L2_CID_IRIS_ABSOLUTE and V4L2_CID_IRIS_RELATIVE controls
Laurent Pinchart wrote: Hi Mauro, On Thursday 18 March 2010 13:50:50 Laurent Pinchart wrote: On Thursday 18 March 2010 13:41:36 Mauro Carvalho Chehab wrote: Laurent Pinchart wrote: On Thursday 18 March 2010 13:19:57 Mauro Carvalho Chehab wrote: Laurent Pinchart wrote: Those control, as their names imply, control the camera aperture settings. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/DocBook/v4l/compat.xml | 11 +++ Documentation/DocBook/v4l/controls.xml| 19 +++ Documentation/DocBook/v4l/videodev2.h.xml |3 +++ include/linux/videodev2.h |3 +++ 4 files changed, 36 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml index b9dbdf9..854235b 100644 --- a/Documentation/DocBook/v4l/compat.xml +++ b/Documentation/DocBook/v4l/compat.xml @@ -2332,6 +2332,17 @@ more information./para /listitem /orderedlist /section +section + titleV4L2 in Linux 2.6.34/title + orderedlist +listitem + paraAdded +constantV4L2_CID_IRIS_ABSOLUTE/constant and +constantV4L2_CID_IRIS_RELATIVE/constant controls to the +link linkend=camera-controlsCamera controls class/link. + /para +/listitem + /orderedlist /section section id=other diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index f464506..c412e89 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -1825,6 +1825,25 @@ wide-angle direction. The zoom speed unit is driver-specific./entry rowentry/entry/row row +entry spanname=idconstantV4L2_CID_IRIS_ABSOLUTE/constantnbsp;/entr y + entryinteger/entry + /rowrowentry spanname=descrThis control sets the +camera aperture's to the specified value. The unit is undefined. +Positive values open the iris, negative close it./entry + /row + rowentry/entry/row + + row +entry spanname=idconstantV4L2_CID_IRIS_RELATIVE/constantnbsp;/entr y + entryinteger/entry + /rowrowentry spanname=descrThis control modifies the +camera aperture's by the specified amount. The unit is undefined. +Positive values open the iris one step further, negative values close +it one step further. This is a write-only control./entry + /row + rowentry/entry/row + + row entry spanname=idconstantV4L2_CID_PRIVACY/constantnbsp;/entr y entryboolean/entry /rowrowentry spanname=descrPrevent video from being acquired Seems ok to me, but it would be good to add some sort of scale for those controls. I'd love to, but most iris controllers will just let you specify a value in an arbitrary scale (0 for closed, 255 for fully opened for instance). In that case do we want to force driver developers to measure the aperture in µm units with a micrometer caliper ? :-) : :) Well, maybe then you could just comment that higher values means more opened apertures. Could point, I will do. I spoke too fast, it's already there :-) Oh. OK then ;) Cheers, 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: Pull request: http://linuxtv.org/hg/~hgoede/gspca
Hans de Goede wrote: Hi, On 03/18/2010 01:25 PM, Mauro Carvalho Chehab wrote: Hans de Goede wrote: Hi Mauro, Please pull from: http://linuxtv.org/hg/~hgoede/gspca For the following changes: gspca_spca561: Fix LED on rev12a cameras gspca_spca561: Add support for camera button sn9c102: Make hv7131d sensor code also recognize the HV7131E gspca: make usb id 0461:0815 get handled by the right driver Hmm... something got wrong here: snip Maybe Douglas had to directly import some patches from -git, instead of pulling from -hg (or maybe you're just faster than Douglas, sending a new patch series before he finish the import of the older ones). Anyway, please, rebase your tree. Will do. This time, I just applied the last patches from the series. Thanks, note that you seem to have forgotten the last one: gspca: make usb id 0461:0815 get handled by the right driver It is at the separate fixes.git tree (locally only, for now). I'm not sure yet how we'll manage those fix patches during the two merge windows, as, if I pull from fixes.git, we move our development tree from 2.6.33 to 2.6.34-rc1. If otherwise I wait to merge it on the next window cycle, people using our trees may have troubles with things that got already fixed. Also, porting/porting back between our git trees and upstream cause troubles. Perhaps one alternative would be to move the backport tree to git. Another one would be to use incoming staging branches at their main tree (for example, patches for x86 tip tree go first to a branch). I need to think more about it and do some research before proposing something. Of couse, ideas are always welcome. Cheers, 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: 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:Thu Mar 18 19:00:19 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14493:514684e53dc6 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
RE: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on DM365
Please discard this patch. I have sent an updated version to the list.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, March 17, 2010 1:19 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Karicheri, Muralidharan
Subject: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on
DM365
From: Muralidharan Karicheri m-kariche...@ti.com
As part of upstream merge, set_params() function was removed from isif.c.
This requires
removal of BUG_ON() and check for set_params ptr in vpfe_capture.c.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 91f665b..aa7dd65 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -222,7 +222,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.get_frame_format);
BUG_ON(!dev-hw_ops.get_pixel_format);
BUG_ON(!dev-hw_ops.set_pixel_format);
- BUG_ON(!dev-hw_ops.set_params);
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
@@ -1704,16 +1703,19 @@ static long vpfe_param_handler(struct file *file,
void *priv,
case VPFE_CMD_S_CCDC_RAW_PARAMS:
v4l2_warn(vpfe_dev-v4l2_dev,
VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n);
- ret = ccdc_dev-hw_ops.set_params(param);
- if (ret) {
- v4l2_err(vpfe_dev-v4l2_dev,
- Error in setting parameters in CCDC\n);
- goto unlock_out;
- }
- if (vpfe_get_ccdc_image_format(vpfe_dev, vpfe_dev-fmt) 0) {
- v4l2_err(vpfe_dev-v4l2_dev,
- Invalid image format at CCDC\n);
- goto unlock_out;
+ if (ccdc_dev-hw_ops.set_params) {
+ ret = ccdc_dev-hw_ops.set_params(param);
+ if (ret) {
+ v4l2_err(vpfe_dev-v4l2_dev,
+ Error setting parameters in CCDC\n);
+ goto unlock_out;
+ }
+ if (vpfe_get_ccdc_image_format(vpfe_dev,
+ vpfe_dev-fmt) 0) {
+ v4l2_err(vpfe_dev-v4l2_dev,
+ Invalid image format at CCDC\n);
+ goto unlock_out;
+ }
}
break;
default:
--
1.6.0.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/RFC] videobuf refactoring
Hi all,
This patch is for discussion only. It is just to illustrate the possibilities.
Once the cleanup patch Pawel posted is merged, then I can try to make a proper
patch series for this depending on the feedback I get.
The more I look at the videobuf code the more it becomes clear that it is
absolute horrendous code. It's no wonder that it is so hard to use.
This patch is just a first phase at trying to bring some sense to the chaos.
The main changes are:
- All videobuf_qtype_ops now operate on buffers instead of whole queues.
Sometimes the queue is still passed, but in most cases that can probably
be avoided in the future. One restriction: the dma_sg needs to support
some V4L1 functionality where all buffers are mmapped with one mmap call.
This really requires videobuf_queue for now.
- Removed an unused op (mmap) and added a new one: vaddr. This returns
the virtual address of the buffer. This used to be vmalloc, but we are
not allocating anything, so that was a bad name,
- With the new vaddr op we can move the copy_stream and video_copy_to_user
ops to the videobuf core where they belong.
- I notice that after this patch the mmap_free op does the same thing for
all qtypes. This op can probably be removed. Frankly, I'm not sure what
it is supposed to do.
- Now that all qtype ops operate on a buffer the next step would be to move
the int_ops field from videobuf_queue to videobuf_buffer. Then that can be
used instead of the 'magic' values.
Is there anything in this patch that I shouldn't have done? I think this
would be a major improvement but perhaps there is something magical somewhere
that I don't know about.
Regards,
Hans
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index 471178e..5f6798e 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -99,8 +99,8 @@ int videobuf_iolock(struct videobuf_queue *q, struct
videobuf_buffer *vb,
void *videobuf_queue_to_vmalloc (struct videobuf_queue *q,
struct videobuf_buffer *buf)
{
- if (q-int_ops-vmalloc)
- return q-int_ops-vmalloc(buf);
+ if (q-int_ops-vaddr)
+ return q-int_ops-vaddr(buf);
else
return NULL;
}
@@ -298,15 +298,16 @@ static void videobuf_status(struct videobuf_queue *q,
struct v4l2_buffer *b,
static int __videobuf_mmap_free(struct videobuf_queue *q)
{
int i;
- int rc;
+ int rc = 0;
if (!q)
return 0;
MAGIC_CHECK(q-int_ops-magic, MAGIC_QTYPE_OPS);
-
- rc = CALL(q, mmap_free, q);
+ for (i = 0; !rc i VIDEO_MAX_FRAME; i++)
+ if (q-bufs[i])
+ rc = CALL(q, mmap_free, q, q-bufs[i]);
q-is_mmapped = 0;
@@ -782,6 +783,49 @@ static ssize_t videobuf_read_zerocopy(struct
videobuf_queue *q,
return retval;
}
+static int __videobuf_copy_to_user(struct videobuf_queue *q,
+ struct videobuf_buffer *buf,
+ char __user *data, size_t count,
+ int nonblocking)
+{
+ void *vaddr = CALL(q, vaddr, buf);
+
+ /* copy to userspace */
+ if (count buf-size - q-read_off)
+ count = buf-size - q-read_off;
+
+ if (copy_to_user(data, vaddr + q-read_off, count))
+ return -EFAULT;
+
+ return count;
+}
+
+static int __videobuf_copy_stream(struct videobuf_queue *q,
+ struct videobuf_buffer *buf,
+ char __user *data, size_t count, size_t pos,
+ int vbihack, int nonblocking)
+{
+ unsigned int *fc = CALL(q, vaddr, buf);
+
+ if (vbihack) {
+ /* dirty, undocumented hack -- pass the frame counter
+ * within the last four bytes of each vbi data block.
+ * We need that one to maintain backward compatibility
+ * to all vbi decoding software out there ... */
+ fc += (buf-size 2) - 1;
+ *fc = buf-field_count 1;
+ dprintk(1, vbihack: %d\n, *fc);
+ }
+
+ /* copy stuff using the common method */
+ count = __videobuf_copy_to_user(q, buf, data, count, nonblocking);
+
+ if ((count == -EFAULT) (pos == 0))
+ return -EFAULT;
+
+ return count;
+}
+
ssize_t videobuf_read_one(struct videobuf_queue *q,
char __user *data, size_t count, loff_t *ppos,
int nonblocking)
@@ -850,7 +894,7 @@ ssize_t videobuf_read_one(struct videobuf_queue *q,
}
/* Copy to userspace */
- retval = CALL(q, video_copy_to_user, q, data, count, nonblocking);
+ retval = __videobuf_copy_to_user(q, q-read_buf, data, count,
nonblocking);
if (retval 0)
goto done;
@@
