libv4l-0.6.2-test problem with compiling on 32 bit
Good morning, I am using arch linux on 64 bit architecture, this version v4l helped me to rotate view from my webcam, but only in 64 bit apps, like mplayer, I have a problem with compiling it to 32 bits (for skype), I have 32 bit libs, but they are in /opt/lib32/usr/lib directory and during the compiling i am receiving an error: [libv4l-0.6.2-test]$ make PREFIX=/usr CFLAGS=-m32 LDFLAGS=-m32 LIBDIR=/opt/lib32/usr ... /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux- gnu/4.4.2/../../../librt.so when searching for -lrt /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux- gnu/4.4.2/../../../librt.a when searching for -lrt /usr/bin/ld: skipping incompatible /usr/lib/librt.so when searching for -lrt /usr/bin/ld: skipping incompatible /usr/lib/librt.a when searching for -lrt /usr/bin/ld: cannot find -lrt collect2: ld returned 1 exit status make[1]: *** [libv4lconvert.so] Error 1 In /opt/lib32/usr/lib, there are files librt.so and librt.a, but ld doesn't seem to find them. $ cat /etc/ld.so.conf # # /etc/ld.so.conf # # End of file /usr/lib/libfakeroot /opt/lib32/usr/lib /opt/lib32/lib I would be grateful if You could help me with this problem. Best regards, Mateusz Szymański -- 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] em28xx: fix for Dikom DK300 hybrid USB tuner (aka Kworld VS-DVB-T 323UR )
This patch fix the Dikom DK300 hybrid usb card which is recognized as a
Kworld VS-DVB-T 323UR (card=54).
The patch adds digital tv and solves analogue tv audio bad quality issue.
Moreover it removes the composite and s-video analogue inputs which are
not present on the board.
Not tested: remote controller
To be done: I attach the usbsnoop obtained some month ago using windows xp.
It seems that with the proposed patch the digital demodulator remains
activated if the tuner is switched from digital to analogue mode.
Workaorund is to unplug and replug the device when switching from
digital to analogue.
If someone can explain how to verify the gpio settings using the
usbsnoop, the above issue perhaps can be resolved.
Signed-off-by: Andrea Amorosi
diff -r aba823ecaea6 linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Thu Nov 12
12:21:05 2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Sun Nov 22
11:50:29 2009 +0100
@@ -1422,19 +1422,25 @@
.tuner_type = TUNER_XC2028,
.tuner_gpio = default_tuner_gpio,
.decoder = EM28XX_TVP5150,
+.mts_firmware = 1,
+.has_dvb = 1,
+.dvb_gpio = kworld_330u_digital,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = TVP5150_COMPOSITE0,
.amux = EM28XX_AMUX_VIDEO,
- }, {
+ .gpio = default_analog,
+ },/* {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = TVP5150_COMPOSITE1,
.amux = EM28XX_AMUX_LINE_IN,
+ .gpio = kworld_330u_analog,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = TVP5150_SVIDEO,
.amux = EM28XX_AMUX_LINE_IN,
- } },
+ .gpio = kworld_330u_analog,
+ } */},
},
[EM2882_BOARD_TERRATEC_HYBRID_XS] = {
.name = "Terratec Hybrid XS (em2882)",
@@ -2143,6 +2149,7 @@
ctl->demod = XC3028_FE_DEFAULT;
break;
case EM2883_BOARD_KWORLD_HYBRID_330U:
+ case EM2882_BOARD_KWORLD_VS_DVBT:
ctl->demod = XC3028_FE_CHINA;
ctl->fname = XC2028_DEFAULT_FIRMWARE;
break;
diff -r aba823ecaea6 linux/drivers/media/video/em28xx/em28xx-dvb.c
--- a/linux/drivers/media/video/em28xx/em28xx-dvb.c Thu Nov 12 12:21:05
2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-dvb.c Sun Nov 22 11:50:29
2009 +0100
@@ -504,6 +504,7 @@
break;
case EM2880_BOARD_TERRATEC_HYBRID_XS:
case EM2881_BOARD_PINNACLE_HYBRID_PRO:
+ case EM2882_BOARD_KWORLD_VS_DVBT:
dvb->frontend = dvb_attach(zl10353_attach,
&em28xx_zl10353_xc3028_no_i2c_gate,
&dev->i2c_adap);
parsed_UsbSnoop.log.tar.gz
Description: application/gzip
[PATCH] gspca sunplus: propagate error for higher level
From: Márton Németh
The function usb_control_msg() can fail any time. Propagate the error to
higher level software. Do not continue sending URBs after the first error.
The change was tested with Trust 610 LCD pow...@m Zoom in webcam mode
(USB ID 06d6:0031).
Signed-off-by: Márton Németh
---
diff -r bc16afd1e7a4 linux/drivers/media/video/gspca/sunplus.c
--- a/linux/drivers/media/video/gspca/sunplus.c Sat Nov 21 12:01:36 2009 +0100
+++ b/linux/drivers/media/video/gspca/sunplus.c Sun Nov 22 14:28:16 2009 +0100
@@ -486,18 +486,19 @@
};
/* read bytes to gspca_dev->usb_buf */
-static void reg_r(struct gspca_dev *gspca_dev,
+static int reg_r(struct gspca_dev *gspca_dev,
u8 req,
u16 index,
u16 len)
{
+ int ret;
#ifdef GSPCA_DEBUG
if (len > USB_BUF_SZ) {
err("reg_r: buffer overflow");
- return;
+ return -EINVAL;
}
#endif
- usb_control_msg(gspca_dev->dev,
+ ret = usb_control_msg(gspca_dev->dev,
usb_rcvctrlpipe(gspca_dev->dev, 0),
req,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
@@ -505,23 +506,35 @@
index,
len ? gspca_dev->usb_buf : NULL, len,
500);
+ if (ret < 0)
+ err("reg_r: failed to read "
+ "req=0x%X, index=0x%X, len=%u, error=%i\n",
+ req, index, len, ret);
+ return ret;
}
/* write one byte */
-static void reg_w_1(struct gspca_dev *gspca_dev,
+static int reg_w_1(struct gspca_dev *gspca_dev,
u8 req,
u16 value,
u16 index,
u16 byte)
{
+ int ret;
+
gspca_dev->usb_buf[0] = byte;
- usb_control_msg(gspca_dev->dev,
+ ret = usb_control_msg(gspca_dev->dev,
usb_sndctrlpipe(gspca_dev->dev, 0),
req,
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
value, index,
gspca_dev->usb_buf, 1,
500);
+ if (ret < 0)
+ err("reg_w_1: failed to write "
+ "req=0x%X, value=0x%X, index=0x%X, byte=0x%X, error: %i\n",
+ req, value, index, byte, ret);
+ return ret;
}
/* write req / index / value */
@@ -580,18 +593,18 @@
index,
gspca_dev->usb_buf, length,
500);
- if (ret < 0) {
+ if (ret < 0)
PDEBUG(D_ERR, "reg_read err %d", ret);
- return -1;
- }
- return (gspca_dev->usb_buf[1] << 8) + gspca_dev->usb_buf[0];
+ else
+ ret = (gspca_dev->usb_buf[1] << 8) + gspca_dev->usb_buf[0];
+ return ret;
}
static int write_vector(struct gspca_dev *gspca_dev,
const struct cmd *data, int ncmds)
{
struct usb_device *dev = gspca_dev->dev;
- int ret;
+ int ret = 0;
while (--ncmds >= 0) {
ret = reg_w_riv(dev, data->req, data->idx, data->val);
@@ -599,11 +612,11 @@
PDEBUG(D_ERR,
"Register write failed for 0x%02x, 0x%04x, 0x%04x",
data->req, data->val, data->idx);
- return ret;
+ break;
}
data++;
}
- return 0;
+ return ret;
}
static int spca50x_setup_qtable(struct gspca_dev *gspca_dev,
@@ -628,42 +641,57 @@
return 0;
}
-static void spca504_acknowledged_command(struct gspca_dev *gspca_dev,
+static int spca504_acknowledged_command(struct gspca_dev *gspca_dev,
u8 req, u16 idx, u16 val)
{
struct usb_device *dev = gspca_dev->dev;
int notdone;
+ int ret;
- reg_w_riv(dev, req, idx, val);
- notdone = reg_r_12(gspca_dev, 0x01, 0x0001, 1);
- reg_w_riv(dev, req, idx, val);
+ ret = reg_w_riv(dev, req, idx, val);
+ if (0 <= ret) {
+ ret = reg_r_12(gspca_dev, 0x01, 0x0001, 1);
+ notdone = ret;
+ }
+ if (0 <= ret)
+ ret = reg_w_riv(dev, req, idx, val);
- PDEBUG(D_FRAM, "before wait 0x%04x", notdone);
+ if (0 <= ret)
+ PDEBUG(D_FRAM, "before wait 0x%04x", notdone);
- msleep(200);
- notdone = reg_r_12(gspca_dev, 0x01, 0x0001, 1);
- PDEBUG(D_FRAM, "after wait 0x%04x", notdone);
+ if (0 <= ret) {
+ msleep(200);
+ ret = reg_r_12(gspca_dev, 0x01, 0x0001, 1);
+ notdone = ret;
+ PDEBUG(D_FRAM, "after wait 0x%04x", notdone);
+ }
+ return ret;
}
-static void spca504A_acknowledged_command(struct gspca_dev *gspca_dev,
+static int spca504A_acknowledged_command(struct gspca
Re: libv4l-0.6.2-test problem with compiling on 32 bit
Hi, On 11/22/2009 12:02 PM, Mateusz Szymański wrote: Good morning, I am using arch linux on 64 bit architecture, this version v4l helped me to rotate view from my webcam, but only in 64 bit apps, like mplayer, I have a problem with compiling it to 32 bits (for skype), I have 32 bit libs, but they are in /opt/lib32/usr/lib directory and during the compiling i am receiving an error: [libv4l-0.6.2-test]$ make PREFIX=/usr CFLAGS=-m32 LDFLAGS=-m32 LIBDIR=/opt/lib32/usr ... /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux- gnu/4.4.2/../../../librt.so when searching for -lrt /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux- gnu/4.4.2/../../../librt.a when searching for -lrt /usr/bin/ld: skipping incompatible /usr/lib/librt.so when searching for -lrt /usr/bin/ld: skipping incompatible /usr/lib/librt.a when searching for -lrt /usr/bin/ld: cannot find -lrt collect2: ld returned 1 exit status make[1]: *** [libv4lconvert.so] Error 1 In /opt/lib32/usr/lib, there are files librt.so and librt.a, but ld doesn't seem to find them. $ cat /etc/ld.so.conf # # /etc/ld.so.conf # # End of file /usr/lib/libfakeroot /opt/lib32/usr/lib /opt/lib32/lib I would be grateful if You could help me with this problem. This is a problem specific to the way things are set up in your distro, please ask for help in one of the fora / mailinglists of your distro. Regards, hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC, PATCH 1/2] gspca: add input support for interrupt endpoints
Németh Márton wrote: > Jean-Francois Moine wrote: >> On Fri, 20 Nov 2009 08:14:10 +0100 >> Németh Márton wrote: >>> Unfortunately I still get the following error when I start streaming, >>> stop streaming or unplug the device: >>> >>> [ 6876.780726] uhci_hcd :00:10.1: dma_pool_free buffer-32, >>> de0ad168/1e0ad168 (bad dma) >> As there is no 'break' in gspca_input_create_urb(), many URBs are >> created. > > I added 'break' in the loop, which makes no real difference because > my device have only one interrupt in endpoint. The error message is > printed when the usb_buffer_free() is called in gspca_input_destroy_urb(): > > [ 6362.113264] gspca_input: Freeing buffer > [ 6362.113284] uhci_hcd :00:1d.1: dma_pool_free buffer-32, > f5ada948/35ada948 (bad dma) > [ 6362.113296] gspca_input: Freeing URB The problem was that the URB buffer was allocated with kmalloc() and was freed with usb_buffer_free(). The right pair is usb_buffer_alloc() and usb_buffer_free(). Regards, Márton Németh -- 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] gspca: add input support for interrupt endpoints
From: Márton Németh
Add helper functions for interrupt endpoint based input handling.
Signed-off-by: Márton Németh
---
diff -r bc16afd1e7a4 linux/drivers/media/video/gspca/Makefile
--- a/linux/drivers/media/video/gspca/Makefile Sat Nov 21 12:01:36 2009 +0100
+++ b/linux/drivers/media/video/gspca/Makefile Sun Nov 22 16:40:34 2009 +0100
@@ -30,6 +30,9 @@
obj-$(CONFIG_USB_GSPCA_ZC3XX)+= gspca_zc3xx.o
gspca_main-objs := gspca.o
+ifeq ($(CONFIG_INPUT),y)
+gspca_main-objs += input.o
+endif
gspca_conex-objs:= conex.o
gspca_etoms-objs:= etoms.o
gspca_finepix-objs := finepix.o
diff -r bc16afd1e7a4 linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Sat Nov 21 12:01:36 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c Sun Nov 22 16:40:34 2009 +0100
@@ -40,6 +40,9 @@
#include
#include "gspca.h"
+
+#include
+#include "input.h"
/* global values */
#define DEF_NURBS 3/* default number of URBs */
@@ -499,11 +502,13 @@
i, ep->desc.bEndpointAddress);
gspca_dev->alt = i; /* memorize the current alt setting */
if (gspca_dev->nbalt > 1) {
+ gspca_input_destroy_urb(gspca_dev);
ret = usb_set_interface(gspca_dev->dev, gspca_dev->iface, i);
if (ret < 0) {
err("set alt %d err %d", i, ret);
- return NULL;
+ ep = NULL;
}
+ gspca_input_create_urb(gspca_dev);
}
return ep;
}
@@ -707,7 +712,9 @@
if (gspca_dev->sd_desc->stopN)
gspca_dev->sd_desc->stopN(gspca_dev);
destroy_urbs(gspca_dev);
+ gspca_input_destroy_urb(gspca_dev);
gspca_set_alt0(gspca_dev);
+ gspca_input_create_urb(gspca_dev);
}
/* always call stop0 to free the subdriver's resources */
@@ -2088,6 +2095,11 @@
usb_set_intfdata(intf, gspca_dev);
PDEBUG(D_PROBE, "/dev/video%d created", gspca_dev->vdev.num);
+
+ ret = gspca_input_connect(gspca_dev);
+ if (0 <= ret)
+ ret = gspca_input_create_urb(gspca_dev);
+
return 0;
out:
kfree(gspca_dev->usb_buf);
@@ -2105,6 +2117,7 @@
void gspca_disconnect(struct usb_interface *intf)
{
struct gspca_dev *gspca_dev = usb_get_intfdata(intf);
+ struct input_dev *input_dev;
PDEBUG(D_PROBE, "/dev/video%d disconnect", gspca_dev->vdev.num);
mutex_lock(&gspca_dev->usb_lock);
@@ -2113,6 +2126,13 @@
if (gspca_dev->streaming) {
destroy_urbs(gspca_dev);
wake_up_interruptible(&gspca_dev->wq);
+ }
+
+ gspca_input_destroy_urb(gspca_dev);
+ input_dev = gspca_dev->input_dev;
+ if (input_dev) {
+ gspca_dev->input_dev = NULL;
+ input_unregister_device(input_dev);
}
/* the device is freed at exit of this function */
@@ -2140,6 +2160,7 @@
if (gspca_dev->sd_desc->stopN)
gspca_dev->sd_desc->stopN(gspca_dev);
destroy_urbs(gspca_dev);
+ gspca_input_destroy_urb(gspca_dev);
gspca_set_alt0(gspca_dev);
if (gspca_dev->sd_desc->stop0)
gspca_dev->sd_desc->stop0(gspca_dev);
@@ -2153,6 +2174,7 @@
gspca_dev->frozen = 0;
gspca_dev->sd_desc->init(gspca_dev);
+ gspca_input_create_urb(gspca_dev);
if (gspca_dev->streaming)
return gspca_init_transfer(gspca_dev);
return 0;
diff -r bc16afd1e7a4 linux/drivers/media/video/gspca/gspca.h
--- a/linux/drivers/media/video/gspca/gspca.h Sat Nov 21 12:01:36 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.h Sun Nov 22 16:40:34 2009 +0100
@@ -81,6 +81,9 @@
typedef void (*cam_pkt_op) (struct gspca_dev *gspca_dev,
u8 *data,
int len);
+typedef int (*cam_int_pkt_op) (struct gspca_dev *gspca_dev,
+ u8 *data,
+ int len);
struct ctrl {
struct v4l2_queryctrl qctrl;
@@ -116,6 +119,9 @@
cam_reg_op get_register;
#endif
cam_ident_op get_chip_ident;
+#ifdef CONFIG_INPUT
+ cam_int_pkt_op int_pkt_scan;
+#endif
};
/* packet types when moving from iso buf to frame buf */
@@ -138,6 +144,10 @@
struct module *module; /* subdriver handling the device */
struct usb_device *dev;
struct file *capt_file; /* file doing video capture */
+#ifdef CONFIG_INPUT
+ struct input_dev *input_dev;
+ char phys[64]; /* physical device path */
+#endif
struct cam cam; /* device information */
const struct sd_desc *sd_desc; /* subdriver description */
@@ -147,6 +157,9 @@
#define USB_BUF_SZ 64
__u8 *usb_buf; /* buffer for USB exc
[PATCH 2/2] gspca pac7302: add support for camera button
From: Márton Németh
Add support for snapshot button found on Labtec Webcam 2200
(USB ID 093a:2626).
Signed-off-by: Márton Németh
---
diff -r bc16afd1e7a4 linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Sat Nov 21 12:01:36 2009 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Sun Nov 22 16:40:34 2009 +0100
@@ -68,8 +68,10 @@
#define MODULE_NAME "pac7302"
+#include
#include
#include "gspca.h"
+#include "input.h"
MODULE_AUTHOR("Thomas Kaiser tho...@kaiser-linux.li");
MODULE_DESCRIPTION("Pixart PAC7302");
@@ -1220,6 +1222,37 @@
}
#endif
+#ifdef CONFIG_INPUT
+static int sd_int_pkt_scan(struct gspca_dev *gspca_dev,
+ u8 *data, /* interrupt packet data */
+ int len)/* interrput packet length */
+{
+ int ret = -EINVAL;
+ u8 data0, data1;
+
+ if (len == 2) {
+ data0 = data[0];
+ data1 = data[1];
+ if ((data0 == 0x00 && data1 == 0x11) ||
+ (data0 == 0x22 && data1 == 0x33) ||
+ (data0 == 0x44 && data1 == 0x55) ||
+ (data0 == 0x66 && data1 == 0x77) ||
+ (data0 == 0x88 && data1 == 0x99) ||
+ (data0 == 0xaa && data1 == 0xbb) ||
+ (data0 == 0xcc && data1 == 0xdd) ||
+ (data0 == 0xee && data1 == 0xff)) {
+ input_report_key(gspca_dev->input_dev, KEY_CAMERA, 1);
+ input_sync(gspca_dev->input_dev);
+ input_report_key(gspca_dev->input_dev, KEY_CAMERA, 0);
+ input_sync(gspca_dev->input_dev);
+ ret = 0;
+ }
+ }
+
+ return ret;
+}
+#endif
+
/* sub-driver description for pac7302 */
static struct sd_desc sd_desc = {
.name = MODULE_NAME,
@@ -1235,6 +1268,9 @@
#ifdef CONFIG_VIDEO_ADV_DEBUG
.set_register = sd_dbg_s_register,
.get_chip_ident = sd_chip_ident,
+#endif
+#ifdef CONFIG_INPUT
+ .int_pkt_scan = sd_int_pkt_scan,
#endif
};
--
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: IR Receiver on an Tevii S470
Hi Andy, Andy Walls wrote: Thank you. I will probably need you for testing when ready. I was planning to do step 1 above for HVR-1800 IR anyway. I will estimate that I may have something ready by about Christmas (25 December 2009), unless work becomes very busy. thanks a lot for your answer. I uploaded two pictures I did from the card, you can find it here: http://fechner.net/tevii-s470/ It is a CX23885. The driver I use is the ds3000. lspci says: 02:00.0 Multimedia video controller: Conexant Device 8852 (rev 02) Subsystem: Device d470:9022 Flags: bus master, fast devsel, latency 0, IRQ 19 Memory at fac0 (64-bit, non-prefetchable) [size=2M] Capabilities: [40] Express Endpoint, MSI 00 Capabilities: [80] Power Management version 2 Capabilities: [90] Vital Product Data Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable- Capabilities: [100] Advanced Error Reporting UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSVoil- UEMsk:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil- UESvrt:DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSVoil- CESta:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CESta:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap:First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn- Capabilities: [200] Virtual Channel Kernel driver in use: cx23885 Kernel modules: cx23885 lsmod says: Module Size Used by lirc_serial10740 1 snd_mixer_oss 12428 0 lirc_dev9512 3 lirc_serial snd_hda_codec_nvhdmi 3976 1 ds3000 12820 1 snd_hda_codec_realtek 184292 1 cx23885 105116 9 cx2341x10784 1 cx23885 v4l2_common15428 2 cx23885,cx2341x nvidia 8860344 44 videodev 34080 2 cx23885,v4l2_common v4l1_compat11252 1 videodev videobuf_dma_sg11176 1 cx23885 videobuf_dvb6308 1 cx23885 dvb_core 78492 2 cx23885,videobuf_dvb videobuf_core 16280 3 cx23885,videobuf_dma_sg,videobuf_dvb snd_hda_intel 22004 1 ir_common 46132 1 cx23885 snd_hda_codec 55908 3 snd_hda_codec_nvhdmi,snd_hda_codec_realtek,snd_hda_intel btcx_risc 4244 1 cx23885 tveeprom 10652 1 cx23885 snd_pcm63812 3 snd_hda_intel,snd_hda_codec snd_timer 17584 1 snd_pcm ehci_hcd 29628 0 ohci_hcd 19664 0 snd49728 7 snd_mixer_oss,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer usbcore 117380 2 ehci_hcd,ohci_hcd i2c_nforce2 6092 0 serio_raw 4708 0 soundcore 6276 1 snd i2c_core 19848 7 ds3000,cx23885,v4l2_common,nvidia,videodev,tveeprom,i2c_nforce2 snd_page_alloc 7952 2 snd_hda_intel,snd_pcm evdev 8148 4 I can test any patch when you have one ready, currently I'm using lirc together with a TechnoTrend RemoteControl. Thanks a lot and have a nice week Best regards, Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Nov 22 19:00:05 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13372:8bff7e6c44d4 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: WARNINGS linux-2.6.24.7-armv5: WARNINGS linux-2.6.25.11-armv5: WARNINGS linux-2.6.26-armv5: WARNINGS linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: WARNINGS linux-2.6.30-armv5: WARNINGS linux-2.6.31-armv5: WARNINGS linux-2.6.32-rc8-armv5: OK linux-2.6.32-rc8-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-armv5-ixp: WARNINGS linux-2.6.32-rc8-armv5-ixp: OK linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc8-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc8-i686: WARNINGS linux-2.6.23.12-m32r: WARNINGS linux-2.6.24.7-m32r: WARNINGS linux-2.6.25.11-m32r: WARNINGS linux-2.6.26-m32r: WARNINGS linux-2.6.27-m32r: WARNINGS linux-2.6.28-m32r: WARNINGS linux-2.6.29.1-m32r: WARNINGS linux-2.6.30-m32r: WARNINGS linux-2.6.31-m32r: WARNINGS linux-2.6.32-rc8-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: WARNINGS linux-2.6.32-rc8-mips: OK linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: WARNINGS linux-2.6.32-rc8-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc8-x86_64: WARNINGS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc8): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: IR Receiver on an Tevii S470
On Sun, 2009-11-22 at 19:08 +0100, Matthias Fechner wrote: > Hi Andy, > > Andy Walls wrote: > > Thank you. I will probably need you for testing when ready. > > > > > > I was planning to do step 1 above for HVR-1800 IR anyway. > > > > I will estimate that I may have something ready by about Christmas (25 > > December 2009), unless work becomes very busy. > > > > thanks a lot for your answer. > I uploaded two pictures I did from the card, you can find it here: > http://fechner.net/tevii-s470/ > > It is a CX23885. > The driver I use is the ds3000. > lspci says: [snip] Matthias, Thanks for the pictures. OK so of the two other interesting chips on the S470: U4 is an I2C connected EEPROM - we don't care about that for IR. U10 appears to perhaps be a Silicon Labs C8051F300 microcontroller or similar: http://www.silabs.com/products/mcu/smallmcu/Pages/C8051F30x.aspx Since the 'F300 has an A/D convertor and has an SMBus interface (compatable with the I2C bus), I suspect this chip could be the IR controller on the TeVii S470. Could you as root: # modprobe cx23885 # modprobe i2c-dev # i2c-detect -l (to list all the i2c buses, including cx23885 mastered i2c buses) # i2c-detect -y N (to show the addresses in use on bus # N: only query the cx23885 buses) i2c-detect was in the lm-sensors package last I checked. (Jean can correct me if I'm wrong.) With that information, I should be able to figure out what I2C address that microcontroller is listening to. Then we can work out how to read and decode it's data and add it to ir-kbd-i2c at least. Depending on how your kernel and LIRC versions LIRC might still work with I2C IR chips too. All presupposing of course that that 'F300 chip is for IR... Regards, Andy > I can test any patch when you have one ready, currently I'm using lirc > together with a TechnoTrend RemoteControl. > Thanks a lot and have a nice week > > Best regards, > Matthias -- 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: IR Receiver on an Tevii S470
Hi Andy, Andy Walls wrote: # modprobe cx23885 # modprobe i2c-dev # i2c-detect -l (to list all the i2c buses, including cx23885 mastered i2c buses) i2c-0smbus SMBus nForce2 adapter at 4d00 SMBus adapter i2c-1i2c cx23885[0] I2C adapter i2c-2i2c cx23885[0] I2C adapter i2c-3i2c cx23885[0] I2C adapter i2c-4i2c NVIDIA i2c adapter I2C adapter i2c-5i2c NVIDIA i2c adapter I2C adapter i2c-6i2c NVIDIA i2c adapter I2C adapter # i2c-detect -y N (to show the addresses in use on bus # N: only query the cx23885 buses) vdrhd1 ~ # i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- vdrhd1 ~ # i2cdetect -y 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- vdrhd1 ~ # i2cdetect -y 3 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- 44 -- -- -- -- -- -- -- 4c -- -- -- 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- i2c-detect was in the lm-sensors package last I checked. (Jean can correct me if I'm wrong.) ok, it seems that the name of tool is different here, but I think it has the same output. Then we can work out how to read and decode it's data and add it to ir-kbd-i2c at least. Depending on how your kernel and LIRC versions LIRC might still work with I2C IR chips too. I will do my best to help you here. Bye, Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook -- 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: IR Receiver on an Tevii S470
Hi Andy, On Sun, 22 Nov 2009 15:11:47 -0500, Andy Walls wrote: > On Sun, 2009-11-22 at 19:08 +0100, Matthias Fechner wrote: > > thanks a lot for your answer. > > I uploaded two pictures I did from the card, you can find it here: > > http://fechner.net/tevii-s470/ > > > > It is a CX23885. > > The driver I use is the ds3000. > > lspci says: > [snip] > > Thanks for the pictures. OK so of the two other interesting chips on > the S470: > > U4 is an I2C connected EEPROM - we don't care about that for IR. > > U10 appears to perhaps be a Silicon Labs C8051F300 microcontroller or > similar: > > http://www.silabs.com/products/mcu/smallmcu/Pages/C8051F30x.aspx > > Since the 'F300 has an A/D convertor and has an SMBus interface > (compatable with the I2C bus), I suspect this chip could be the IR > controller on the TeVii S470. > > Could you as root: > > # modprobe cx23885 > # modprobe i2c-dev > # i2c-detect -l > (to list all the i2c buses, including cx23885 mastered i2c buses) > # i2c-detect -y N > (to show the addresses in use on bus # N: only query the cx23885 buses) > > > i2c-detect was in the lm-sensors package last I checked. (Jean can > correct me if I'm wrong.) It is actually named "i2cdetect" (no dash). It used to live in the lm-sensors package (up to 2.10.x) but is now in i2c-tools: http://www.lm-sensors.org/wiki/I2CTools > With that information, I should be able to figure out what I2C address > that microcontroller is listening to. -- 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: IR Receiver on an Tevii S470
On Sun, 22 Nov 2009 21:25:27 +0100, Matthias Fechner wrote: > Hi Andy, > > Andy Walls wrote: > > > > # modprobe cx23885 > > # modprobe i2c-dev > > # i2c-detect -l > > (to list all the i2c buses, including cx23885 mastered i2c buses) > > > i2c-0smbus SMBus nForce2 adapter at 4d00 SMBus adapter > i2c-1i2c cx23885[0] I2C adapter > i2c-2i2c cx23885[0] I2C adapter > i2c-3i2c cx23885[0] I2C adapter > i2c-4i2c NVIDIA i2c adapter I2C adapter > i2c-5i2c NVIDIA i2c adapter I2C adapter > i2c-6i2c NVIDIA i2c adapter I2C adapter > > > # i2c-detect -y N > > (to show the addresses in use on bus # N: only query the cx23885 buses) > > > > > vdrhd1 ~ # i2cdetect -y 1 > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 70: -- -- -- -- -- -- -- -- > vdrhd1 ~ # i2cdetect -y 2 > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f > 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- > 70: -- -- -- -- -- -- -- -- > vdrhd1 ~ # i2cdetect -y 3 > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- > 40: -- -- -- -- 44 -- -- -- -- -- -- -- 4c -- -- -- > 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 70: -- -- -- -- -- -- -- -- The fact that 0x30-0x37 and 0x50-0x5f all reply suggest that the bus driver erroneously returns success to "SMBus receive byte" transactions even when no device acks. This is a bug which should get fixed. If you point me to the I2C adapter driver code, I can take a look. In the meantime, you can try i2cdetect -q to force i2cdetect to use "SMBus quick" commands for all the addresses. Beware though that some chips are known to not like it at all (in particular the infamous AT24RF08... not that I expect to ever see one on a TV adapter but you never know.) At least the above scan has already found 3 chips. -- 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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
Hans Verkuil worte:
> linux-2.6.22.19-armv5: WARNINGS
/marune/build/v4l-dvb-master/v4l/videobuf-core.c: In function
'videobuf_reqbufs':
/marune/build/v4l-dvb-master/v4l/videobuf-core.c:434: warning: format '%d'
expects type 'int', but argument 4 has type 'long unsigned int'
I think this can be solved by explicit casting the result.
---
Subject: [PATCH] explicitly cast page count
From: Márton Németh
Explicitly cast page count in the debug message.
Signed-off-by: Márton Németh
---
diff -r bc16afd1e7a4 linux/drivers/media/video/videobuf-core.c
--- a/linux/drivers/media/video/videobuf-core.c Sat Nov 21 12:01:36 2009 +0100
+++ b/linux/drivers/media/video/videobuf-core.c Sun Nov 22 21:56:20 2009 +0100
@@ -431,8 +431,9 @@
count = VIDEO_MAX_FRAME;
size = 0;
q->ops->buf_setup(q, &count, &size);
- dprintk(1, "reqbufs: bufs=%d, size=0x%x [%d pages total]\n",
- count, size, (count*PAGE_ALIGN(size))>>PAGE_SHIFT);
+ dprintk(1, "reqbufs: bufs=%d, size=0x%x [%u pages total]\n",
+ count, size,
+ (unsigned int)((count*PAGE_ALIGN(size))>>PAGE_SHIFT) );
retval = __videobuf_mmap_setup(q, count, size, req->memory);
if (retval < 0) {
--
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
V4L-DVB modules not loading
Sorry, I don't know who to send this to. Not sure if it is a bug or not. I followed your very helpful tutorial perfectly: http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers but it hasn't quite worked. I've built the module okay. It installed correctly and copied the files into /lib/modules/2.6.31-14-generic/kernel/drivers/media/dvb/dvb-usb. After that I rebooted (since it was easier for me). Then I got to the "If the Modules load correctly" section to find that nothing has worked at all. I've checked my system log and it's recognising the USB device when I enter it but it isn't doing anything with it. The tutorial says you should be able to see the modules in /proc/modules but the modules folder doesn't even exist. The /dev/dvb/ folder has not been created either. I have a EyeTV Diversity and have the antenna plugged in. I will provide as much information as you need. I really want to get this working. :) Thanks ~ Stacey -- 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] smssdio: initialize return value
From: Márton Németh
The return value may be used uninitialized when the size parameter
happens to be 0.
Signed-off-by: Márton Németh
---
diff -r bc16afd1e7a4 linux/drivers/media/dvb/siano/smssdio.c
--- a/linux/drivers/media/dvb/siano/smssdio.c Sat Nov 21 12:01:36 2009 +0100
+++ b/linux/drivers/media/dvb/siano/smssdio.c Sun Nov 22 22:40:31 2009 +0100
@@ -78,7 +78,7 @@
static int smssdio_sendrequest(void *context, void *buffer, size_t size)
{
- int ret;
+ int ret = 0;
struct smssdio_device *smsdev;
smsdev = context;
--
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] dib8000: merge two conditionals
From: Márton Németh Merge two ifs: the condition is the same. The second if uses the ncoeff which is initialized in the first if. Signed-off-by: Márton Németh --- diff -r bc16afd1e7a4 linux/drivers/media/dvb/frontends/dib8000.c --- a/linux/drivers/media/dvb/frontends/dib8000.c Sat Nov 21 12:01:36 2009 +0100 +++ b/linux/drivers/media/dvb/frontends/dib8000.c Sun Nov 22 22:40:31 2009 +0100 @@ -1402,10 +1402,9 @@ } break; } - } - if (state->fe.dtv_property_cache.isdbt_sb_mode == 1) for (i = 0; i < 8; i++) dib8000_write_word(state, 343 + i, ncoeff[i]); + } // P_small_coef_ext_enable=ISDB-Tsb, P_small_narrow_band=ISDB-Tsb, P_small_last_seg=13, P_small_offset_num_car=5 dib8000_write_word(state, 351, -- 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: IR Receiver on an Tevii S470
On 22 ноября 2009 22:11:47 Andy Walls wrote: > On Sun, 2009-11-22 at 19:08 +0100, Matthias Fechner wrote: > > Hi Andy, > > > > Andy Walls wrote: > > > Thank you. I will probably need you for testing when ready. > > > > > > > > > I was planning to do step 1 above for HVR-1800 IR anyway. > > > > > > I will estimate that I may have something ready by about Christmas (25 > > > December 2009), unless work becomes very busy. > > > > thanks a lot for your answer. > > I uploaded two pictures I did from the card, you can find it here: > > http://fechner.net/tevii-s470/ > > > > It is a CX23885. > > The driver I use is the ds3000. > > lspci says: > > [snip] > > Matthias, > > Thanks for the pictures. OK so of the two other interesting chips on > the S470: > > U4 is an I2C connected EEPROM - we don't care about that for IR. > > U10 appears to perhaps be a Silicon Labs C8051F300 microcontroller or > similar: > > http://www.silabs.com/products/mcu/smallmcu/Pages/C8051F30x.aspx > > Since the 'F300 has an A/D convertor and has an SMBus interface > (compatable with the I2C bus), I suspect this chip could be the IR > controller on the TeVii S470. > > Could you as root: > > # modprobe cx23885 > # modprobe i2c-dev > # i2c-detect -l > (to list all the i2c buses, including cx23885 mastered i2c buses) > # i2c-detect -y N > (to show the addresses in use on bus # N: only query the cx23885 buses) > > > i2c-detect was in the lm-sensors package last I checked. (Jean can > correct me if I'm wrong.) > > With that information, I should be able to figure out what I2C address > that microcontroller is listening to. > > Then we can work out how to read and decode it's data and add it to > ir-kbd-i2c at least. Depending on how your kernel and LIRC versions > LIRC might still work with I2C IR chips too. > > > All presupposing of course that that 'F300 chip is for IR... Receiver connected to cx23885 IR_RX(pin 106). It is not difficult to track. F300 is for LNB power control. It connected to cx23885 GPIO pins: GPIO0 - data - P0.3 F300 GPIO1 - reset - P0.2 F300 GPIO2 - clk - P0.1 F300 GPIO3 - busy - P0.0 F300 Interface seems not I2C/SMBUS. Source code from TeVii: http://mercurial.intuxication.org/hg/s2- liplianin/file/d0dfe416e0f6/linux/drivers/media/video/cx23885/tevii_pwr.c BR Igor > > Regards, > Andy > > > I can test any patch when you have one ready, currently I'm using lirc > > together with a TechnoTrend RemoteControl. > > Thanks a lot and have a nice week > > > > Best regards, > > Matthias -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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: IR Receiver on an Tevii S470
On Mon, 2009-11-23 at 00:29 +0200, Igor M. Liplianin wrote:
> On 22 ноября 2009 22:11:47 Andy Walls wrote:
> > On Sun, 2009-11-22 at 19:08 +0100, Matthias Fechner wrote:
> > > Hi Andy,
> > >
> > > Andy Walls wrote:
> > > > Thank you. I will probably need you for testing when ready.
> > > >
> > > >
> > > > I was planning to do step 1 above for HVR-1800 IR anyway.
> > > >
> > > > I will estimate that I may have something ready by about Christmas (25
> > > > December 2009), unless work becomes very busy.
> > >
> > > thanks a lot for your answer.
> > > I uploaded two pictures I did from the card, you can find it here:
> > > http://fechner.net/tevii-s470/
> > >
> > > It is a CX23885.
> > > The driver I use is the ds3000.
> > > lspci says:
> >
> > [snip]
> >
> > Matthias,
> >
> > Thanks for the pictures. OK so of the two other interesting chips on
> > the S470:
> >
> > U4 is an I2C connected EEPROM - we don't care about that for IR.
> >
> > U10 appears to perhaps be a Silicon Labs C8051F300 microcontroller or
> > similar:
> >
> > http://www.silabs.com/products/mcu/smallmcu/Pages/C8051F30x.aspx
> >
> > Since the 'F300 has an A/D convertor and has an SMBus interface
> > (compatable with the I2C bus), I suspect this chip could be the IR
> > controller on the TeVii S470.
> >
> > Could you as root:
> >
> > # modprobe cx23885
> > # modprobe i2c-dev
> > # i2c-detect -l
> > (to list all the i2c buses, including cx23885 mastered i2c buses)
> > # i2c-detect -y N
> > (to show the addresses in use on bus # N: only query the cx23885 buses)
> >
> >
> > i2c-detect was in the lm-sensors package last I checked. (Jean can
> > correct me if I'm wrong.)
> >
> > With that information, I should be able to figure out what I2C address
> > that microcontroller is listening to.
> >
> > Then we can work out how to read and decode it's data and add it to
> > ir-kbd-i2c at least. Depending on how your kernel and LIRC versions
> > LIRC might still work with I2C IR chips too.
> >
> >
> > All presupposing of course that that 'F300 chip is for IR...
> Receiver connected to cx23885 IR_RX(pin 106). It is not difficult to track.
Igor,
Thank you. I did not have a board to trace. I will then stick with my
original plan since the F300 doesn't do the IR.
> F300 is for LNB power control.
> It connected to cx23885 GPIO pins:
> GPIO0 - data - P0.3 F300
> GPIO1 - reset - P0.2 F300
> GPIO2 - clk - P0.1 F300
> GPIO3 - busy - P0.0 F300
>
> Interface seems not I2C/SMBUS.
>
> Source code from TeVii:
> http://mercurial.intuxication.org/hg/s2-
> liplianin/file/d0dfe416e0f6/linux/drivers/media/video/cx23885/tevii_pwr.c
Interesting
static void Delay1mS(void)
{
udelay(800);
}
:D
Regards,
Andy
> BR
> Igor
--
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: IR Receiver on an Tevii S470
On 23 ноября 2009, "Igor M. Liplianin" wrote:
> On Mon, 2009-11-23 at 00:29 +0200, Igor M. Liplianin wrote:
> > On 22 ноября 2009 22:11:47 Andy Walls wrote:
> > > On Sun, 2009-11-22 at 19:08 +0100, Matthias Fechner wrote:
> > > > Hi Andy,
> > > >
> > > > Andy Walls wrote:
> > > > > Thank you. I will probably need you for testing when ready.
> > > > >
> > > > >
> > > > > I was planning to do step 1 above for HVR-1800 IR anyway.
> > > > >
> > > > > I will estimate that I may have something ready by about Christmas
> > > > > (25 December 2009), unless work becomes very busy.
> > > >
> > > > thanks a lot for your answer.
> > > > I uploaded two pictures I did from the card, you can find it here:
> > > > http://fechner.net/tevii-s470/
> > > >
> > > > It is a CX23885.
> > > > The driver I use is the ds3000.
> > > > lspci says:
> > >
> > > [snip]
> > >
> > > Matthias,
> > >
> > > Thanks for the pictures. OK so of the two other interesting chips on
> > > the S470:
> > >
> > > U4 is an I2C connected EEPROM - we don't care about that for IR.
> > >
> > > U10 appears to perhaps be a Silicon Labs C8051F300 microcontroller or
> > > similar:
> > >
> > > http://www.silabs.com/products/mcu/smallmcu/Pages/C8051F30x.aspx
> > >
> > > Since the 'F300 has an A/D convertor and has an SMBus interface
> > > (compatable with the I2C bus), I suspect this chip could be the IR
> > > controller on the TeVii S470.
> > >
> > > Could you as root:
> > >
> > > # modprobe cx23885
> > > # modprobe i2c-dev
> > > # i2c-detect -l
> > > (to list all the i2c buses, including cx23885 mastered i2c buses)
> > > # i2c-detect -y N
> > > (to show the addresses in use on bus # N: only query the cx23885 buses)
> > >
> > >
> > > i2c-detect was in the lm-sensors package last I checked. (Jean can
> > > correct me if I'm wrong.)
> > >
> > > With that information, I should be able to figure out what I2C address
> > > that microcontroller is listening to.
> > >
> > > Then we can work out how to read and decode it's data and add it to
> > > ir-kbd-i2c at least. Depending on how your kernel and LIRC versions
> > > LIRC might still work with I2C IR chips too.
> > >
> > >
> > > All presupposing of course that that 'F300 chip is for IR...
> >
> > Receiver connected to cx23885 IR_RX(pin 106). It is not difficult to
> > track.
>
> Igor,
>
> Thank you. I did not have a board to trace. I will then stick with my
> original plan since the F300 doesn't do the IR.
I have cx23885 based Compro E650F DVB-T card. It shipped with RC6 type remote.
So I can test RC6 too... And I will.
>
> > F300 is for LNB power control.
> > It connected to cx23885 GPIO pins:
> > GPIO0 - data - P0.3 F300
> > GPIO1 - reset - P0.2 F300
> > GPIO2 - clk - P0.1 F300
> > GPIO3 - busy - P0.0 F300
> >
> > Interface seems not I2C/SMBUS.
> >
> > Source code from TeVii:
> > http://mercurial.intuxication.org/hg/s2-
> > liplianin/file/d0dfe416e0f6/linux/drivers/media/video/cx23885/tevii_pwr.c
>
> Interesting
>
>static void Delay1mS(void)
>{
> udelay(800);
>}
>
> :D
Your link to datasheet helps me a lot :)
I will clear all that out and will commit to linuxtv soon.
BR
Igor
>
> Regards,
> Andy
>
> > BR
> > Igor
>
> --
> 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
--
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
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: IR Receiver on an Tevii S470
On Sun, 2009-11-22 at 21:32 +0100, Jean Delvare wrote: > On Sun, 22 Nov 2009 21:25:27 +0100, Matthias Fechner wrote: > > Hi Andy, > > > > Andy Walls wrote: > > > > > > # modprobe cx23885 > > > # modprobe i2c-dev > > > # i2c-detect -l > > > (to list all the i2c buses, including cx23885 mastered i2c buses) > > > > > i2c-0smbus SMBus nForce2 adapter at 4d00 SMBus adapter > > i2c-1i2c cx23885[0] I2C adapter > > i2c-2i2c cx23885[0] I2C adapter > > i2c-3i2c cx23885[0] I2C adapter > > i2c-4i2c NVIDIA i2c adapter I2C adapter > > i2c-5i2c NVIDIA i2c adapter I2C adapter > > i2c-6i2c NVIDIA i2c adapter I2C adapter > > > > > # i2c-detect -y N > > > (to show the addresses in use on bus # N: only query the cx23885 buses) > > > > > > > > vdrhd1 ~ # i2cdetect -y 1 > > 0 1 2 3 4 5 6 7 8 9 a b c d e f > > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- > > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f > > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 70: -- -- -- -- -- -- -- -- > > vdrhd1 ~ # i2cdetect -y 2 > > 0 1 2 3 4 5 6 7 8 9 a b c d e f > > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- > > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f > > 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- > > 70: -- -- -- -- -- -- -- -- > > vdrhd1 ~ # i2cdetect -y 3 > > 0 1 2 3 4 5 6 7 8 9 a b c d e f > > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- > > 40: -- -- -- -- 44 -- -- -- -- -- -- -- 4c -- -- -- > > 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f > > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 70: -- -- -- -- -- -- -- -- > > The fact that 0x30-0x37 and 0x50-0x5f all reply suggest that the bus > driver erroneously returns success to "SMBus receive byte" transactions > even when no device acks. This is a bug which should get fixed. If you > point me to the I2C adapter driver code, I can take a look. Jean, Although Igor's information makes the original need for this moot, here is the i2c adapter driver code: http://linuxtv.org/hg/v4l-dvb/file/8bff7e6c44d4/linux/drivers/media/video/cx23885/cx23885-i2c.c Note the CX2388[578] chips have 3 I2C masters, 2 for external buses, and 1 internal "on silicon" bus which the driver sets up as the 3rd bus. The internal bus should at least have devices at 0x44 and 0x4c as confirmed above. I'll note the comment in this file, that indicates the "on silicon" I2C bus runs at 1.95 MHz: http://linuxtv.org/hg/v4l-dvb/file/8bff7e6c44d4/linux/drivers/media/video/cx23885/cx23885-core.c The TeVii S470 card had what looked like at serial I2C EEPROM with the A0, A1, and A2 pins all grounded, so I assume it is at 0x50 on one of the CX23885's external I2C buses. Regards, Andy > In the meantime, you can try i2cdetect -q to force i2cdetect to use > "SMBus quick" commands for all the addresses. Beware though that some > chips are known to not like it at all (in particular the infamous > AT24RF08... not that I expect to ever see one on a TV adapter but you > never know.) > > At least the above scan has already found 3 chips. > -- 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] proc_fops: convert cpia
Signed-off-by: Alexey Dobriyan
---
drivers/media/video/cpia.c | 211 ++---
1 file changed, 104 insertions(+), 107 deletions(-)
--- a/drivers/media/video/cpia.c
+++ b/drivers/media/video/cpia.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -244,72 +245,67 @@ static void rvfree(void *mem, unsigned long size)
#ifdef CONFIG_PROC_FS
static struct proc_dir_entry *cpia_proc_root=NULL;
-static int cpia_read_proc(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int cpia_proc_show(struct seq_file *m, void *v)
{
- char *out = page;
- int len, tmp;
- struct cam_data *cam = data;
+ struct cam_data *cam = m->private;
+ int tmp;
char tmpstr[29];
- /* IMPORTANT: This output MUST be kept under PAGE_SIZE
-*or we need to get more sophisticated. */
-
- out += sprintf(out, "read-only\n---\n");
- out += sprintf(out, "V4L Driver version: %d.%d.%d\n",
+ seq_printf(m, "read-only\n---\n");
+ seq_printf(m, "V4L Driver version: %d.%d.%d\n",
CPIA_MAJ_VER, CPIA_MIN_VER, CPIA_PATCH_VER);
- out += sprintf(out, "CPIA Version: %d.%02d (%d.%d)\n",
+ seq_printf(m, "CPIA Version: %d.%02d (%d.%d)\n",
cam->params.version.firmwareVersion,
cam->params.version.firmwareRevision,
cam->params.version.vcVersion,
cam->params.version.vcRevision);
- out += sprintf(out, "CPIA PnP-ID: %04x:%04x:%04x\n",
+ seq_printf(m, "CPIA PnP-ID: %04x:%04x:%04x\n",
cam->params.pnpID.vendor, cam->params.pnpID.product,
cam->params.pnpID.deviceRevision);
- out += sprintf(out, "VP-Version: %d.%d %04x\n",
+ seq_printf(m, "VP-Version: %d.%d %04x\n",
cam->params.vpVersion.vpVersion,
cam->params.vpVersion.vpRevision,
cam->params.vpVersion.cameraHeadID);
- out += sprintf(out, "system_state: %#04x\n",
+ seq_printf(m, "system_state: %#04x\n",
cam->params.status.systemState);
- out += sprintf(out, "grab_state: %#04x\n",
+ seq_printf(m, "grab_state: %#04x\n",
cam->params.status.grabState);
- out += sprintf(out, "stream_state: %#04x\n",
+ seq_printf(m, "stream_state: %#04x\n",
cam->params.status.streamState);
- out += sprintf(out, "fatal_error: %#04x\n",
+ seq_printf(m, "fatal_error: %#04x\n",
cam->params.status.fatalError);
- out += sprintf(out, "cmd_error:%#04x\n",
+ seq_printf(m, "cmd_error:%#04x\n",
cam->params.status.cmdError);
- out += sprintf(out, "debug_flags: %#04x\n",
+ seq_printf(m, "debug_flags: %#04x\n",
cam->params.status.debugFlags);
- out += sprintf(out, "vp_status:%#04x\n",
+ seq_printf(m, "vp_status:%#04x\n",
cam->params.status.vpStatus);
- out += sprintf(out, "error_code: %#04x\n",
+ seq_printf(m, "error_code: %#04x\n",
cam->params.status.errorCode);
/* QX3 specific entries */
if (cam->params.qx3.qx3_detected) {
- out += sprintf(out, "button: %4d\n",
+ seq_printf(m, "button: %4d\n",
cam->params.qx3.button);
- out += sprintf(out, "cradled: %4d\n",
+ seq_printf(m, "cradled: %4d\n",
cam->params.qx3.cradled);
}
- out += sprintf(out, "video_size: %s\n",
+ seq_printf(m, "video_size: %s\n",
cam->params.format.videoSize == VIDEOSIZE_CIF ?
"CIF " : "QCIF");
- out += sprintf(out, "roi: (%3d, %3d) to (%3d,
%3d)\n",
+ seq_printf(m, "roi: (%3d, %3d) to (%3d, %3d)\n",
cam->params.roi.colStart*8,
cam->params.roi.rowStart*4,
cam->params.roi.colEnd*8,
cam->params.roi.rowEnd*4);
- out += sprintf(out, "actual_fps: %3d\n", cam->fps);
- out += sprintf(out, "transfer_rate:%4dkB/s\n",
+ seq_printf(m, "actual_fps: %3d\n", cam->fps);
+ seq_printf(m, "transfer_rate:
Re: cx18: Reprise of YUV frame alignment improvements
On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls wrote: > OK, here's my second attempt at getting rid of cx18 YUV frame alignment > and tearing issues. > > http://linuxtv.org/hg/~awalls/cx18-yuv2 Hi Andy, I did some testing of your tree, using the following command mplayer /dev/video32 -demuxer rawvideo -rawvideo w=720:h=480:format=hm12:ntsc and then in parallel run a series of make commands of the v4l-dvb tree make -j2 && make unload && make -j2 && make unload && make -j2 && make unload && make -j2 && make unload I was definitely seeing the corruption by doing this test before your patches (both frame alignment and colorspace problems as PCI frames were being dropped). After your change, I no longer see those problems. The picture never became misaligned. However, it would appear that some sort of regression may have been introduced with the buffer handling. I was seeing a continuous reporting of the following in dmesg, even *after* I stopped generating the load by running the make commands. [ 5175.703811] cx18-0: Could not find MDL 106 for stream encoder YUV [ 5175.737380] cx18-0: Could not find MDL 111 for stream encoder YUV [ 5175.804317] cx18-0: Skipped encoder YUV, MDL 96, 3 times - it must have dropped out of rotation [ 5175.804324] cx18-0: Skipped encoder YUV, MDL 101, 3 times - it must have dropped out of rotation [ 5175.904500] cx18-0: Skipped encoder YUV, MDL 96, 2 times - it must have dropped out of rotation [ 5176.204507] cx18-0: Skipped encoder YUV, MDL 101, 1 times - it must have dropped out of rotation [ 5176.204513] cx18-0: Skipped encoder YUV, MDL 96, 1 times - it must have dropped out of rotation [ 5176.204518] cx18-0: Could not find MDL 111 for stream encoder YUV I would expect to see frame drops while the system was under high load, but I would expect that the errors would stop once the load fell back to something reasonable. However, they continue to accumulate even after the make commands stop and the only thing running on the system is mplayer (with a CPU load of around 10%). I think this tree is definitely on the right track, but it looks like some edge case has been missed. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/11] add the generic file
> +#ifdef CONFIG_PM
> +/* Is the card working now ? */
> +static inline int is_working(struct poseidon *pd)
> +{
> + if (pd->state & POSEIDON_STATE_IDLE_HIBERANTION)
> + return 0;
> + return pd->interface->pm_usage_cnt > 0;
> +}
> +
> +static int poseidon_suspend(struct usb_interface *intf, pm_message_t msg)
> +{
> + struct poseidon *pd = usb_get_intfdata(intf);
> +
> + if (!is_working(pd)) {
> + if (pd->interface->pm_usage_cnt <= 0
>
`interface->pm_usage_cnt` has been changed to atomic_t type in the latest code.
> + && !in_hibernation(pd)) {
> + pd->msg.event = PM_EVENT_AUTO_SUSPEND;
> + pd->pm_resume = NULL; /* a good guard */
> + printk(KERN_DEBUG "\n\t ++ TLG2300 auto suspend ++\n");
> + }
> + return 0;
> + }
> + pd->msg = msg;
>
--
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
