[RESEND][PATCH v2 2/6] OMAP1: Add support for SoC camera interface
This patch adds support for SoC camera interface to OMAP1 devices.
Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
For successfull compilation, requires a header file provided by PATCH 1/6 from
this series, "SoC Camera: add driver for OMAP1 camera interface".
Signed-off-by: Janusz Krzysztofik
---
Resend because of wrapped lines, sorry.
Janusz
v1->v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3
arch/arm/mach-omap1/devices.c | 43 ++
arch/arm/mach-omap1/include/mach/camera.h |8 +
2 files changed, 51 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c
linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c 2010-09-03
22:29:00.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c 2010-09-09
18:42:30.0 +0200
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -25,6 +26,7 @@
#include
#include
#include
+#include
/*-*/
@@ -191,6 +193,47 @@ static inline void omap_init_spi100k(voi
}
#endif
+
+#define OMAP1_CAMERA_BASE 0xfffb6800
+
+static struct resource omap1_camera_resources[] = {
+ [0] = {
+ .start = OMAP1_CAMERA_BASE,
+ .end= OMAP1_CAMERA_BASE + OMAP1_CAMERA_IOSIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = INT_CAMERA,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 omap1_camera_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device omap1_camera_device = {
+ .name = "omap1-camera",
+ .id = 0, /* This is used to put cameras on this interface */
+ .dev= {
+ .dma_mask = &omap1_camera_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .num_resources = ARRAY_SIZE(omap1_camera_resources),
+ .resource = omap1_camera_resources,
+};
+
+void __init omap1_set_camera_info(struct omap1_cam_platform_data *info)
+{
+ struct platform_device *dev = &omap1_camera_device;
+ int ret;
+
+ dev->dev.platform_data = info;
+
+ ret = platform_device_register(dev);
+ if (ret)
+ dev_err(&dev->dev, "unable to register device: %d\n", ret);
+}
+
+
/*-*/
static inline void omap_init_sti(void) {}
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
2010-09-03 22:34:03.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h 2010-09-09
18:42:30.0 +0200
@@ -0,0 +1,8 @@
+#ifndef __ASM_ARCH_CAMERA_H_
+#define __ASM_ARCH_CAMERA_H_
+
+#include
+
+extern void omap1_set_camera_info(struct omap1_cam_platform_data *);
+
+#endif /* __ASM_ARCH_CAMERA_H_ */
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/6] OMAP1: Amstrad Delta: add camera controlled LEDS trigger
This patch extends the Amstrad Delta camera support with LEDS trigger that can
be used for automatic control of the on-board camera LED. The led turns on
automatically on camera device open and turns off on camera device close.
Created and tested against linux-2.6.36-rc3.
Works on top of patch 5/6, "OMAP1: Amstrad Delta: add support for on-board
camera"
Signed-off-by: Janusz Krzysztofik
---
Having no comments received on v1 of this patch, I assume nobody could see any
benefit if I implemented this idea at the SoC camera or OMAP1 camera level,
so I'm leaveing it as an Amstrad Delta only feature, as it originally was for
v1.
Thanks,
Janusz
v1->v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3.
arch/arm/mach-omap1/board-ams-delta.c | 24
1 file changed, 24 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c
linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c 2010-09-10
22:01:24.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c 2010-09-10
22:08:29.0 +0200
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -222,11 +223,30 @@ static struct i2c_board_info ams_delta_c
},
};
+#ifdef CONFIG_LEDS_TRIGGERS
+DEFINE_LED_TRIGGER(ams_delta_camera_led_trigger);
+
+static int ams_delta_camera_power(struct device *dev, int power)
+{
+ /*
+* turn on camera LED
+*/
+ if (power)
+ led_trigger_event(ams_delta_camera_led_trigger, LED_FULL);
+ else
+ led_trigger_event(ams_delta_camera_led_trigger, LED_OFF);
+ return 0;
+}
+#else
+#define ams_delta_camera_power NULL
+#endif
+
static struct soc_camera_link __initdata ams_delta_iclink = {
.bus_id = 0,/* OMAP1 SoC camera bus */
.i2c_adapter_id = 1,
.board_info = &ams_delta_camera_board_info[0],
.module_name= "ov6650",
+ .power = ams_delta_camera_power,
};
static struct platform_device ams_delta_camera_device = {
@@ -281,6 +301,10 @@ static void __init ams_delta_init(void)
omap1_usb_init(&ams_delta_usb_config);
omap1_set_camera_info(&ams_delta_camera_platform_data);
+#ifdef CONFIG_LEDS_TRIGGERS
+ led_trigger_register_simple("ams_delta_camera",
+ &ams_delta_camera_led_trigger);
+#endif
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
#ifdef CONFIG_AMS_DELTA_FIQ
--
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 5/6] OMAP1: Amstrad Delta: add support for camera
This patch adds configuration data and initialization code required for camera
support to the Amstrad Delta board.
Three devices are declared: SoC camera, OMAP1 camera interface and OV6650
sensor.
Default 12MHz clock has been selected for driving the sensor. Pixel clock has
been limited to get reasonable frame rates, not exceeding the board
capabilities. Since both devices (interface and sensor) support both pixel
clock polarities, decision on polarity selection has been left to drivers.
Interface GPIO line has been found not functional, thus not configured.
Created and tested against linux-2.6.36-rc3.
Works on top of previous patches from the series, at least 1/6, 2/6 and 3/6.
Signed-off-by: Janusz Krzysztofik
---
v1->v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3
arch/arm/mach-omap1/board-ams-delta.c | 45 ++
1 file changed, 45 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c
linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c 2010-09-03
22:29:00.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c 2010-09-10
22:01:24.0 +0200
@@ -19,6 +19,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -32,6 +34,7 @@
#include
#include
#include
+#include
#include
@@ -213,10 +216,37 @@ static struct platform_device ams_delta_
.id = -1
};
+static struct i2c_board_info ams_delta_camera_board_info[] = {
+ {
+ I2C_BOARD_INFO("ov6650", 0x60),
+ },
+};
+
+static struct soc_camera_link __initdata ams_delta_iclink = {
+ .bus_id = 0,/* OMAP1 SoC camera bus */
+ .i2c_adapter_id = 1,
+ .board_info = &ams_delta_camera_board_info[0],
+ .module_name= "ov6650",
+};
+
+static struct platform_device ams_delta_camera_device = {
+ .name = "soc-camera-pdrv",
+ .id = 0,
+ .dev= {
+ .platform_data = &ams_delta_iclink,
+ },
+};
+
+static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
+ .camexclk_khz = 12000,/* default 12MHz clock, no extra DPLL */
+ .lclk_khz_max = 1334, /* results in 5fps CIF, 10fps QCIF */
+};
+
static struct platform_device *ams_delta_devices[] __initdata = {
&ams_delta_kp_device,
&ams_delta_lcd_device,
&ams_delta_led_device,
+ &ams_delta_camera_device,
};
static void __init ams_delta_init(void)
@@ -225,6 +255,20 @@ static void __init ams_delta_init(void)
omap_cfg_reg(UART1_TX);
omap_cfg_reg(UART1_RTS);
+ /* parallel camera interface */
+ omap_cfg_reg(H19_1610_CAM_EXCLK);
+ omap_cfg_reg(J15_1610_CAM_LCLK);
+ omap_cfg_reg(L18_1610_CAM_VS);
+ omap_cfg_reg(L15_1610_CAM_HS);
+ omap_cfg_reg(L19_1610_CAM_D0);
+ omap_cfg_reg(K14_1610_CAM_D1);
+ omap_cfg_reg(K15_1610_CAM_D2);
+ omap_cfg_reg(K19_1610_CAM_D3);
+ omap_cfg_reg(K18_1610_CAM_D4);
+ omap_cfg_reg(J14_1610_CAM_D5);
+ omap_cfg_reg(J19_1610_CAM_D6);
+ omap_cfg_reg(J18_1610_CAM_D7);
+
iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc));
omap_board_config = ams_delta_config;
@@ -236,6 +280,7 @@ static void __init ams_delta_init(void)
ams_delta_latch2_write(~0, 0);
omap1_usb_init(&ams_delta_usb_config);
+ omap1_set_camera_info(&ams_delta_camera_platform_data);
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
#ifdef CONFIG_AMS_DELTA_FIQ
--
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 4/6] SoC Camera: add support for g_parm / s_parm operations
This patch adds support for g_parm / s_parm operations to the SoC Camera
framework. It is usefull for checking/setting camera frame rate.
Example usage can be found in the previous patch from this series,
"SoC Camera: add driver for OV6650 sensor".
Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik
---
v1->v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3.
drivers/media/video/soc_camera.c | 18 ++
1 file changed, 18 insertions(+)
diff -upr linux-2.6.36-rc3.orig/drivers/media/video/soc_camera.c
linux-2.6.36-rc3/drivers/media/video/soc_camera.c
--- linux-2.6.36-rc3.orig/drivers/media/video/soc_camera.c 2010-09-03
22:29:44.0 +0200
+++ linux-2.6.36-rc3/drivers/media/video/soc_camera.c 2010-09-03
22:34:03.0 +0200
@@ -1148,6 +1148,20 @@ static int default_s_crop(struct soc_cam
return v4l2_subdev_call(sd, video, s_crop, a);
}
+static int default_g_parm(struct soc_camera_device *icd,
+ struct v4l2_streamparm *parm)
+{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ return v4l2_subdev_call(sd, video, g_parm, parm);
+}
+
+static int default_s_parm(struct soc_camera_device *icd,
+ struct v4l2_streamparm *parm)
+{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ return v4l2_subdev_call(sd, video, s_parm, parm);
+}
+
static void soc_camera_device_init(struct device *dev, void *pdata)
{
dev->platform_data = pdata;
@@ -1179,6 +1193,10 @@ int soc_camera_host_register(struct soc_
ici->ops->get_crop = default_g_crop;
if (!ici->ops->cropcap)
ici->ops->cropcap = default_cropcap;
+ if (!ici->ops->set_parm)
+ ici->ops->set_parm = default_s_parm;
+ if (!ici->ops->get_parm)
+ ici->ops->get_parm = default_g_parm;
mutex_lock(&list_lock);
list_for_each_entry(ix, &hosts, list) {
--
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 3/6] SoC Camera: add driver for OV6650 sensor
This patch provides a V4L2 SoC Camera driver for OV6650 camera sensor, found on OMAP1 SoC based Amstrad Delta videophone. Since I have no experience with camera sensors, and the sensor documentation I was able to find was not very comprehensive, I left most settings at their default (reset) values, except for: - those required for proper mediabus parameters and picture format setup, - those used by controls. Resulting picture quality is far from perfect, but better than nothing. In order to be able to get / set the sensor frame rate from userspace, I decided to provide two not yet SoC camera supported operations, g_parm and s_parm. These can be used after applying patch 4/6 from this series, "SoC Camera: add support for g_parm / s_parm operations". Created and tested against linux-2.6.36-rc3 on Amstrad Delta. Signed-off-by: Janusz Krzysztofik --- v1->v2 changes: requested by Guennadi Liakhovetski (thanks!): - include if using BIT() macro, - sort headers alphabetically, - don't mix tabs with spaces (preferred) when separating symbols from #define keywords, - drop unused NUM_REGS definition, - optimize SET_SAT() and SAT_MASK macros, - reuse no longer needed function argument instead of declaring a new local variable, - don't touch auto controls when changing their correspondig manual settings, and vice versa, - drop probably unsupported auto-hue control, - initialize sensor by writing registers explicitly instead of using a "magic" initialization array, - avoid gotos, don't use them other than in failure cases, - make pclk computation more readable, - implement g_mbus_fmt() callback, - correct a few obvious mistakes, - remove a few extra whitespaces, suggested by Ralph Corderoy (thanks!): - use one common format when hex printing register addresses and values, - optimize if(ret) vs. if(!ret) constructs usage, - replace a few if-else constructs with more compact, conditional expression based, when translating controls to register bits, - optimize ov6650_res_roundup(), - drop redundant cast of index from ov6650_enum_fmt(), - use variable identifiers rather than their types as sizeof() arguments, other: - disable band filter, auto exposure control seems working more effectively without it, - refresh against linux-2.6.36-rc3. drivers/media/video/Kconfig |6 drivers/media/video/Makefile|1 drivers/media/video/ov6650.c| 1242 include/media/v4l2-chip-ident.h |1 4 files changed, 1250 insertions(+) diff -upr linux-2.6.36-rc3.orig/drivers/media/video/Kconfig linux-2.6.36-rc3/drivers/media/video/Kconfig --- linux-2.6.36-rc3.orig/drivers/media/video/Kconfig 2010-09-03 22:34:02.0 +0200 +++ linux-2.6.36-rc3/drivers/media/video/Kconfig2010-09-03 22:34:02.0 +0200 @@ -835,6 +835,12 @@ config SOC_CAMERA_PLATFORM help This is a generic SoC camera platform driver, useful for testing +config SOC_CAMERA_OV6650 + tristate "ov6650 sensor support" + depends on SOC_CAMERA && I2C + ---help--- + This is a V4L2 SoC camera driver for the OmniVision OV6650 sensor + config SOC_CAMERA_OV772X tristate "ov772x camera support" depends on SOC_CAMERA && I2C diff -upr linux-2.6.36-rc3.orig/drivers/media/video/Makefile linux-2.6.36-rc3/drivers/media/video/Makefile --- linux-2.6.36-rc3.orig/drivers/media/video/Makefile 2010-09-03 22:34:02.0 +0200 +++ linux-2.6.36-rc3/drivers/media/video/Makefile 2010-09-03 22:34:02.0 +0200 @@ -79,6 +79,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o obj-$(CONFIG_SOC_CAMERA_MT9T112) += mt9t112.o obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o +obj-$(CONFIG_SOC_CAMERA_OV6650)+= ov6650.o obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o obj-$(CONFIG_SOC_CAMERA_OV9640)+= ov9640.o obj-$(CONFIG_SOC_CAMERA_RJ54N1)+= rj54n1cb0c.o diff -upr linux-2.6.36-rc3.orig/drivers/media/video/ov6650.c linux-2.6.36-rc3/drivers/media/video/ov6650.c --- linux-2.6.36-rc3.orig/drivers/media/video/ov6650.c 2010-09-03 22:34:02.0 +0200 +++ linux-2.6.36-rc3/drivers/media/video/ov6650.c 2010-09-04 17:50:32.0 +0200 @@ -0,0 +1,1242 @@ +/* + * V4L2 SoC Camera driver for OmniVision OV6650 Camera Sensor + * + * Copyright (C) 2010 Janusz Krzysztofik + * + * Based on OmniVision OV96xx Camera Driver + * Copyright (C) 2009 Marek Vasut + * + * Based on ov772x camera driver: + * Copyright (C) 2008 Renesas Solutions Corp. + * Kuninori Morimoto + * + * Based on ov7670 and soc_camera_platform driver, + * Copyright 2006-7 Jonathan Corbet + * Copyright (C) 2008 Magnus Damm + * Copyright (C) 2008, Guennadi Liakhovetski + * + * Hardware specific bits initialy based on former work by Matt Callow + * drivers/media/video/omap/sensor_ov6650.c + * Copyright (C) 2006 Matt Callow + * + * This pro
[PATCH v2 2/6] OMAP1: Add support for SoC camera interface
This patch adds support for SoC camera interface to OMAP1 devices.
Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
For successfull compilation, requires a header file provided by PATCH 1/6 from
this series, "SoC Camera: add driver for OMAP1 camera interface".
Signed-off-by: Janusz Krzysztofik
---
v1->v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3
arch/arm/mach-omap1/devices.c | 43
++
arch/arm/mach-omap1/include/mach/camera.h |8 +
2 files changed, 51 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c
linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c 2010-09-03
22:29:00.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c 2010-09-09
18:42:30.0 +0200
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -25,6 +26,7 @@
#include
#include
#include
+#include
/*-*/
@@ -191,6 +193,47 @@ static inline void omap_init_spi100k(voi
}
#endif
+
+#define OMAP1_CAMERA_BASE 0xfffb6800
+
+static struct resource omap1_camera_resources[] = {
+ [0] = {
+ .start = OMAP1_CAMERA_BASE,
+ .end= OMAP1_CAMERA_BASE + OMAP1_CAMERA_IOSIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = INT_CAMERA,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 omap1_camera_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device omap1_camera_device = {
+ .name = "omap1-camera",
+ .id = 0, /* This is used to put cameras on this interface */
+ .dev= {
+ .dma_mask = &omap1_camera_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .num_resources = ARRAY_SIZE(omap1_camera_resources),
+ .resource = omap1_camera_resources,
+};
+
+void __init omap1_set_camera_info(struct omap1_cam_platform_data *info)
+{
+ struct platform_device *dev = &omap1_camera_device;
+ int ret;
+
+ dev->dev.platform_data = info;
+
+ ret = platform_device_register(dev);
+ if (ret)
+ dev_err(&dev->dev, "unable to register device: %d\n", ret);
+}
+
+
/*-*/
static inline void omap_init_sti(void) {}
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
2010-09-03
22:34:03.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h 2010-09-09
18:42:30.0 +0200
@@ -0,0 +1,8 @@
+#ifndef __ASM_ARCH_CAMERA_H_
+#define __ASM_ARCH_CAMERA_H_
+
+#include
+
+extern void omap1_set_camera_info(struct omap1_cam_platform_data *);
+
+#endif /* __ASM_ARCH_CAMERA_H_ */
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/6] Add camera support to the OMAP1 Amstrad Delta videophone
This set consists of the following patches: 1/6 SoC Camera: add driver for OMAP1 camera interface 2/6 OMAP1: Add support for SoC camera interface 3/6 SoC Camera: add driver for OV6650 sensor 4/6 SoC Camera: add support for g_parm / s_parm operations 5/6 OMAP1: Amstrad Delta: add support for on-board camera 6/6 OMAP1: Amstrad Delta: add camera controlled LEDS trigger arch/arm/mach-omap1/board-ams-delta.c | 69 + arch/arm/mach-omap1/devices.c | 43 arch/arm/mach-omap1/include/mach/camera.h |8 drivers/media/video/Kconfig | 14 drivers/media/video/Makefile |2 drivers/media/video/omap1_camera.c| 1781 ++ drivers/media/video/ov6650.c | 1242 drivers/media/video/soc_camera.c | 18 include/media/omap1_camera.h | 35 include/media/v4l2-chip-ident.h |1 10 files changed, 3213 insertions(+) -- 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: Kernel Oops with Kernel 2.6.32
Hello, Can really nobody give me an advice what I can do to make my Nova-T-Stick work with my Debian Kernel 2.6.32? I want to add the information that I had it working with my Debian Kernel 2.6.26 and sources from linuxtv.org which I downloaded on April 09, 2009. Regards Christoph Hello, I am running a Debian 2.6.32-Kernel (which by the way contains a lot of unresolved symbols in many dvb modules). As this kernel does not support my WinTV Nova-T USB-Stick, I downloaded the latest sources via the web interface from linuxtv.org, compiled the sources and installed the resulting modules. When I now connect the USB stick, the DVB modules are loaded correctly, but when I start an application to watch TV, I get a Kernel Oops. These lines from my kern.log show the kernel actions when connecting the device: Sep 8 19:51:16 superstar kernel: [ 3480.084012] usb 2-5: new high speed USB device using ehci_hcd and address 3 Sep 8 19:51:16 superstar kernel: [ 3480.217755] usb 2-5: New USB device found, idVendor=2040, idProduct=7050 Sep 8 19:51:16 superstar kernel: [ 3480.217758] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Sep 8 19:51:16 superstar kernel: [ 3480.217760] usb 2-5: Product: Nova-T Stick Sep 8 19:51:16 superstar kernel: [ 3480.217761] usb 2-5: Manufacturer: Hauppauge Sep 8 19:51:16 superstar kernel: [ 3480.217762] usb 2-5: SerialNumber: 00 Sep 8 19:51:16 superstar kernel: [ 3480.217849] usb 2-5: configuration #1 chosen from 1 choice Sep 8 19:51:16 superstar kernel: [ 3480.332785] dib0700: loaded with support for 14 different device-types Sep 8 19:51:16 superstar kernel: [ 3480.333846] dvb-usb: found a 'Hauppauge Nova-T Stick' in cold state, will try to load a firmware Sep 8 19:51:16 superstar kernel: [ 3480.333851] usb 2-5: firmware: requesting dvb-usb-dib0700-1.20.fw Sep 8 19:51:16 superstar kernel: [ 3480.439083] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' Sep 8 19:51:17 superstar kernel: [ 3480.640502] dib0700: firmware started successfully. Sep 8 19:51:17 superstar kernel: [ 3481.144141] dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state. Sep 8 19:51:17 superstar kernel: [ 3481.144540] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Sep 8 19:51:17 superstar kernel: [ 3481.144639] DVB: registering new adapter (Hauppauge Nova-T Stick) Sep 8 19:51:17 superstar kernel: [ 3481.480505] DVB: registering adapter 0 frontend 0 (DiBcom 7000MA/MB/PA/PB/MC)... Sep 8 19:51:17 superstar kernel: [ 3481.498377] MT2060: successfully identified (IF1 = 1218) Sep 8 19:51:18 superstar kernel: [ 3481.975455] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:02.1/usb2/2-5/input/input6 Sep 8 19:51:18 superstar kernel: [ 3481.975500] dvb-usb: schedule remote query interval to 50 msecs. Sep 8 19:51:18 superstar kernel: [ 3481.975503] dvb-usb: Hauppauge Nova-T Stick successfully initialized and connected. Sep 8 19:51:18 superstar kernel: [ 3481.975777] usbcore: registered new interface driver dvb_usb_dib0700 These lines from my kern.log show the Oops event: Sep 8 19:51:28 superstar kernel: [ 3492.321914] BUG: unable to handle kernel NULL pointer dereference at 0012 Sep 8 19:51:28 superstar kernel: [ 3492.321920] IP: [] i2c_transfer+0x1c/0xc0 [i2c_core] Sep 8 19:51:28 superstar kernel: [ 3492.321928] PGD 1b8e69067 PUD 1b8e6a067 PMD 0 Sep 8 19:51:28 superstar kernel: [ 3492.321932] Oops: [#1] SMP Sep 8 19:51:28 superstar kernel: [ 3492.321934] last sysfs file: /sys/devices/pci:00/:00:02.1/usb2/2-5/input/input6/capabilities/sw Sep 8 19:51:28 superstar kernel: [ 3492.321936] CPU 0 Sep 8 19:51:28 superstar kernel: [ 3492.321938] Modules linked in: mt2060 dvb_usb_dib0700 dib7000p dib0090 dib7000m dib0070 dvb_usb dib8000 dvb_core dib30 00mc dibx000_common fglrx(P) binfmt_misc rfcomm l2cap crc16 bluetooth rfkill vboxnetadp vboxnetflt vboxdrv battery ppdev lp ext3 jbd mbcache xfs exportfs r eiserfs hwmon_vid eeprom firewire_sbp2 firewire_core crc_itu_t loop snd_hda_codec_atihdmi parport_pc parport psmouse evdev serio_raw snd_emu10k1_synth snd_ emux_synth snd_seq_virmidi snd_seq_midi_emul snd_hda_intel snd_hda_codec snd_emu10k1 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_seq_midi snd_pcm snd_rawmidi snd_util_mem asus_atk0110 snd_seq_midi_event snd_hwdep snd_seq snd_timer snd_seq_device emu10k1_gp pcspkr gameport snd snd_page_alloc soundcor e k8temp edac_core edac_mce_amd button processor i2c_nforce2 i2c_core jfs dm_mirror dm_region_hash dm_log dm_snapshot dm_mod sg sr_mod cdrom sd_mod crc_t10 dif ata_generic floppy fan pata_amd sata_nv ehci_hcd ohci_hcd libata thermal forcedeth thermal_sys scsi_mod usbcore nls_base [last unloaded: scsi_wait_scan ] Sep 8 19:51:28 superstar kernel: [ 3492.321984] Pid: 26841, comm: kaffeine Tainted: P 2.6.32-bpo.5-amd64 #1 System Product Name Sep 8 19:51:28 supersta
[cron job] v4l-dvb daily build 2.6.26 and up: 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:Fri Sep 10 19:00:12 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15139:6e0befab696a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328 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: WARNINGS linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.36-rc2-armv5: ERRORS linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35.3-armv5-davinci: WARNINGS linux-2.6.36-rc2-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35.3-armv5-ixp: WARNINGS linux-2.6.36-rc2-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35.3-armv5-omap2: WARNINGS linux-2.6.36-rc2-armv5-omap2: ERRORS 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-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-rc2-i686: ERRORS linux-2.6.32.6-m32r: WARNINGS linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.36-rc2-m32r: ERRORS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.36-rc2-mips: ERRORS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.36-rc2-powerpc64: ERRORS 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-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-rc2-x86_64: ERRORS linux-git-Module.symvers: ERRORS linux-git-armv5: ERRORS linux-git-armv5-davinci: ERRORS linux-git-armv5-ixp: ERRORS linux-git-armv5-omap2: ERRORS linux-git-i686: ERRORS linux-git-m32r: ERRORS linux-git-mips: ERRORS linux-git-powerpc64: ERRORS linux-git-x86_64: ERRORS spec: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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
[PATCH 1/5 v2] cx22702: Clean up register access functions
Hi Mauro,
On Fri, 10 Sep 2010 12:13:32 -0300, Mauro Carvalho Chehab wrote:
> Em 10-09-2010 10:27, Jean Delvare escreveu:
> > * Avoid temporary variables.
> > * Optimize success paths.
> > * Make error messages consistently verbose.
> >
> > Signed-off-by: Jean Delvare
> > Cc: Steven Toth
> > ---
> > drivers/media/dvb/frontends/cx22702.c | 23 +--
> > 1 file changed, 13 insertions(+), 10 deletions(-)
> >
> > --- linux-2.6.32-rc5.orig/drivers/media/dvb/frontends/cx22702.c
> > 2009-10-16 09:47:14.0 +0200
> > +++ linux-2.6.32-rc5/drivers/media/dvb/frontends/cx22702.c 2009-10-16
> > 09:47:45.0 +0200
> > @@ -92,33 +92,36 @@ static int cx22702_writereg(struct cx227
> >
> > ret = i2c_transfer(state->i2c, &msg, 1);
> >
> > - if (ret != 1)
> > + if (ret != 1) {
>
> As a suggestion, if you want to optimize success paths, you should use
> unlikely() for error
> checks. This tells gcc to optimize the code to avoid cache cleanups for the
> likely condition:
>
> if (unlikely(ret != 1)) {
Good point. Updated patch follows:
* * * * *
* Avoid temporary variables.
* Optimize success paths.
* Make error messages consistently verbose.
Signed-off-by: Jean Delvare
Cc: Steven Toth
---
Changes in v2:
* Use unlikely() to help gcc optimize the success paths.
drivers/media/dvb/frontends/cx22702.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
--- linux-2.6.35.orig/drivers/media/dvb/frontends/cx22702.c 2010-09-10
14:22:31.0 +0200
+++ linux-2.6.35/drivers/media/dvb/frontends/cx22702.c 2010-09-10
17:39:58.0 +0200
@@ -92,33 +92,36 @@ static int cx22702_writereg(struct cx227
ret = i2c_transfer(state->i2c, &msg, 1);
- if (ret != 1)
+ if (unlikely(ret != 1)) {
printk(KERN_ERR
"%s: error (reg == 0x%02x, val == 0x%02x, ret == %i)\n",
__func__, reg, data, ret);
+ return -1;
+ }
- return (ret != 1) ? -1 : 0;
+ return 0;
}
static u8 cx22702_readreg(struct cx22702_state *state, u8 reg)
{
int ret;
- u8 b0[] = { reg };
- u8 b1[] = { 0 };
+ u8 data;
struct i2c_msg msg[] = {
{ .addr = state->config->demod_address, .flags = 0,
- .buf = b0, .len = 1 },
+ .buf = ®, .len = 1 },
{ .addr = state->config->demod_address, .flags = I2C_M_RD,
- .buf = b1, .len = 1 } };
+ .buf = &data, .len = 1 } };
ret = i2c_transfer(state->i2c, msg, 2);
- if (ret != 2)
- printk(KERN_ERR "%s: readreg error (ret == %i)\n",
- __func__, ret);
+ if (unlikely(ret != 2)) {
+ printk(KERN_ERR "%s: error (reg == 0x%02x, ret == %i)\n",
+ __func__, reg, ret);
+ return 0;
+ }
- return b1[0];
+ return data;
}
static int cx22702_set_inversion(struct cx22702_state *state, int inversion)
--
Jean Delvare
--
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/5] cx22702: Clean up register access functions
Em 10-09-2010 10:27, Jean Delvare escreveu:
> * Avoid temporary variables.
> * Optimize success paths.
> * Make error messages consistently verbose.
>
> Signed-off-by: Jean Delvare
> Cc: Steven Toth
> ---
> drivers/media/dvb/frontends/cx22702.c | 23 +--
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> --- linux-2.6.32-rc5.orig/drivers/media/dvb/frontends/cx22702.c
> 2009-10-16 09:47:14.0 +0200
> +++ linux-2.6.32-rc5/drivers/media/dvb/frontends/cx22702.c2009-10-16
> 09:47:45.0 +0200
> @@ -92,33 +92,36 @@ static int cx22702_writereg(struct cx227
>
> ret = i2c_transfer(state->i2c, &msg, 1);
>
> - if (ret != 1)
> + if (ret != 1) {
As a suggestion, if you want to optimize success paths, you should use
unlikely() for error
checks. This tells gcc to optimize the code to avoid cache cleanups for the
likely condition:
if (unlikely(ret != 1)) {
> printk(KERN_ERR
> "%s: error (reg == 0x%02x, val == 0x%02x, ret == %i)\n",
> __func__, reg, data, ret);
> + return -1;
> + }
>
> - return (ret != 1) ? -1 : 0;
> + return 0;
> }
>
> static u8 cx22702_readreg(struct cx22702_state *state, u8 reg)
> {
> int ret;
> - u8 b0[] = { reg };
> - u8 b1[] = { 0 };
> + u8 data;
>
> struct i2c_msg msg[] = {
> { .addr = state->config->demod_address, .flags = 0,
> - .buf = b0, .len = 1 },
> + .buf = ®, .len = 1 },
> { .addr = state->config->demod_address, .flags = I2C_M_RD,
> - .buf = b1, .len = 1 } };
> + .buf = &data, .len = 1 } };
>
> ret = i2c_transfer(state->i2c, msg, 2);
>
> - if (ret != 2)
> - printk(KERN_ERR "%s: readreg error (ret == %i)\n",
> - __func__, ret);
> + if (ret != 2) {
Same comment applies here.
> + printk(KERN_ERR "%s: error (reg == 0x%02x, ret == %i)\n",
> + __func__, reg, ret);
> + return 0;
> + }
>
> - return b1[0];
> + return data;
> }
>
> static int cx22702_set_inversion(struct cx22702_state *state, int inversion)
>
--
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: DIKOM DK300: Kernel hangs after suspend to ram
On Tue, Sep 07, 2010 at 10:47:55PM +0200, andrea.amoros...@gmail.com wrote: > I'm trying to use my Dikom DK-300 usb dvb-t device connected to an > old laptop used as media player. > The device works well but if I suspend the pc to ram (S3) when the > Dikom usb stick is plugged in, the system hangs during the resume > phase. > So I've tried to create two scripts. The first one removes the driver > before sleeping (the script is in the /etc/acpi/suspend.d directory) > and the second one reloads it during the resume phase (this script is > in /etc/acpi/resume.d directory). > I've also inserted in the scripts some logs and it seems that the > driver is correctly removed before the suspension, but then the pc > hangs when resuming. > Do you have some suggestion on how to resolve? > I suspect that something in the GPIO setting is not corrected, but I > don't know very well how to check that (now I've access to a windows > xp virtualbox machine and a real windows vista system which maybe I > can use to test/debug the correctness of the patch I postes some > time ago). Can't help you with the driver, but for general suspend/resume debug: Did you try no_console_suspend to see if there are any errors? See Documentation/kernel-parameters.txt for more info. There are also some debugging hints in Documentation/power/s2ram.txt and basic-pm-debugging.txt. HTH Johannes -- 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 v1 0/7] Videobuf2 framework
On Fri, 2010-09-10 at 10:22 +0200, Hans Verkuil wrote: > On Friday, September 10, 2010 09:38:44 Marek Szyprowski wrote: > > Hello, > > > > On 2010-09-10 13:27, Mauro Carvalho Chehab wrote: > > > > >>> 1) it lacks implementation of read() method. This means that vivi driver > > >>> has a regression, as it currently supports it. > > >> > > >> Yes, read() is not yet implemented. I guess it is not a feature that > > >> would > > >> be deprecated, right? > > > > > > Yes, there are no plans to deprecate it. Also, some devices like cx88 and > > > bttv > > > allows receiving simultaneous streams, one via mmap, and another via > > > read(). > > > This is used by some applications to allow recording video via > > > ffmpeg/mencoder > > > using read(), while the main application is displaying video using mmap. > > > > Well, in my opinion such devices should provide two separate /dev/videoX > > nodes rather than hacking with mmap and read access types. > > 1) It is in use so you can't just drop it. > 2) The read() API is actually very useful for video devices that deal with >compressed video streams. E.g. you can do things like 'cat /dev/video0 > >foo.mpg' > > It's been a long standing wish to convert the ivtv and cx18 drivers to > videobuf, > but it's always been too complex. With a new vb2 implementation it may become > actually possible. Steven has mmap() mostly done for the cx18 YUV stream: http://www.kernellabs.com/hg/~stoth/cx18-videobuf/ I provided him a slew of comments on the patchset, The comments were mostly just grunt work to move things around and clean it up than any major flaws. I only saw one problem that must be fixed before it is usable for the masses, IIRC. Maybe if there's a test case for trying out videobuf2, it's the cx18 driver where we want to use mmap() for YUV and read() for MPEG. Note Steven's changes allow one to tell the CX23418 to send YUV data in YUYV format vs. HM12. 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] Illuminators and status LED controls
On Thu, 2010-09-09 at 08:07 +0200, Jean-Francois Moine wrote: > On Wed, 08 Sep 2010 20:58:18 +0200 > Hi, > > If I may resume this exchange: > > - the (microscope or device dependant) illuminators may be controlled > by v4l2, I agree. > - the status LED should be controlled by the LED interface. I agree. However, I think it is overkill based on my perception of future utilization by end users. I recommend ultimately implementing something in the v4l2 infrastructure that helps v4l2 drivers expose LEDs via the LED API easily and uniformly. Maybe that can start with a gspca framework implementation, which then evolves to the v4l2 infrastructure implementation. 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
[PATCH 5/5] cx22702: Simplify cx22702_set_tps()
Code in function cx22702_set_tps() can be slightly simplified.
Apparently gcc was smart enough to optimize it anyway, but it can't
hurt to make the code more readable.
Signed-off-by: Jean Delvare
Cc: Steven Toth
---
drivers/media/dvb/frontends/cx22702.c | 58 ++---
1 file changed, 26 insertions(+), 32 deletions(-)
--- linux-2.6.32-rc5.orig/drivers/media/dvb/frontends/cx22702.c 2009-10-17
14:50:42.0 +0200
+++ linux-2.6.32-rc5/drivers/media/dvb/frontends/cx22702.c 2009-10-17
16:12:39.0 +0200
@@ -316,33 +316,31 @@ static int cx22702_set_tps(struct dvb_fr
}
/* manually programmed values */
- val = 0;
- switch (p->u.ofdm.constellation) {
+ switch (p->u.ofdm.constellation) { /* mask 0x18 */
case QPSK:
- val = (val & 0xe7);
+ val = 0x00;
break;
case QAM_16:
- val = (val & 0xe7) | 0x08;
+ val = 0x08;
break;
case QAM_64:
- val = (val & 0xe7) | 0x10;
+ val = 0x10;
break;
default:
dprintk("%s: invalid constellation\n", __func__);
return -EINVAL;
}
- switch (p->u.ofdm.hierarchy_information) {
+ switch (p->u.ofdm.hierarchy_information) { /* mask 0x07 */
case HIERARCHY_NONE:
- val = (val & 0xf8);
break;
case HIERARCHY_1:
- val = (val & 0xf8) | 1;
+ val |= 0x01;
break;
case HIERARCHY_2:
- val = (val & 0xf8) | 2;
+ val |= 0x02;
break;
case HIERARCHY_4:
- val = (val & 0xf8) | 3;
+ val |= 0x03;
break;
default:
dprintk("%s: invalid hierarchy\n", __func__);
@@ -350,44 +348,42 @@ static int cx22702_set_tps(struct dvb_fr
}
cx22702_writereg(state, 0x06, val);
- val = 0;
- switch (p->u.ofdm.code_rate_HP) {
+ switch (p->u.ofdm.code_rate_HP) { /* mask 0x38 */
case FEC_NONE:
case FEC_1_2:
- val = (val & 0xc7);
+ val = 0x00;
break;
case FEC_2_3:
- val = (val & 0xc7) | 0x08;
+ val = 0x08;
break;
case FEC_3_4:
- val = (val & 0xc7) | 0x10;
+ val = 0x10;
break;
case FEC_5_6:
- val = (val & 0xc7) | 0x18;
+ val = 0x18;
break;
case FEC_7_8:
- val = (val & 0xc7) | 0x20;
+ val = 0x20;
break;
default:
dprintk("%s: invalid code_rate_HP\n", __func__);
return -EINVAL;
}
- switch (p->u.ofdm.code_rate_LP) {
+ switch (p->u.ofdm.code_rate_LP) { /* mask 0x07 */
case FEC_NONE:
case FEC_1_2:
- val = (val & 0xf8);
break;
case FEC_2_3:
- val = (val & 0xf8) | 1;
+ val |= 0x01;
break;
case FEC_3_4:
- val = (val & 0xf8) | 2;
+ val |= 0x02;
break;
case FEC_5_6:
- val = (val & 0xf8) | 3;
+ val |= 0x03;
break;
case FEC_7_8:
- val = (val & 0xf8) | 4;
+ val |= 0x04;
break;
default:
dprintk("%s: invalid code_rate_LP\n", __func__);
@@ -395,30 +391,28 @@ static int cx22702_set_tps(struct dvb_fr
}
cx22702_writereg(state, 0x07, val);
- val = 0;
- switch (p->u.ofdm.guard_interval) {
+ switch (p->u.ofdm.guard_interval) { /* mask 0x0c */
case GUARD_INTERVAL_1_32:
- val = (val & 0xf3);
+ val = 0x00;
break;
case GUARD_INTERVAL_1_16:
- val = (val & 0xf3) | 0x04;
+ val = 0x04;
break;
case GUARD_INTERVAL_1_8:
- val = (val & 0xf3) | 0x08;
+ val = 0x08;
break;
case GUARD_INTERVAL_1_4:
- val = (val & 0xf3) | 0x0c;
+ val = 0x0c;
break;
default:
dprintk("%s: invalid guard_interval\n", __func__);
return -EINVAL;
}
- switch (p->u.ofdm.transmission_mode) {
+ switch (p->u.ofdm.transmission_mode) { /* mask 0x03 */
case TRANSMISSION_MODE_2K:
- val = (val & 0xfc);
break;
case TRANSMISSION_MODE_8K:
- val = (val & 0xfc) | 1;
+ val |= 0x1;
break;
default:
dprintk("%s: invalid transmission_mode\n", __func__);
--
Jean Delvare
--
To unsubscribe from this list: send the
[PATCH 4/5] cx22702: Some things never change
The init sequence never changes so it can be marked const. Likewise,
cx22702_ops is a template and can thus be made read-only.
Signed-off-by: Jean Delvare
Cc: Steven Toth
---
drivers/media/dvb/frontends/cx22702.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.32-rc5.orig/drivers/media/dvb/frontends/cx22702.c 2009-10-17
14:49:50.0 +0200
+++ linux-2.6.32-rc5/drivers/media/dvb/frontends/cx22702.c 2009-10-18
11:44:09.0 +0200
@@ -54,7 +54,7 @@ MODULE_PARM_DESC(debug, "Enable verbose
#define dprintkif (debug) printk
/* Register values to initialise the demod */
-static u8 init_tab[] = {
+static const u8 init_tab[] = {
0x00, 0x00, /* Stop aquisition */
0x0B, 0x06,
0x09, 0x01,
@@ -576,7 +576,7 @@ static void cx22702_release(struct dvb_f
kfree(state);
}
-static struct dvb_frontend_ops cx22702_ops;
+static const struct dvb_frontend_ops cx22702_ops;
struct dvb_frontend *cx22702_attach(const struct cx22702_config *config,
struct i2c_adapter *i2c)
@@ -608,7 +608,7 @@ error:
}
EXPORT_SYMBOL(cx22702_attach);
-static struct dvb_frontend_ops cx22702_ops = {
+static const struct dvb_frontend_ops cx22702_ops = {
.info = {
.name = "Conexant CX22702 DVB-T",
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] cx22702: Avoid duplicating code in branches
Calling the same functions in if/else or switch/case branches is
inefficient. Refactor the code for a smaller binary and increased
readability.
Signed-off-by: Jean Delvare
Cc: Steven Toth
---
drivers/media/dvb/frontends/cx22702.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
--- linux-2.6.32-rc5.orig/drivers/media/dvb/frontends/cx22702.c 2009-10-24
16:12:18.0 +0200
+++ linux-2.6.32-rc5/drivers/media/dvb/frontends/cx22702.c 2009-10-24
16:27:04.0 +0200
@@ -128,19 +128,20 @@ static int cx22702_set_inversion(struct
{
u8 val;
+ val = cx22702_readreg(state, 0x0C);
switch (inversion) {
case INVERSION_AUTO:
return -EOPNOTSUPP;
case INVERSION_ON:
- val = cx22702_readreg(state, 0x0C);
- return cx22702_writereg(state, 0x0C, val | 0x01);
+ val |= 0x01;
+ break;
case INVERSION_OFF:
- val = cx22702_readreg(state, 0x0C);
- return cx22702_writereg(state, 0x0C, val & 0xfe);
+ val &= 0xfe;
+ break;
default:
return -EINVAL;
}
-
+ return cx22702_writereg(state, 0x0C, val);
}
/* Retrieve the demod settings */
@@ -247,13 +248,15 @@ static int cx22702_get_tps(struct cx2270
static int cx22702_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
{
struct cx22702_state *state = fe->demodulator_priv;
+ u8 val;
+
dprintk("%s(%d)\n", __func__, enable);
+ val = cx22702_readreg(state, 0x0D);
if (enable)
- return cx22702_writereg(state, 0x0D,
- cx22702_readreg(state, 0x0D) & 0xfe);
+ val &= 0xfe;
else
- return cx22702_writereg(state, 0x0D,
- cx22702_readreg(state, 0x0D) | 1);
+ val |= 0x01;
+ return cx22702_writereg(state, 0x0D, val);
}
/* Talk to the demod, set the FEC, GUARD, QAM settings etc */
@@ -273,23 +276,21 @@ static int cx22702_set_tps(struct dvb_fr
cx22702_set_inversion(state, p->inversion);
/* set bandwidth */
+ val = cx22702_readreg(state, 0x0C) & 0xcf;
switch (p->u.ofdm.bandwidth) {
case BANDWIDTH_6_MHZ:
- cx22702_writereg(state, 0x0C,
- (cx22702_readreg(state, 0x0C) & 0xcf) | 0x20);
+ val |= 0x20;
break;
case BANDWIDTH_7_MHZ:
- cx22702_writereg(state, 0x0C,
- (cx22702_readreg(state, 0x0C) & 0xcf) | 0x10);
+ val |= 0x10;
break;
case BANDWIDTH_8_MHZ:
- cx22702_writereg(state, 0x0C,
- cx22702_readreg(state, 0x0C) & 0xcf);
break;
default:
dprintk("%s: invalid bandwidth\n", __func__);
return -EINVAL;
}
+ cx22702_writereg(state, 0x0C, val);
p->u.ofdm.code_rate_LP = FEC_AUTO; /* temp hack as manual not working */
--
Jean Delvare
--
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/5] cx22702: Drop useless initializations to 0
These variables are either unconditionally set right afterward, or
already set to 0 by kzalloc.
Signed-off-by: Jean Delvare
Cc: Steven Toth
---
drivers/media/dvb/frontends/cx22702.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- linux-2.6.32-rc5.orig/drivers/media/dvb/frontends/cx22702.c 2009-10-17
14:01:34.0 +0200
+++ linux-2.6.32-rc5/drivers/media/dvb/frontends/cx22702.c 2009-10-17
14:23:48.0 +0200
@@ -508,7 +508,7 @@ static int cx22702_read_signal_strength(
{
struct cx22702_state *state = fe->demodulator_priv;
- u16 rs_ber = 0;
+ u16 rs_ber;
rs_ber = cx22702_readreg(state, 0x23);
*signal_strength = (rs_ber << 8) | rs_ber;
@@ -519,7 +519,7 @@ static int cx22702_read_snr(struct dvb_f
{
struct cx22702_state *state = fe->demodulator_priv;
- u16 rs_ber = 0;
+ u16 rs_ber;
if (cx22702_readreg(state, 0xE4) & 0x02) {
/* Realtime statistics */
rs_ber = (cx22702_readreg(state, 0xDE) & 0x7F) << 7
@@ -590,7 +590,6 @@ struct dvb_frontend *cx22702_attach(cons
/* setup the state */
state->config = config;
state->i2c = i2c;
- state->prevUCBlocks = 0;
/* check if the demod is there */
if (cx22702_readreg(state, 0x1f) != 0x3)
--
Jean Delvare
--
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] Illuminators and status LED controls
On Fri, 2010-09-10 at 09:19 +0200, Peter Korsgaard wrote: > > "Andy" == Andy Walls writes: > > Hi, > > Andy> Given choices I made when I patched up gspca/cpia1.c for my > Andy> prototype LED API usage, I got these associations > > Andy> By exposed LED name: > > Andy>/sys/class/leds/video0:white:illuminator0 > > Indeed. But didn't we just decide that illuminators were an integral > part of the video handling (similar to gain control), and only use the > LED API for status LEDs that don't directly interfere with the video > data? Hi Peter, Correct, I still want illuminators controlled by the V4L2 control API. The QX3 is the only unit I had to test with.I needed to prototype something so I could understand how the LED API worked. The Documentation/led-class.txt file does not explain things enough for an end user nor a developer to use the interface. Nothing in my desktop system currently exported LEDs. (git grep revealed that drivers dedicated to LED or GPIO chips, laptop led drivers, a few NIC drivers, and a some graphics devices were the major exporters of LEDs via the LED API. Nothing in my desktop system exported LEDs.) > Andy> The LED API has some shortcomings/annoyances: > > Andy> - The method a driver provides to set the LED brightness cannot sleep, > Andy> so a workqueue is needed to simply turn a hardware light on and off for > Andy> USB devices. > > Andy> - The Documentation is not very good for end-users or kernel developers > Andy> on using the LED API. > > No? I agree that the documentation is pretty minimalistic, but ok - It's > not that complicated. It is opaque to the unfamiliar. In a few Google searches, I could not find userspace application code or scripts that demonstrated use of the API. An average user will give up on using it, before rummaging through kernel code. Even after reading the minimal documentation and looking at the code, I improperly thought that more than one trigger could be set on an LED. I wasted time on figuring out these things, where I think the documentation could have easily helped: - names of kernel provided LED trigger modules - function/operation of each kernel provided LED trigger module - of the LED triggers that took parameters, what were the units - implementation difference between a simple and a complex LED trigger, not just the LED class design objective differences - location of a top level sysfs node that provides a list of all the LED triggers available - there is none. You need at least one LED exposed to see the global list. - that the LED core provides a simple suspend/resume, if drivers don't want to provide their own. And these, for which documentation will probably always lag: - What drivers expose LEDs - What drivers possibly provide LED trigger events, and what triggers pick them up. > Andy> - For an LED trigger not to override a user's desire to inhibit an LED, > Andy> the user needs to know to cancel all the triggers on an LED before > Andy> setting the LEDs brightness to 0. > > Only a single trigger can be active at a time for a given LED. Hmmm. I had supposed if I had a USB camera that has an LED and a button then I could provide triggers: video0_stream (for video stream stop/start events) video0_button0 (for button press events from the first button) then I could use these together to automatically turn the LED on and off when a stream started or stopped and allow the user to extinguish the LED by pressing the button. (As a prototype test case for the LED API, I was thinking of walking the two QX3 microscope illuminators through different brightness sequences when pressing the button, and having them both turn off when the stream stopped.) So instead I guess I would have write a single LED trigger that responds to all the event types I care to handle at once. Again, it would have been nice, if the documentation provided that as guidance. Explaining binding a trigger to an LED by referring to how a user changes I/O schedulers, doesn't help most users. Most end users have never needed to change the I/O scheduler. > Andy> Again, that happens to be the only real compelling use case I see for > Andy> using the LED API. However, I doubt many users will try to take > Andy> advantage of it, and I suspect even less will succeed in getting it > Andy> configured right. Good documentation could go a long way in correcting > Andy> that. > > That and using the LED for something else (perhaps with another trigger > like I eplained earlier with wlan/hdd activity). I personally don't think all the extra code in the V4L2 drivers is worth it for sharing a camera LED for other purposes. I don't see the average user really using it for Network or HDD activity, when userspace tools like GNOME system monitor provides a convenient display right on the desktop bar. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body
[PATCH 1/5] cx22702: Clean up register access functions
* Avoid temporary variables.
* Optimize success paths.
* Make error messages consistently verbose.
Signed-off-by: Jean Delvare
Cc: Steven Toth
---
drivers/media/dvb/frontends/cx22702.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
--- linux-2.6.32-rc5.orig/drivers/media/dvb/frontends/cx22702.c 2009-10-16
09:47:14.0 +0200
+++ linux-2.6.32-rc5/drivers/media/dvb/frontends/cx22702.c 2009-10-16
09:47:45.0 +0200
@@ -92,33 +92,36 @@ static int cx22702_writereg(struct cx227
ret = i2c_transfer(state->i2c, &msg, 1);
- if (ret != 1)
+ if (ret != 1) {
printk(KERN_ERR
"%s: error (reg == 0x%02x, val == 0x%02x, ret == %i)\n",
__func__, reg, data, ret);
+ return -1;
+ }
- return (ret != 1) ? -1 : 0;
+ return 0;
}
static u8 cx22702_readreg(struct cx22702_state *state, u8 reg)
{
int ret;
- u8 b0[] = { reg };
- u8 b1[] = { 0 };
+ u8 data;
struct i2c_msg msg[] = {
{ .addr = state->config->demod_address, .flags = 0,
- .buf = b0, .len = 1 },
+ .buf = ®, .len = 1 },
{ .addr = state->config->demod_address, .flags = I2C_M_RD,
- .buf = b1, .len = 1 } };
+ .buf = &data, .len = 1 } };
ret = i2c_transfer(state->i2c, msg, 2);
- if (ret != 2)
- printk(KERN_ERR "%s: readreg error (ret == %i)\n",
- __func__, ret);
+ if (ret != 2) {
+ printk(KERN_ERR "%s: error (reg == 0x%02x, ret == %i)\n",
+ __func__, reg, ret);
+ return 0;
+ }
- return b1[0];
+ return data;
}
static int cx22702_set_inversion(struct cx22702_state *state, int inversion)
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Fri, Sep 10, 2010 at 11:35:23AM +0300, Maxim Levitsky wrote: > On Thu, 2010-09-09 at 22:01 -0400, Jarod Wilson wrote: > > On Thu, Sep 09, 2010 at 12:34:27AM -0400, Jarod Wilson wrote: > > ... > > > >> For now, I've applied patches 3, 4 and 5, as it is nice to have > > > >> Jarod's review also. > > > > > > > > I've finally got them all applied atop current media_tree > > > > staging/v2.6.37, > > > > though none of the streamzap bits in patch 7 are applicable any longer. > > > > Will try to get through looking and commenting (and testing) of the rest > > > > of them tonight. > > > > > > Also had to make a minor addition to the rc5-sz decoder (same change > > > as in the other decoders). Almost have all the requisite test kernels > > > for David's, Maxim's and Dmitry's patchsets built and installed, wish > > > my laptop was faster... Probably would have been faster to use a lab > > > box and copy data over. Oh well. So functional testing to hopefully > > > commence tomorrow morning. > > > > Wuff. None of the three builds is at all stable on my laptop, but I can't > > actually point the finger at any of the three patchsets, since I'm getting > > spontaneous lockups doing nothing at all before even plugging in a > > receiver. I did however get occasional periods of a non-panicking (not > > starting X seems to help a lot). Initial results: > > > > Btw, my printk blackbox patch could help you a lot. > I can't count how many times it helped me. > I just enable softlockup, hardlockup, and nmi watchdog, and let system > panic on oopses, and reboot. Or if you have hardware reboot button, you > can just use it. The point is that most BIOSES don't clear the ram, and > I take advantage of that. Interesting. I was thinking perhaps I'd give a go at trying kdump on my laptop, but I've had pretty mixed results with kdump working correctly on random kernels (generally works quite well in RHEL, notsomuch in Fedora). My hope is that this is something already fixed in later Linus' kernels, so I'll try a current Linus snap before I try looking any deeper. I'll file this away for consideration though! -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Clean-ups to the cx22702 frontend driver
Hi all, hi Steven, I wrote these 5 patches cleaning up the cx22702 frontend driver a long time ago, I've been using them for months, so it's probably about time that I post them for review and, hopefully, upstream inclusion. Note that I unfortunately do not have access to the CX22702 datasheet, so my changes are based solely on analysis of the original code, and testing with a real chip (on my WinFast DTV1000-T.) [PATCH 1/5] cx22702: Clean up register access functions [PATCH 2/5] cx22702: Drop useless initializations to 0 [PATCH 3/5] cx22702: Avoid duplicating code in branches [PATCH 4/5] cx22702: Some things never change [PATCH 5/5] cx22702: Simplify cx22702_set_tps() Reviews/comments welcome, of course. -- Jean Delvare -- 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 5/8] IR: extend MCE keymap.
On Fri, Sep 10, 2010 at 10:27:02AM +0200, David Härdeman wrote: > On Fri, September 10, 2010 03:37, Jarod Wilson wrote: > > I think for mythtv, we're going to end up having a daemon process with > > elevated privs that reads directly from input devices to get around > > this annoyance, until such time as the annoyance is gone. > > A similar approach could work for XBMC since it already has input plugins > (e.g. for using a Nintendo Wii controller, etc). While attempting to drift off to sleep last night, it occurred to me that lircd already has support for attaching to input devices, so it might be an option to extend lircd and the lirc client library to have a "pass raw keycodes" mode. Both xmbc and mythtv already have options to build in lirc client support, so it'd just be minor extension of its use in both cases, at least in theory... -- Jarod Wilson ja...@redhat.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 5/8] IR: extend MCE keymap.
On Fri, Sep 10, 2010 at 11:40:31AM +0300, Maxim Levitsky wrote: > On Thu, 2010-09-09 at 21:37 -0400, Jarod Wilson wrote: > > On Thu, Sep 9, 2010 at 8:40 PM, Maxim Levitsky > > wrote: > > > On Wed, 2010-09-08 at 10:47 -0400, Jarod Wilson wrote: > > >> On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky > > >> wrote: > > >> > These keys are found on remote bundled with > > >> > Toshiba Qosmio F50-10q. > > >> > > > >> > Found and tested by, Sami R > > >> > > > >> > Signed-off-by: Maxim Levitsky > > >> > --- > > >> > drivers/media/IR/keymaps/rc-rc6-mce.c |3 +++ > > >> > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > > > Tommorow I will resend that patch with even more scancodes. > > > > Saw the discussion on irc. Feel your pain big-time on the X server > > limitation on keycodes. Its put a big damper on efforts to add native > > support to mythtv. Peter Hutterer's libXi2 cookbook tutorials talk a > > good game about how libXi2 supports 32-bit keycodes, but neglects to > > mention that the X server still gobbles up anything above 248 or 255 > > or whatever it is, and remedying that is no small task. :( > > > > I think for mythtv, we're going to end up having a daemon process with > > elevated privs that reads directly from input devices to get around > > this annoyance, until such time as the annoyance is gone. > > Btw, indeed Xi2 still doesn't pass > 248 keycodes, just tested that with > -git versions of X stack from about 2 months ago. > However this can be fixed relatively easily. > Maybe even I could do that. > > The big problem is however about ability to map extended keycodes to > actions, thing that should be provided by XKB2, which we will see > probably when DNF is released on Phantom console... > Also this will need lots of changes in toolkits. > Thats the problem I don't have resources to fix. Yeah, that's exactly what I got from Peter when I was asking him about this issue on irc -- X server can be modified fairly easily, but there's the arduous and undesirable task of making all the toolkits and whatnot behave again, and nobody in their right mind really *wants* to dig into xkb. :) -- Jarod Wilson ja...@redhat.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 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Fri, Sep 10, 2010 at 10:08:24AM +0200, David Härdeman wrote: > On Fri, September 10, 2010 04:01, Jarod Wilson wrote: > > Wuff. None of the three builds is at all stable on my laptop, but I can't > > actually point the finger at any of the three patchsets, since I'm getting > > spontaneous lockups doing nothing at all before even plugging in a > > receiver. I did however get occasional periods of a non-panicking (not > > starting X seems to help a lot). Initial results: > > If you get lockups without even plugging in a receiver, does that mean > that the rc-core driver hasn't even been loaded at that point? Correct, no rc-core bits loaded at all at this point. -- Jarod Wilson ja...@redhat.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 v1 0/7] Videobuf2 framework
Em 10-09-2010 04:38, Marek Szyprowski escreveu: > Hello, > > On 2010-09-10 13:27, Mauro Carvalho Chehab wrote: > 1) it lacks implementation of read() method. This means that vivi driver has a regression, as it currently supports it. >>> >>> Yes, read() is not yet implemented. I guess it is not a feature that would >>> be deprecated, right? >> >> Yes, there are no plans to deprecate it. Also, some devices like cx88 and >> bttv >> allows receiving simultaneous streams, one via mmap, and another via read(). >> This is used by some applications to allow recording video via >> ffmpeg/mencoder >> using read(), while the main application is displaying video using mmap. > > Well, in my opinion such devices should provide two separate /dev/videoX > nodes rather than hacking with mmap and read access types. Why? V4L2 API allows to have multiple applications opening and streaming. There's nothing wrong with that, since it is a common practice in Unix to allow multiple opens for the same device. 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: [GIT PULL FOR 2.6.37] new AF9015 devices
Hi
On Friday 10 September 2010, Antti Palosaari wrote:
> sure yet how to distinguish between the
> > "Cinergy T Dual" and my "Cinergy T RC MKII":
>
>
> > Given that keys, once pressed, remain to be stuck, using both lirc's
> > dev/input and without any dæmon trying to catch keypresses, I have not
> > reached a functional configuration.
>
> That`s known issue. Chip configures USB HID polling interval wrongly and
> due to that HID starts repeating usually. There is USB-ID mapped quir
Yes, now I see it. A quickly hacked test seems to improve the stuck key
events a lot (some keys still have a tendency to get stuck, but in general
it works):
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -45,6 +45,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD
},
{ USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016,
HID_QUIRK_FULLSPEED_INTERVAL },
+ { 0x0ccd, 0x0097, HID_QUIRK_FULLSPEED_INTERVAL },
{ USB_VENDOR_ID_ETURBOTOUCH, USB_DEVICE_ID_ETURBOTOUCH,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_PANTHERLORD,
USB_DEVICE_ID_PANTHERLORD_TWIN_USB_JOYSTICK, HID_QUIRK_MULTI_INPUT |
HID_QUIRK_SKIP_OUTPUT_REPORTS },
Regards
Stefan Lippers-Hollmann
--
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 PULL FOR 2.6.37] new AF9015 devices
On 09/10/2010 03:54 AM, Stefan Lippers-Hollmann wrote: Another test and some further debugging of the IR core usedby the af9015 branch of this git tree led me to partial success. DVB-T functionality continues to be fine and I've now found the proper values for this remote, however once a key gets pressed, it is never released (unless another key gets pressed which is then struck or unless I ctrl-c it (only works on terminals). Likewise I'm not sure yet how to distinguish between the "Cinergy T Dual" and my "Cinergy T RC MKII": Given that keys, once pressed, remain to be stuck, using both lirc's dev/input and without any dæmon trying to catch keypresses, I have not reached a functional configuration. That`s known issue. Chip configures USB HID polling interval wrongly and due to that HID starts repeating usually. There is USB-ID mapped quirks in HID driver to avoid that, but only for few ADF9015 IDs... I know how to fix that totally. I have been waiting new IR core merge before switch remote from broken HID + polling to memory read based one. But maybe I can do it just now and convert it later to IR core. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v2] media: Add timberdale video-in driver
This patch adds the timberdale video-in driver.
The video IP of timberdale delivers the video data via DMA.
The driver uses the DMA api to handle DMA transfers, and make use
of the V4L2 video buffers to handle buffers against user space.
If available the driver uses an encoder to get/set the video standard
Signed-off-by: Richard Röjfors
---
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f6e4d04..1afbe26 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -734,6 +734,15 @@ config VIDEO_HEXIUM_GEMINI
To compile this driver as a module, choose M here: the
module will be called hexium_gemini.
+config VIDEO_TIMBERDALE
+ tristate "Support for timberdale Video In/LogiWIN"
+ depends on VIDEO_V4L2 && I2C
+ select TIMB_DMA
+ select VIDEO_ADV7180
+ select VIDEOBUF_DMA_CONTIG
+ ---help---
+ Add support for the Video In peripherial of the timberdale FPGA.
+
source "drivers/media/video/cx88/Kconfig"
source "drivers/media/video/cx23885/Kconfig"
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 40f98fb..c93af35 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_VIDEO_CPIA2) += cpia2/
obj-$(CONFIG_VIDEO_MXB) += mxb.o
obj-$(CONFIG_VIDEO_HEXIUM_ORION) += hexium_orion.o
obj-$(CONFIG_VIDEO_HEXIUM_GEMINI) += hexium_gemini.o
+obj-$(CONFIG_VIDEO_TIMBERDALE) += timblogiw.o
obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o
obj-$(CONFIG_VIDEOBUF_DMA_SG) += videobuf-dma-sg.o
diff --git a/drivers/media/video/timblogiw.c b/drivers/media/video/timblogiw.c
new file mode 100644
index 000..549c0be
--- /dev/null
+++ b/drivers/media/video/timblogiw.c
@@ -0,0 +1,881 @@
+/*
+ * timblogiw.c timberdale FPGA LogiWin Video In driver
+ * Copyright (c) 2009-2010 Intel Corporation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/* Supports:
+ * Timberdale FPGA LogiWin Video In
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"timb-video"
+
+#define TIMBLOGIWIN_NAME "Timberdale Video-In"
+#define TIMBLOGIW_VERSION_CODE 0x04
+
+#define TIMBLOGIW_LINES_PER_DESC 44
+#define TIMBLOGIW_MAX_VIDEO_MEM16
+
+#define TIMBLOGIW_HAS_DECODER(lw) (lw->pdata.encoder.module_name)
+
+
+struct timblogiw {
+ struct video_device video_dev;
+ struct v4l2_device v4l2_dev; /* mutual exclusion */
+ struct mutexlock;
+ struct device *dev;
+ struct timb_video_platform_data pdata;
+ struct v4l2_subdev *sd_enc;/* encoder */
+ boolopened;
+};
+
+struct timblogiw_tvnorm {
+ v4l2_std_id std;
+ u16 width;
+ u16 height;
+ u8 fps;
+};
+
+struct timblogiw_fh {
+ struct videobuf_queue vb_vidq;
+ struct timblogiw_tvnorm const *cur_norm;
+ struct list_headcapture;
+ struct dma_chan *chan;
+ spinlock_t queue_lock; /* mutual exclusion */
+ unsigned intframe_count;
+};
+
+struct timblogiw_buffer {
+ /* common v4l buffer stuff -- must be first */
+ struct videobuf_buffer vb;
+ struct scatterlist sg[16];
+ dma_cookie_tcookie;
+ struct timblogiw_fh *fh;
+};
+
+const struct timblogiw_tvnorm timblogiw_tvnorms[] = {
+ {
+ .std= V4L2_STD_PAL,
+ .width = 720,
+ .height = 576,
+ .fps= 25
+ },
+ {
+ .std= V4L2_STD_NTSC,
+ .width = 720,
+ .height = 480,
+ .fps= 30
+ }
+};
+
+static int timblogiw_bytes_per_line(const struct timblogiw_tvnorm *norm)
+{
+ return norm->width * 2;
+}
+
+
+static int timblogiw_frame_size(const struct timblogiw_tvnorm *norm)
+{
+ return norm->height * timblogiw_bytes_per_line(norm);
+}
+
+static const struct timblogiw_tvnorm *timblogiw_get
[PATCH 2/2 v2] mfd: Add timberdale video-in driver to timberdale
This patch defines platform data for the video-in driver
and adds it to all configurations of timberdale.
Signed-off-by: Richard Röjfors
---
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index ac59950..52a651b 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -40,6 +40,7 @@
#include
#include
+#include
#include
@@ -238,7 +239,24 @@ static const __devinitconst struct resource
timberdale_uartlite_resources[] = {
},
};
-static const __devinitconst struct resource timberdale_radio_resources[] = {
+static __devinitdata struct i2c_board_info timberdale_adv7180_i2c_board_info =
{
+ /* Requires jumper JP9 to be off */
+ I2C_BOARD_INFO("adv7180", 0x42 >> 1),
+ .irq = IRQ_TIMBERDALE_ADV7180
+};
+
+static __devinitdata struct timb_video_platform_data
+ timberdale_video_platform_data = {
+ .dma_channel = DMA_VIDEO_RX,
+ .i2c_adapter = 0,
+ .encoder = {
+ .module_name = "adv7180",
+ .info = &timberdale_adv7180_i2c_board_info
+ }
+};
+
+static const __devinitconst struct resource
+timberdale_radio_resources[] = {
{
.start = RDSOFFSET,
.end= RDSEND,
@@ -272,6 +290,18 @@ static __devinitdata struct timb_radio_platform_data
}
};
+static const __devinitconst struct resource timberdale_video_resources[] = {
+ {
+ .start = LOGIWOFFSET,
+ .end= LOGIWEND,
+ .flags = IORESOURCE_MEM,
+ },
+ /*
+ note that the "frame buffer" is located in DMA area
+ starting at 0x120
+ */
+};
+
static __devinitdata struct timb_dma_platform_data timb_dma_platform_data = {
.nr_channels = 10,
.channels = {
@@ -372,6 +402,13 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg0[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+ .name = "timb-video",
+ .num_resources = ARRAY_SIZE(timberdale_video_resources),
+ .resources = timberdale_video_resources,
+ .platform_data = &timberdale_video_platform_data,
+ .data_size = sizeof(timberdale_video_platform_data),
+ },
+ {
.name = "timb-radio",
.num_resources = ARRAY_SIZE(timberdale_radio_resources),
.resources = timberdale_radio_resources,
@@ -430,6 +467,13 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg1[] = {
.resources = timberdale_mlogicore_resources,
},
{
+ .name = "timb-video",
+ .num_resources = ARRAY_SIZE(timberdale_video_resources),
+ .resources = timberdale_video_resources,
+ .platform_data = &timberdale_video_platform_data,
+ .data_size = sizeof(timberdale_video_platform_data),
+ },
+ {
.name = "timb-radio",
.num_resources = ARRAY_SIZE(timberdale_radio_resources),
.resources = timberdale_radio_resources,
@@ -478,6 +522,13 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg2[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+ .name = "timb-video",
+ .num_resources = ARRAY_SIZE(timberdale_video_resources),
+ .resources = timberdale_video_resources,
+ .platform_data = &timberdale_video_platform_data,
+ .data_size = sizeof(timberdale_video_platform_data),
+ },
+ {
.name = "timb-radio",
.num_resources = ARRAY_SIZE(timberdale_radio_resources),
.resources = timberdale_radio_resources,
@@ -521,6 +572,13 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg3[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+ .name = "timb-video",
+ .num_resources = ARRAY_SIZE(timberdale_video_resources),
+ .resources = timberdale_video_resources,
+ .platform_data = &timberdale_video_platform_data,
+ .data_size = sizeof(timberdale_video_platform_data),
+ },
+ {
.name = "timb-radio",
.num_resources = ARRAY_SIZE(timberdale_radio_resources),
.resources = timberdale_radio_resources,
diff --git a/drivers/mfd/timberdale.h b/drivers/mfd/timberdale.h
index c11bf6e..4412acd 100644
--- a/drivers/mfd/timberdale.h
+++ b/drivers/mfd/timberdale.h
@@ -23,7 +23,7 @@
#ifndef MFD_TIMBERDALE_H
#define MFD_TIMBERDALE_H
-#define DRV_VERSION"0.2"
+#define DRV_VERSION"0.3"
/* This driver only support versions >= 3.8 and < 4.0 */
#define TIMB_SUPPORTED_MAJOR 3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kern
[PATCH 0/2 v2] media, mfd: Add timberdale video-in driver
To follow are two patches. The first adds the timberdale video-in driver to the media tree. The second adds it to the timberdale MFD driver. As Mauro pointed out earlier the patch to timberdale should be trivial so I hope Mauro can take the patches via his tree. Thanks --Richard -- 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: [RESEND][PATCH 1/2] media: Add timberdale video-in driver
Thanks for the feedback, I will post an updated patch. Comments below.
On 09/08/2010 09:35 PM, Mauro Carvalho Chehab wrote:
Em 02-09-2010 08:56, Richard Röjfors escreveu:
This patch adds the timberdale video-in driver.
The video IP of timberdale delivers the video data via DMA.
The driver uses the DMA api to handle DMA transfers, and make use
of the V4L2 video buffers to handle buffers against user space.
If available the driver uses an encoder to get/set the video standard
Signed-off-by: Richard Röjfors
---
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f6e4d04..1afbe26 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -734,6 +734,15 @@ config VIDEO_HEXIUM_GEMINI
To compile this driver as a module, choose M here: the
module will be called hexium_gemini.
+config VIDEO_TIMBERDALE
+ tristate "Support for timberdale Video In/LogiWIN"
+ depends on VIDEO_V4L2&& I2C
+ select TIMB_DMA
+ select VIDEO_ADV7180
+ select VIDEOBUF_DMA_CONTIG
+ ---help---
+ Add support for the Video In peripherial of the timberdale FPGA.
+
source "drivers/media/video/cx88/Kconfig"
source "drivers/media/video/cx23885/Kconfig"
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 40f98fb..c93af35 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_VIDEO_CPIA2) += cpia2/
obj-$(CONFIG_VIDEO_MXB) += mxb.o
obj-$(CONFIG_VIDEO_HEXIUM_ORION) += hexium_orion.o
obj-$(CONFIG_VIDEO_HEXIUM_GEMINI) += hexium_gemini.o
+obj-$(CONFIG_VIDEO_TIMBERDALE) += timblogiw.o
obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o
obj-$(CONFIG_VIDEOBUF_DMA_SG) += videobuf-dma-sg.o
diff --git a/drivers/media/video/timblogiw.c b/drivers/media/video/timblogiw.c
new file mode 100644
index 000..1ccc620
--- /dev/null
+++ b/drivers/media/video/timblogiw.c
@@ -0,0 +1,877 @@
+/*
+ * timblogiw.c timberdale FPGA LogiWin Video In driver
+ * Copyright (c) 2009-2010 Intel Corporation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/* Supports:
+ * Timberdale FPGA LogiWin Video In
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"timb-video"
+
+#define TIMBLOGIWIN_NAME "Timberdale Video-In"
+#define TIMBLOGIW_VERSION_CODE 0x04
+
+#define TIMBLOGIW_LINES_PER_DESC 44
+#define TIMBLOGIW_MAX_VIDEO_MEM16
+
+#define TIMBLOGIW_VIDEO_FORMAT V4L2_PIX_FMT_UYVY
Hmm... why are you using a constant here? Does this device provide the standard
UYVY fourcc
format, or does it have a different (proprietary) format?
I will change to use the V4L2 define in the code instead of an own. The framegrabber follows the
standard.
If it uses the standard format, just use the standard definition. Otherwise, we
need to add a
new format to the V4L2 API, to make sure that userspace applications and libv4l
will properly
handle it.
+
+#define TIMBLOGIW_HAS_DECODER(lw) (lw->pdata.encoder.module_name)
+
+
+struct timblogiw {
+ struct video_device video_dev;
+ struct v4l2_device v4l2_dev; /* mutual exclusion */
+ struct mutexlock;
+ struct device *dev;
+ struct timb_video_platform_data pdata;
+ struct v4l2_subdev *sd_enc;/* encoder */
+ boolopened;
+};
+
+struct timblogiw_tvnorm {
+ v4l2_std_id std;
+ u16 width;
+ u16 height;
+ u8 fps;
+};
+
+struct timblogiw_fh {
+ struct videobuf_queue vb_vidq;
+ struct timblogiw_tvnorm const *cur_norm;
+ struct list_headcapture;
+ struct dma_chan *chan;
+ spinlock_t queue_lock; /* mutual exclusion */
+ unsigned intframe_count;
+};
+
+struct timblogiw_buffer {
+ /* common v4l buffer stuff -- must be first */
+ struct videobuf_buffer vb;
+ struct scatterlist sg[16];
+ dma_cookie_tcookie;
+ struct timblogiw_fh *fh;
+};
+
+const struct timblogiw_tvnorm timblogiw_tvnorms[] = {
+ {
+ .std
Re: [PATCH 5/8] IR: extend MCE keymap.
On Thu, 2010-09-09 at 21:37 -0400, Jarod Wilson wrote: > On Thu, Sep 9, 2010 at 8:40 PM, Maxim Levitsky > wrote: > > On Wed, 2010-09-08 at 10:47 -0400, Jarod Wilson wrote: > >> On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky > >> wrote: > >> > These keys are found on remote bundled with > >> > Toshiba Qosmio F50-10q. > >> > > >> > Found and tested by, Sami R > >> > > >> > Signed-off-by: Maxim Levitsky > >> > --- > >> > drivers/media/IR/keymaps/rc-rc6-mce.c |3 +++ > >> > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > Tommorow I will resend that patch with even more scancodes. > > Saw the discussion on irc. Feel your pain big-time on the X server > limitation on keycodes. Its put a big damper on efforts to add native > support to mythtv. Peter Hutterer's libXi2 cookbook tutorials talk a > good game about how libXi2 supports 32-bit keycodes, but neglects to > mention that the X server still gobbles up anything above 248 or 255 > or whatever it is, and remedying that is no small task. :( > > I think for mythtv, we're going to end up having a daemon process with > elevated privs that reads directly from input devices to get around > this annoyance, until such time as the annoyance is gone. Btw, indeed Xi2 still doesn't pass > 248 keycodes, just tested that with -git versions of X stack from about 2 months ago. However this can be fixed relatively easily. Maybe even I could do that. The big problem is however about ability to map extended keycodes to actions, thing that should be provided by XKB2, which we will see probably when DNF is released on Phantom console... Also this will need lots of changes in toolkits. Thats the problem I don't have resources to fix. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Thu, 2010-09-09 at 22:01 -0400, Jarod Wilson wrote:
> On Thu, Sep 09, 2010 at 12:34:27AM -0400, Jarod Wilson wrote:
> ...
> > >> For now, I've applied patches 3, 4 and 5, as it is nice to have Jarod's
> > >> review also.
> > >
> > > I've finally got them all applied atop current media_tree staging/v2.6.37,
> > > though none of the streamzap bits in patch 7 are applicable any longer.
> > > Will try to get through looking and commenting (and testing) of the rest
> > > of them tonight.
> >
> > Also had to make a minor addition to the rc5-sz decoder (same change
> > as in the other decoders). Almost have all the requisite test kernels
> > for David's, Maxim's and Dmitry's patchsets built and installed, wish
> > my laptop was faster... Probably would have been faster to use a lab
> > box and copy data over. Oh well. So functional testing to hopefully
> > commence tomorrow morning.
>
> Wuff. None of the three builds is at all stable on my laptop, but I can't
> actually point the finger at any of the three patchsets, since I'm getting
> spontaneous lockups doing nothing at all before even plugging in a
> receiver. I did however get occasional periods of a non-panicking (not
> starting X seems to help a lot). Initial results:
>
Btw, my printk blackbox patch could help you a lot.
I can't count how many times it helped me.
I just enable softlockup, hardlockup, and nmi watchdog, and let system
panic on oopses, and reboot. Or if you have hardware reboot button, you
can just use it. The point is that most BIOSES don't clear the ram, and
I take advantage of that.
Recently in an attempt to make it reserve only small portion of memory
(before I would use mem=) I also made this work out of box.
After a reboot, to get crash dmesg, just do
sudo cat /sys/kernel/debug/printk/crash_dmesg | strings
Note that kernel contains now a ramoops module that does similar things.
It doesn't reserve the memory automatically, and (this is the reason I
still don't use it) is only called by kernel to save oopses/panicks.
It should be enough though too, but my patch actually places the printk
buffer itself in the fixed area in the ram.
Best regards,
Maxim Levitsky
commit 8f1c423046c22dad6aaeca04bfcb0ab301843c36
Author: Maxim Levitsky
Date: Sat Jul 31 13:43:03 2010 +0300
printk: Allow to fix the physical address of printk buffer
Allows to put printk buffer at fixed location of ram (default 128M).
If debugfs is enabled, log of last boot is copied into
system ram, and can be accessed via debugfs, for example
cat /sys/kernel/debug/printk/crash_dmesg
Signed-off-by: Maxim Levitsky
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index ef292c7..a6eaf40 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -46,6 +46,7 @@ extern unsigned long saved_video_mode;
extern void reserve_standard_io_resources(void);
extern void i386_reserve_resources(void);
extern void setup_default_timer_irq(void);
+extern void early_reserve_printk_buffer(void);
#ifdef CONFIG_X86_MRST
extern void x86_mrst_early_setup(void);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index c3a4fbb..6fbf2a0 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -843,6 +843,7 @@ void __init setup_arch(char **cmdline_p)
/* after early param, so could get panic from serial */
reserve_early_setup_data();
+ early_reserve_printk_buffer();
if (acpi_mps_check()) {
#ifdef CONFIG_X86_LOCAL_APIC
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 3ba6e06..8854a91 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -106,7 +106,6 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
if (is_ram && pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn)))
return NULL;
- WARN_ON_ONCE(is_ram);
}
/*
diff --git a/kernel/printk.c b/kernel/printk.c
index 8fe465a..a6fff63 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -41,6 +41,7 @@
#include
#include
+#include
/*
* for_each_console() allows you to iterate on each console
@@ -167,6 +168,7 @@ void log_buf_kexec_setup(void)
}
#endif
+#ifndef CONFIG_HWMEM_PRINTK
static int __init log_buf_len_setup(char *str)
{
unsigned size = memparse(str, &str);
@@ -207,6 +209,93 @@ out:
}
__setup("log_buf_len=", log_buf_len_setup);
+#endif
+
+#ifdef CONFIG_HWMEM_PRINTK
+
+char *old_log_buf;
+struct debugfs_blob_wrapper crash_dmesg_wrapper;
+static unsigned int printk_phys_address = CONFIG_HWMEM_PRINTK_DEFAULT_ADDRESS;
+
+
+static int __init printk_address_setup(char *p)
+{
+ char *tmp;
+
+ if (!strncmp(p, "off", 3))
+ printk_phys_address = 0;
+ else
+ printk_phys_address = memparse(p, &tmp);
+ return 0;
+}
+early_param("printk_address", printk_address_setup);
+
+
+void early_reserve_printk_buffer(void)
+{
+ if (printk_phys_address)
+ reserve_early(printk_phys_address,
+ printk_phys_address + __LOG_BUF_LEN, "printk buffer"
Re: [PATCH 5/8] IR: extend MCE keymap.
On Fri, September 10, 2010 03:37, Jarod Wilson wrote: > I think for mythtv, we're going to end up having a daemon process with > elevated privs that reads directly from input devices to get around > this annoyance, until such time as the annoyance is gone. A similar approach could work for XBMC since it already has input plugins (e.g. for using a Nintendo Wii controller, etc). -- David Härdeman -- 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 v1 0/7] Videobuf2 framework
On Fri, Sep 10, 2010 at 4:22 AM, Hans Verkuil wrote: > It's been a long standing wish to convert the ivtv and cx18 drivers to > videobuf, > but it's always been too complex. With a new vb2 implementation it may become > actually possible. FYI: KernelLabs has done a port of cx18 to videobuf. We just haven't submitted it upstream yet. I'm just mentioning this so nobody else feels the urge to take a crack at it. 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
[GIT FIXES FOR 2.6.36] mem2mem_testdev fixes
Hi Mauro, please pull the below fixes for 2.6.36: The following changes since commit 7e0e8c4f78e93136a2fb44cf46366e868fb75a10: v4l: radio: si470x: fix unneeded free_irq() call (2010-09-06 15:24:33 +0900) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung v4l/fixes_for_v2.6.36 Pawel Osciak (2): v4l: mem2mem_testdev: fix errorenous comparison v4l: mem2mem_testdev: add missing release for video_device drivers/media/video/mem2mem_testdev.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) -- Best regards, Pawel Osciak Linux Platform Group Samsung Poland R&D 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: [PATCH/RFC v1 0/7] Videobuf2 framework
On Friday, September 10, 2010 09:38:44 Marek Szyprowski wrote: > Hello, > > On 2010-09-10 13:27, Mauro Carvalho Chehab wrote: > > >>> 1) it lacks implementation of read() method. This means that vivi driver > >>> has a regression, as it currently supports it. > >> > >> Yes, read() is not yet implemented. I guess it is not a feature that would > >> be deprecated, right? > > > > Yes, there are no plans to deprecate it. Also, some devices like cx88 and > > bttv > > allows receiving simultaneous streams, one via mmap, and another via read(). > > This is used by some applications to allow recording video via > > ffmpeg/mencoder > > using read(), while the main application is displaying video using mmap. > > Well, in my opinion such devices should provide two separate /dev/videoX > nodes rather than hacking with mmap and read access types. 1) It is in use so you can't just drop it. 2) The read() API is actually very useful for video devices that deal with compressed video streams. E.g. you can do things like 'cat /dev/video0 >foo.mpg' It's been a long standing wish to convert the ivtv and cx18 drivers to videobuf, but it's always been too complex. With a new vb2 implementation it may become actually possible. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Fri, September 10, 2010 04:01, Jarod Wilson wrote: > Wuff. None of the three builds is at all stable on my laptop, but I can't > actually point the finger at any of the three patchsets, since I'm getting > spontaneous lockups doing nothing at all before even plugging in a > receiver. I did however get occasional periods of a non-panicking (not > starting X seems to help a lot). Initial results: If you get lockups without even plugging in a receiver, does that mean that the rc-core driver hasn't even been loaded at that point? -- David Härdeman -- 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 v1 0/7] Videobuf2 framework
Hello, On 2010-09-10 13:27, Mauro Carvalho Chehab wrote: 1) it lacks implementation of read() method. This means that vivi driver has a regression, as it currently supports it. Yes, read() is not yet implemented. I guess it is not a feature that would be deprecated, right? Yes, there are no plans to deprecate it. Also, some devices like cx88 and bttv allows receiving simultaneous streams, one via mmap, and another via read(). This is used by some applications to allow recording video via ffmpeg/mencoder using read(), while the main application is displaying video using mmap. Well, in my opinion such devices should provide two separate /dev/videoX nodes rather than hacking with mmap and read access types. Best regards -- Marek Szyprowski Samsung Poland R&D 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: [PATCH] Illuminators and status LED controls
> "Andy" == Andy Walls writes: Hi, Andy> Given choices I made when I patched up gspca/cpia1.c for my Andy> prototype LED API usage, I got these associations Andy> By exposed LED name: Andy> /sys/class/leds/video0:white:illuminator0 Indeed. But didn't we just decide that illuminators were an integral part of the video handling (similar to gain control), and only use the LED API for status LEDs that don't directly interfere with the video data? Andy> The LED API has some shortcomings/annoyances: Andy> - The method a driver provides to set the LED brightness cannot sleep, Andy> so a workqueue is needed to simply turn a hardware light on and off for Andy> USB devices. Andy> - The Documentation is not very good for end-users or kernel developers Andy> on using the LED API. No? I agree that the documentation is pretty minimalistic, but ok - It's not that complicated. Andy> - For an LED trigger not to override a user's desire to inhibit an LED, Andy> the user needs to know to cancel all the triggers on an LED before Andy> setting the LEDs brightness to 0. Only a single trigger can be active at a time for a given LED. Andy> Again, that happens to be the only real compelling use case I see for Andy> using the LED API. However, I doubt many users will try to take Andy> advantage of it, and I suspect even less will succeed in getting it Andy> configured right. Good documentation could go a long way in correcting Andy> that. That and using the LED for something else (perhaps with another trigger like I eplained earlier with wlan/hdd activity). Andy> If a user configures multiple LED triggers on an LED, those triggers Andy> will compete with each other. The net result is the most recent event Andy> from the driver, any LED triggers wins, or user manipulation of sysfs Andy> brightness. Only a single trigger can be active at a time for a given LED. Andy> With indicators that's annoying, but not a failure. With illuminators, Andy> that is a failure. Again, I don't think we should use the LED API for something as integral to the video signal as illuminators. -- Bye, Peter Korsgaard -- 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
