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 andrea.amoros...@gmail.com
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 nm...@freemial.hu
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 nm...@freemial.hu
---
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 len 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_dev *gspca_dev,
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 nm...@freemail.hu 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 nm...@freemail.hu
Add helper functions for interrupt endpoint based input handling.
Signed-off-by: Márton Németh nm...@freemail.hu
---
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 media/v4l2-ioctl.h
#include gspca.h
+
+#include linux/input.h
+#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;
[PATCH 2/2] gspca pac7302: add support for camera button
From: Márton Németh nm...@freemail.hu
Add support for snapshot button found on Labtec Webcam 2200
(USB ID 093a:2626).
Signed-off-by: Márton Németh nm...@freemail.hu
---
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 linux/input.h
#include media/v4l2-chip-ident.h
#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
[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 nm...@freemail.hu
Explicitly cast page count in the debug message.
Signed-off-by: Márton Németh nm...@freemail.hu
---
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 nm...@freemail.hu
The return value may be used uninitialized when the size parameter
happens to be 0.
Signed-off-by: Márton Németh nm...@freemail.hu
---
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 nm...@freemail.hu 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 nm...@freemail.hu --- 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 liplia...@me.by 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 adobri...@gmail.com
---
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 linux/fs.h
#include linux/vmalloc.h
#include linux/sched.h
+#include linux/seq_file.h
#include linux/slab.h
#include linux/proc_fs.h
#include linux/ctype.h
@@ -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,
Re: cx18: Reprise of YUV frame alignment improvements
On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls awa...@radix.net 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
