Re: [GIT PULL FOR 3.6] V4L2 API cleanups
On Sun, Jun 17, 2012 at 12:03:06AM +0200, Laurent Pinchart wrote: Hi Sakari, Hi Laurent, On Monday 11 June 2012 12:39:44 Sakari Ailus wrote: On Mon, Jun 11, 2012 at 09:50:54AM +0200, Laurent Pinchart wrote: On Sunday 10 June 2012 23:22:59 Sakari Ailus wrote: Hi Mauro, Here are two V4L2 API cleanup patches; the first removes __user from videodev2.h from a few places, making it possible to use the header file as such in user space, while the second one changes the v4l2_buffer.input field back to reserved. The following changes since commit 5472d3f17845c4398c6a510b46855820920c2181: [media] mt9m032: Implement V4L2_CID_PIXEL_RATE control (2012-05-24 09:27:24 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.6 Sakari Ailus (2): v4l: Remove __user from interface structure definitions NAK, sorry. __user has a purpose, we need to add it where it's missing, not remove it where it's rightfully present. It's not quite as simple as adding __user everywhere it might belong to --- these structs are being used in kernel space, too. The structs that are part of the user space interface may at some point contain pointers to memory which is in user space. That is being dealt by video_usercopy(), so the individual drivers or the rest of the V4L2 framework always gets pointers pointing to kernel memory. Very good point, I haven't thought about that. I'm not sure how to deal with this, splitting structures in a __user and a non __user version isn't really a good option. Maybe the sparse tool should be somehow extended ? Wouldn't type casting in video_usercopy() just do the job? Albeit I'm far from certain it'd make the code better, just make the sparse warnings go away... regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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: video: USB webcam fails since kernel 3.2
pe, 2012-06-15 kello 23:41 -0500, Jonathan Nieder kirjoitti: Martin-Éric Racine wrote: usb 1-7: new high-speed USB device number 3 using ehci_hcd [...] usb 1-7: New USB device found, idVendor=0ac8, idProduct=0321 usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-7: Product: USB2.0 Web Camera usb 1-7: Manufacturer: Vimicro Corp. [...] Linux media interface: v0.10 Linux video capture interface: v2.00 gspca_main: v2.14.0 registered gspca_main: vc032x-2.14.0 probing 0ac8:0321 usbcore: registered new interface driver vc032x The device of interest is discovered. gspca_main: ISOC data error: [36] len=0, status=-71 gspca_main: ISOC data error: [65] len=0, status=-71 [...] gspca_main: ISOC data error: [48] len=0, status=-71 video_source:sr[3246]: segfault at 0 ip (null) sp ab36de1c error 14 in cheese[8048000+21000] gspca_main: ISOC data error: [17] len=0, status=-71 (The above data error spew starts around t=121 seconds and continues at a rate of about 15 messages per second. The segfault is around t=154.) The vc032x code hasn't changed since 3.4.1, so please report your symptoms to Jean-François Moine moin...@free.fr, cc-ing linux-media@vger.kernel.org, linux-ker...@vger.kernel.org, and either me or this bug log so we can track it. Be sure to mention: - steps to reproduce, expected result, actual result, and how the difference indicates a bug (should be simple enough in this case) 1. Ensure that user 'myself' is a member of the 'video' group. 2. Launch the webcam application Cheese from the GNOME desktop. Expected result: Cheese displays whatever this laptop's camera sees. Actual result: Cheese crashes while attempting to access the camera. - how reproducible the bug is (100%?) 100% - which kernel versions you have tested and result with each (what is the newest kernel version that worked?) It probably was 3.1.0 or some earlier 3.2 release (the upcoming Debian will release with 3.2.x; 3.4 was only used here for testing purposes), but I wouldn't know for sure since I don't use my webcam too often. - a log from booting and reproducing the bug, or a link to one See http://bugs.debian.org/677533 - any other weird symptoms or observations When testing the camera using the closed-source Skype 4.x compiled for Debian, the video preferences dialog shows that a USB 2.0 camera is found at /dev/video0. However, no image is shown. This would confirm the assumption that the issue lies with the kernel video driver, rather than with the Gstreamer framework that Cheese uses to access the camera. Hopefully someone upstream will have ideas for commands to run or patches to apply to further track down the cause. Let's indeed hope so. Thanks for providing these instructions! Regards, Martin-Éric -- 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
uvcvideo issue with kernel 3.5-rc2 and 3
Hello, my external webcam from Logitech (I guess it's a c910) stopped working using kernel 3.5-rc3.( 3.4 worked fine.) uvcvideo: Found UVC 1.00 device unnamed (046d:0821) input: UVC Camera (046d:0821) as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.2/input/input14 usbcore: registered new interface driver uvcvideo USB Video Class driver (1.1.1) uvcvideo: Failed to query (GET_DEF) UVC control 2 on unit 2: -71 (exp. 2). uvcvideo: Failed to query (GET_DEF) UVC control 2 on unit 2: -71 (exp. 2). uvcvideo: Failed to query (GET_DEF) UVC control 3 on unit 2: -71 (exp. 2). uvcvideo: Failed to query (GET_DEF) UVC control 7 on unit 2: -71 (exp. 2). uvcvideo: Failed to query (GET_DEF) UVC control 11 on unit 2: -71 (exp. 1). uvcvideo: Failed to query (GET_DEF) UVC control 4 on unit 2: -71 (exp. 2). uvcvideo: Failed to query (GET_DEF) UVC control 5 on unit 2: -71 (exp. 1). uvcvideo: Failed to query (GET_CUR) UVC control 11 on unit 2: -71 (exp. 1). uvcvideo: Failed to query (GET_DEF) UVC control 8 on unit 2: -71 (exp. 2). uvcvideo: Failed to query (GET_DEF) UVC control 1 on unit 2: -71 (exp. 2). uvcvideo: Failed to set UVC probe control : -71 (exp. 26). uvcvideo: Failed to set UVC probe control : -71 (exp. 26). uvcvideo: Failed to set UVC probe control : -71 (exp. 26). uvcvideo: Failed to set UVC probe control : -71 (exp. 26). (the last line is being repeated...) I used cheese to test the webcam. My other webcam is working fine: uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b217) input: Integrated Camera as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input13 Thanks, Philipp Dreimann -- 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] tvaudio: rename getmode and setmode
This is basically s/getmode/getrxsubchans/ and s/setmode/setaudmode/
with some whitespace adjustment in affected lines to please the eye.
The rename is done to point out their relation to the rxsubchans and
audmode fields of struct v4l2_tuner.
I also corrected a commented out call to v4l_dbg in one of the lines.
Signed-off-by: Daniel Glöckner daniel...@gmx.net
---
drivers/media/video/tvaudio.c | 108 +++--
1 files changed, 60 insertions(+), 48 deletions(-)
diff --git a/drivers/media/video/tvaudio.c b/drivers/media/video/tvaudio.c
index 1e61cbf..321b315 100644
--- a/drivers/media/video/tvaudio.c
+++ b/drivers/media/video/tvaudio.c
@@ -59,8 +59,8 @@ struct CHIPSTATE;
typedef int (*getvalue)(int);
typedef int (*checkit)(struct CHIPSTATE*);
typedef int (*initialize)(struct CHIPSTATE*);
-typedef int (*getmode)(struct CHIPSTATE*);
-typedef void (*setmode)(struct CHIPSTATE*, int mode);
+typedef int (*getrxsubchans)(struct CHIPSTATE *);
+typedef void (*setaudmode)(struct CHIPSTATE*, int mode);
/* i2c command */
typedef struct AUDIOCMD {
@@ -96,8 +96,8 @@ struct CHIPDESC {
getvalue volfunc,treblefunc,bassfunc;
/* get/set mode */
- getmode getmode;
- setmode setmode;
+ getrxsubchans getrxsubchans;
+ setaudmode setaudmode;
/* input switch register + values for v4l inputs */
int inputreg;
@@ -306,7 +306,7 @@ static int chip_thread(void *data)
continue;
/* have a look what's going on */
- mode = desc-getmode(chip);
+ mode = desc-getrxsubchans(chip);
if (mode == chip-prevmode)
continue;
@@ -340,7 +340,7 @@ static int chip_thread(void *data)
else if (mode V4L2_TUNER_SUB_STEREO)
selected = V4L2_TUNER_MODE_STEREO;
}
- desc-setmode(chip, selected);
+ desc-setaudmode(chip, selected);
/* schedule next check */
mod_timer(chip-wt, jiffies+msecs_to_jiffies(2000));
@@ -373,7 +373,7 @@ static int chip_thread(void *data)
#define TDA9840_TEST_INT1SN 0x1 /* Integration time 0.5s when set */
#define TDA9840_TEST_INTFU 0x02 /* Disables integrator function */
-static int tda9840_getmode(struct CHIPSTATE *chip)
+static int tda9840_getrxsubchans(struct CHIPSTATE *chip)
{
struct v4l2_subdev *sd = chip-sd;
int val, mode;
@@ -385,12 +385,13 @@ static int tda9840_getmode(struct CHIPSTATE *chip)
if (val TDA9840_ST_STEREO)
mode = V4L2_TUNER_SUB_STEREO;
- v4l2_dbg(1, debug, sd, tda9840_getmode(): raw chip read: %d, return:
%d\n,
+ v4l2_dbg(1, debug, sd,
+ tda9840_getrxsubchans(): raw chip read: %d, return: %d\n,
val, mode);
return mode;
}
-static void tda9840_setmode(struct CHIPSTATE *chip, int mode)
+static void tda9840_setaudmode(struct CHIPSTATE *chip, int mode)
{
int update = 1;
int t = chip-shadow.bytes[TDA9840_SW + 1] ~0x7e;
@@ -532,7 +533,7 @@ static int tda9855_volume(int val) { return val/0x2e8+0x27;
}
static int tda9855_bass(int val) { return val/0xccc+0x06; }
static int tda9855_treble(int val) { return (val/0x1c71+0x3)1; }
-static int tda985x_getmode(struct CHIPSTATE *chip)
+static int tda985x_getrxsubchans(struct CHIPSTATE *chip)
{
int mode, val;
@@ -547,7 +548,7 @@ static int tda985x_getmode(struct CHIPSTATE *chip)
return mode;
}
-static void tda985x_setmode(struct CHIPSTATE *chip, int mode)
+static void tda985x_setaudmode(struct CHIPSTATE *chip, int mode)
{
int update = 1;
int c6 = chip-shadow.bytes[TDA985x_C6+1] 0x3f;
@@ -692,7 +693,7 @@ static void tda985x_setmode(struct CHIPSTATE *chip, int
mode)
#define TDA9873_STEREO 2 /* Stereo sound is identified */
#define TDA9873_DUAL4 /* Dual sound is identified */
-static int tda9873_getmode(struct CHIPSTATE *chip)
+static int tda9873_getrxsubchans(struct CHIPSTATE *chip)
{
struct v4l2_subdev *sd = chip-sd;
int val,mode;
@@ -703,24 +704,29 @@ static int tda9873_getmode(struct CHIPSTATE *chip)
mode = V4L2_TUNER_SUB_STEREO;
if (val TDA9873_DUAL)
mode |= V4L2_TUNER_SUB_LANG1 | V4L2_TUNER_SUB_LANG2;
- v4l2_dbg(1, debug, sd, tda9873_getmode(): raw chip read: %d, return:
%d\n,
+ v4l2_dbg(1, debug, sd,
+ tda9873_getrxsubchans(): raw chip read: %d, return: %d\n,
val, mode);
return mode;
}
-static void tda9873_setmode(struct CHIPSTATE *chip, int mode)
+static void tda9873_setaudmode(struct CHIPSTATE *chip, int mode)
{
struct v4l2_subdev *sd = chip-sd;
int sw_data = chip-shadow.bytes[TDA9873_SW+1] ~ TDA9873_TR_MASK;
/* int adj_data = chip-shadow.bytes[TDA9873_AD+1] ; */
if ((sw_data
Re: [PATCH] tvaudio: rename getmode and setmode
On Sun June 17 2012 13:53:42 Daniel Glöckner wrote:
This is basically s/getmode/getrxsubchans/ and s/setmode/setaudmode/
with some whitespace adjustment in affected lines to please the eye.
The rename is done to point out their relation to the rxsubchans and
audmode fields of struct v4l2_tuner.
I also corrected a commented out call to v4l_dbg in one of the lines.
Looks much better!
For the whole patch series:
Acked-by: Hans Verkuil hans.verk...@cisco.com
You could even make it a little bit better by removing all typedefs
(they are totally bogus) and lower case those ugly uppercase struct
names (CHIPSTATE, AUDIOCMD and CHIPDESC).
Regards,
Hans
Signed-off-by: Daniel Glöckner daniel...@gmx.net
---
drivers/media/video/tvaudio.c | 108
+++--
1 files changed, 60 insertions(+), 48 deletions(-)
diff --git a/drivers/media/video/tvaudio.c b/drivers/media/video/tvaudio.c
index 1e61cbf..321b315 100644
--- a/drivers/media/video/tvaudio.c
+++ b/drivers/media/video/tvaudio.c
@@ -59,8 +59,8 @@ struct CHIPSTATE;
typedef int (*getvalue)(int);
typedef int (*checkit)(struct CHIPSTATE*);
typedef int (*initialize)(struct CHIPSTATE*);
-typedef int (*getmode)(struct CHIPSTATE*);
-typedef void (*setmode)(struct CHIPSTATE*, int mode);
+typedef int (*getrxsubchans)(struct CHIPSTATE *);
+typedef void (*setaudmode)(struct CHIPSTATE*, int mode);
/* i2c command */
typedef struct AUDIOCMD {
@@ -96,8 +96,8 @@ struct CHIPDESC {
getvalue volfunc,treblefunc,bassfunc;
/* get/set mode */
- getmode getmode;
- setmode setmode;
+ getrxsubchans getrxsubchans;
+ setaudmode setaudmode;
/* input switch register + values for v4l inputs */
int inputreg;
@@ -306,7 +306,7 @@ static int chip_thread(void *data)
continue;
/* have a look what's going on */
- mode = desc-getmode(chip);
+ mode = desc-getrxsubchans(chip);
if (mode == chip-prevmode)
continue;
@@ -340,7 +340,7 @@ static int chip_thread(void *data)
else if (mode V4L2_TUNER_SUB_STEREO)
selected = V4L2_TUNER_MODE_STEREO;
}
- desc-setmode(chip, selected);
+ desc-setaudmode(chip, selected);
/* schedule next check */
mod_timer(chip-wt, jiffies+msecs_to_jiffies(2000));
@@ -373,7 +373,7 @@ static int chip_thread(void *data)
#define TDA9840_TEST_INT1SN 0x1 /* Integration time 0.5s when set */
#define TDA9840_TEST_INTFU 0x02 /* Disables integrator function */
-static int tda9840_getmode(struct CHIPSTATE *chip)
+static int tda9840_getrxsubchans(struct CHIPSTATE *chip)
{
struct v4l2_subdev *sd = chip-sd;
int val, mode;
@@ -385,12 +385,13 @@ static int tda9840_getmode(struct CHIPSTATE *chip)
if (val TDA9840_ST_STEREO)
mode = V4L2_TUNER_SUB_STEREO;
- v4l2_dbg(1, debug, sd, tda9840_getmode(): raw chip read: %d, return:
%d\n,
+ v4l2_dbg(1, debug, sd,
+ tda9840_getrxsubchans(): raw chip read: %d, return: %d\n,
val, mode);
return mode;
}
-static void tda9840_setmode(struct CHIPSTATE *chip, int mode)
+static void tda9840_setaudmode(struct CHIPSTATE *chip, int mode)
{
int update = 1;
int t = chip-shadow.bytes[TDA9840_SW + 1] ~0x7e;
@@ -532,7 +533,7 @@ static int tda9855_volume(int val) { return
val/0x2e8+0x27; }
static int tda9855_bass(int val) { return val/0xccc+0x06; }
static int tda9855_treble(int val) { return (val/0x1c71+0x3)1; }
-static int tda985x_getmode(struct CHIPSTATE *chip)
+static int tda985x_getrxsubchans(struct CHIPSTATE *chip)
{
int mode, val;
@@ -547,7 +548,7 @@ static int tda985x_getmode(struct CHIPSTATE *chip)
return mode;
}
-static void tda985x_setmode(struct CHIPSTATE *chip, int mode)
+static void tda985x_setaudmode(struct CHIPSTATE *chip, int mode)
{
int update = 1;
int c6 = chip-shadow.bytes[TDA985x_C6+1] 0x3f;
@@ -692,7 +693,7 @@ static void tda985x_setmode(struct CHIPSTATE *chip, int
mode)
#define TDA9873_STEREO 2 /* Stereo sound is identified */
#define TDA9873_DUAL4 /* Dual sound is identified */
-static int tda9873_getmode(struct CHIPSTATE *chip)
+static int tda9873_getrxsubchans(struct CHIPSTATE *chip)
{
struct v4l2_subdev *sd = chip-sd;
int val,mode;
@@ -703,24 +704,29 @@ static int tda9873_getmode(struct CHIPSTATE *chip)
mode = V4L2_TUNER_SUB_STEREO;
if (val TDA9873_DUAL)
mode |= V4L2_TUNER_SUB_LANG1 | V4L2_TUNER_SUB_LANG2;
- v4l2_dbg(1, debug, sd, tda9873_getmode(): raw chip read: %d, return:
%d\n,
+ v4l2_dbg(1, debug, sd,
+ tda9873_getrxsubchans(): raw chip read: %d, return: %d\n,
DiBcom adapter problems
Hi, every time that i try to syntonize DVB-T channels i receive a message in kernel like in log1.txt arch. There are in log2.txt some usefull information about the device. My kernel/system is: Linux version 3.4.2-gentoo-r1-asgard (root@asgard) (gcc version 4.6.3 (Gentoo 4.6.3 p1.3, pie-0.5.2) ) #1 SMP PREEMPT Thu Jun 14 07:45:19 BRT 2012 Best Regards dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to delivery system 0 dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to delivery system 0 dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0 dtv_property_cache_sync: doesn't know how to handle a DVBv3 call to delivery system 0
DiBcom adapter problems
Hi, every time that i try to syntonize DVB-T channels i receive a message in kernel like in log1.txt arch. There are in log2.txt some usefull information about the device. -- 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: video: USB webcam fails since kernel 3.2
(cc-ing Hans de Goede, the new gspca maintainer. Sorry I missed that before.) Martin-Éric Racine wrote: usb 1-7: new high-speed USB device number 3 using ehci_hcd [...] usb 1-7: Product: USB2.0 Web Camera usb 1-7: Manufacturer: Vimicro Corp. [...] gspca_main: v2.14.0 registered gspca_main: vc032x-2.14.0 probing 0ac8:0321 [...] gspca_main: ISOC data error: [36] len=0, status=-71 gspca_main: ISOC data error: [65] len=0, status=-71 [...] gspca_main: ISOC data error: [48] len=0, status=-71 video_source:sr[3246]: segfault at 0 ip (null) sp ab36de1c error 14 in cheese[8048000+21000] gspca_main: ISOC data error: [17] len=0, status=-71 Thanks again. If you get a chance to test Hans's media-for_v3.5 branch, that would be interesting. It works like so: 0. prerequisites: apt-get install git build-essential 1. get the kernel history, if you don't already have it: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. fetch gspca updates: cd linux git remote add gspca \ git://linuxtv.org/hgoede/gspca.git git fetch gspca 3. configure, build, test: git checkout gspca/media-for_v3.5 cp /boot/config-$(uname -r) .config; # current configuration scripts/config --disable DEBUG_INFO make localmodconfig; # optional: minimize configuration make deb-pkg; # optionally with -jnum for parallel build dpkg -i ../name of package; # as root reboot ... test test test ... I ask because there have been some gspca core fixes cooking that are not part of the 3.4.y tree, though none of them looks especially relevant. Hope that helps, Jonathan -- 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: video: USB webcam fails since kernel 3.2
Jonathan Nieder wrote: (cc-ing Hans de Goede, the new gspca maintainer. Sorry I missed that before.) Actually cc-ing this time. Sorry for the noise. Martin-Éric Racine wrote: usb 1-7: new high-speed USB device number 3 using ehci_hcd [...] usb 1-7: Product: USB2.0 Web Camera usb 1-7: Manufacturer: Vimicro Corp. [...] gspca_main: v2.14.0 registered gspca_main: vc032x-2.14.0 probing 0ac8:0321 [...] gspca_main: ISOC data error: [36] len=0, status=-71 gspca_main: ISOC data error: [65] len=0, status=-71 [...] gspca_main: ISOC data error: [48] len=0, status=-71 video_source:sr[3246]: segfault at 0 ip (null) sp ab36de1c error 14 in cheese[8048000+21000] gspca_main: ISOC data error: [17] len=0, status=-71 Thanks again. If you get a chance to test Hans's media-for_v3.5 branch, that would be interesting. It works like so: 0. prerequisites: apt-get install git build-essential 1. get the kernel history, if you don't already have it: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. fetch gspca updates: cd linux git remote add gspca \ git://linuxtv.org/hgoede/gspca.git git fetch gspca 3. configure, build, test: git checkout gspca/media-for_v3.5 cp /boot/config-$(uname -r) .config; # current configuration scripts/config --disable DEBUG_INFO make localmodconfig; # optional: minimize configuration make deb-pkg; # optionally with -jnum for parallel build dpkg -i ../name of package; # as root reboot ... test test test ... I ask because there have been some gspca core fixes cooking that are not part of the 3.4.y tree, though none of them looks especially relevant. Hope that helps, Jonathan -- 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
TERRATEC Cinergy T PCIE dual remote control support ?
Hello everybody ! First of all, i would like to thank you all for your wonderful work. Thanks to you, my new Terratec Cinergy T PCIE dual card is now receiving TV on my linux HTPC. The only remaining thing that is not working is the remote control (not at all). This remote control seems to be the same as a Cinergy HTC USB XS. It can be seen on image http://www.terratec.net/us/produits/photos/img/3923630_4ac1bb0a60.png So the mapping is probably the same as a Cinergy XS product. In fact, when the cx23885 module driver is loaded, no ir input is associated with the card nor created in /dev/input. Here is the output of dmesg when inserting the cx23885 module in the kernel : [ 9321.995048] cx23885 driver version 0.0.3 loaded [ 9321.999469] CORE cx23885[0]: subsystem: 153b:117e, board: TerraTec Cinergy T PCIe Dual [card=34,autodetected] [ 9322.130326] cx25840 5-0044: cx23885 A/V decoder found @ 0x88 (cx23885[0]) [ 9322.755350] cx25840 5-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) [ 9322.788281] cx23885_dvb_register() allocating 1 frontend(s) [ 9322.788285] cx23885[0]: cx23885 based dvb card [ 9322.803661] drxk: status = 0x639160d9 [ 9322.803666] drxk: detected a drx-3916k, spin A3, xtal 20.250 MHz [ 9322.876517] DRXK driver version 0.9.4300 [ 9322.900430] drxk: frontend initialized. [ 9322.900449] mt2063_attach: Attaching MT2063 [ 9322.900451] DVB: registering new adapter (cx23885[0]) [ 9322.900454] DVB: registering adapter 0 frontend 0 (DRXK DVB-T)... [ 9322.901581] cx23885_dvb_register() allocating 1 frontend(s) [ 9322.901586] cx23885[0]: cx23885 based dvb card [ 9322.916744] drxk: status = 0x639130d9 [ 9322.916749] drxk: detected a drx-3913k, spin A3, xtal 20.250 MHz [ 9322.989590] DRXK driver version 0.9.4300 [ 9323.013545] drxk: frontend initialized. [ 9323.013567] mt2063_attach: Attaching MT2063 [ 9323.013570] DVB: registering new adapter (cx23885[0]) [ 9323.013573] DVB: registering adapter 1 frontend 0 (DRXK DVB-C DVB-T)... [ 9323.013955] cx23885_dev_checkrevision() Hardware revision = 0xa5 [ 9323.013961] cx23885[0]/0: found at :02:00.0, rev: 4, irq: 16, latency: 0, mmio: 0xfd80 Any ideas on how to make the ir receiver recognized and work ? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Fix audio on analog cx231xx devices
With the following patches, I get proper audio on my HVR850 and there isn't a stutter when starting Live TV under MythTV. I think this also fixes a number of odd crashes I've seen on the box, which can easily be explained by DMA to unlucky addresses. The first patch fixes DMA for the device; I think this also keeps MythTV from being unhappy with the stream (VBI timeouts), though I've not explicitly tested that -- I'm confident in the VBI change based on code inspection. I'm not sure the second patch is needed; on my system, audio seems to work with and without the patch. However, the patch does not hurt my hardware, and the value is never passed in to cx231xx_initialize_stream_xfer() so I think there is a argument to be made for using the provided names instead of magic numbers. -- 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] [media] cx231xx: don't DMA to random addresses
Commit 7a6f6c29d264cdd2fe0eb3d923217eed5f0ad134 (cx231xx: use URB_NO_TRANSFER_DMA_MAP) was intended to avoid mapping the DMA buffer for URB twice. This works for the URBs allocated with usb_alloc_urb(), as those are allocated from cohernent DMA pools, but the flag was also added for the VBI and audio URBs, which have a manually allocated area. This leaves the random trash in the structure after allocation as the DMA address, corrupting memory and preventing VBI and audio from working. Letting the USB core map the buffers solves the problem. Signed-off-by: David Dillow d...@thedillows.org -- This should also go to -stable, as this can corrupt memory. diff --git a/drivers/media/video/cx231xx/cx231xx-audio.c b/drivers/media/video/cx231xx/cx231xx-audio.c index 068f78d..b4c99c7 100644 --- a/drivers/media/video/cx231xx/cx231xx-audio.c +++ b/drivers/media/video/cx231xx/cx231xx-audio.c @@ -307,7 +307,7 @@ static int cx231xx_init_audio_isoc(struct cx231xx *dev) urb-context = dev; urb-pipe = usb_rcvisocpipe(dev-udev, dev-adev.end_point_addr); - urb-transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP; + urb-transfer_flags = URB_ISO_ASAP; urb-transfer_buffer = dev-adev.transfer_buffer[i]; urb-interval = 1; urb-complete = cx231xx_audio_isocirq; @@ -368,7 +368,7 @@ static int cx231xx_init_audio_bulk(struct cx231xx *dev) urb-context = dev; urb-pipe = usb_rcvbulkpipe(dev-udev, dev-adev.end_point_addr); - urb-transfer_flags = URB_NO_TRANSFER_DMA_MAP; + urb-transfer_flags = 0; urb-transfer_buffer = dev-adev.transfer_buffer[i]; urb-complete = cx231xx_audio_bulkirq; urb-transfer_buffer_length = sb_size; diff --git a/drivers/media/video/cx231xx/cx231xx-vbi.c b/drivers/media/video/cx231xx/cx231xx-vbi.c index 3d15314..ac7db52 100644 --- a/drivers/media/video/cx231xx/cx231xx-vbi.c +++ b/drivers/media/video/cx231xx/cx231xx-vbi.c @@ -448,7 +448,7 @@ int cx231xx_init_vbi_isoc(struct cx231xx *dev, int max_packets, return -ENOMEM; } dev-vbi_mode.bulk_ctl.urb[i] = urb; - urb-transfer_flags = URB_NO_TRANSFER_DMA_MAP; + urb-transfer_flags = 0; dev-vbi_mode.bulk_ctl.transfer_buffer[i] = kzalloc(sb_size, GFP_KERNEL); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2][media] cx231xx: use TRANSFER_TYPE enum for cleanup
Most calls to cx231xx_capture_start() already use the values from
TRANSFER_TYPE, but cx231xx_capture_start() and
cx231xx_initialize_stream_xfer() were hand coding the values.
Use the named values (81 is never passed in), and simplify
cx231xx_capture_start(), as the switch statements were identical and
pcb_config-config_num is a u8, so any non-zero config got the same
result.
Signed-off-by: David Dillow d...@thedillows.org
--
This may not be strictly necessary for audio to work, and has only been
tested on my HVR-850 (2040:b140). I don't know if there are devices out
there that break if we enter HANC.
diff --git a/drivers/media/video/cx231xx/cx231xx-avcore.c
b/drivers/media/video/cx231xx/cx231xx-avcore.c
index b085a3c..447148e 100644
--- a/drivers/media/video/cx231xx/cx231xx-avcore.c
+++ b/drivers/media/video/cx231xx/cx231xx-avcore.c
@@ -89,7 +89,7 @@ void initGPIO(struct cx231xx *dev)
verve_read_byte(dev, 0x07, val);
cx231xx_info( verve_read_byte address0x07=0x%x\n, val);
- cx231xx_capture_start(dev, 1, 2);
+ cx231xx_capture_start(dev, 1, Vbi);
cx231xx_mode_register(dev, EP_MODE_SET, 0x0500FE00);
cx231xx_mode_register(dev, GBULK_BIT_EN, 0xFFFD);
@@ -99,7 +99,7 @@ void uninitGPIO(struct cx231xx *dev)
{
u8 value[4] = { 0, 0, 0, 0 };
- cx231xx_capture_start(dev, 0, 2);
+ cx231xx_capture_start(dev, 0, Vbi);
verve_write_byte(dev, 0x07, 0x14);
cx231xx_write_ctrl_reg(dev, VRT_SET_REGISTER,
0x68, value, 4);
@@ -2516,29 +2516,29 @@ int cx231xx_initialize_stream_xfer(struct cx231xx *dev,
u32 media_type)
if (dev-udev-speed == USB_SPEED_HIGH) {
switch (media_type) {
- case 81: /* audio */
+ case Audio:
cx231xx_info(%s: Audio enter HANC\n, __func__);
status =
cx231xx_mode_register(dev, TS_MODE_REG, 0x9300);
break;
- case 2: /* vbi */
+ case Vbi:
cx231xx_info(%s: set vanc registers\n, __func__);
status = cx231xx_mode_register(dev, TS_MODE_REG, 0x300);
break;
- case 3: /* sliced cc */
+ case Sliced_cc:
cx231xx_info(%s: set hanc registers\n, __func__);
status =
cx231xx_mode_register(dev, TS_MODE_REG, 0x1300);
break;
- case 0: /* video */
+ case Raw_Video:
cx231xx_info(%s: set video registers\n, __func__);
status = cx231xx_mode_register(dev, TS_MODE_REG, 0x100);
break;
- case 4: /* ts1 */
+ case TS1_serial_mode:
cx231xx_info(%s: set ts1 registers, __func__);
if (dev-board.has_417) {
@@ -2569,7 +2569,7 @@ int cx231xx_initialize_stream_xfer(struct cx231xx *dev,
u32 media_type)
}
break;
- case 6: /* ts1 parallel mode */
+ case TS1_parallel_mode:
cx231xx_info(%s: set ts1 parallel mode registers\n,
__func__);
status = cx231xx_mode_register(dev, TS_MODE_REG, 0x100);
@@ -2592,52 +2592,28 @@ int cx231xx_capture_start(struct cx231xx *dev, int
start, u8 media_type)
/* get EP for media type */
pcb_config = (struct pcb_config *)dev-current_pcb_config;
- if (pcb_config-config_num == 1) {
+ if (pcb_config-config_num) {
switch (media_type) {
- case 0: /* Video */
+ case Raw_Video:
ep_mask = ENABLE_EP4; /* ep4 [00:1000] */
break;
- case 1: /* Audio */
+ case Audio:
ep_mask = ENABLE_EP3; /* ep3 [00:0100] */
break;
- case 2: /* Vbi */
+ case Vbi:
ep_mask = ENABLE_EP5; /* ep5 [01:] */
break;
- case 3: /* Sliced_cc */
+ case Sliced_cc:
ep_mask = ENABLE_EP6; /* ep6 [10:] */
break;
- case 4: /* ts1 */
- case 6: /* ts1 parallel mode */
+ case TS1_serial_mode:
+ case TS1_parallel_mode:
ep_mask = ENABLE_EP1; /* ep1 [00:0001] */
break;
- case 5: /* ts2 */
+ case TS2:
ep_mask = ENABLE_EP2; /* ep2 [00:0010] */
break;
}
-
- } else if (pcb_config-config_num 1) {
- switch (media_type) {
- case 0: /* Video */
- ep_mask =
Re: [PATCH 1/2] [media] cx231xx: don't DMA to random addresses
On Mon, 2012-06-18 at 00:15 -0400, David Dillow wrote: Commit 7a6f6c29d264cdd2fe0eb3d923217eed5f0ad134 (cx231xx: use URB_NO_TRANSFER_DMA_MAP) was intended to avoid mapping the DMA buffer for URB twice. This works for the URBs allocated with usb_alloc_urb(), as those are allocated from cohernent DMA pools, but the flag was also Nothing like finding a typo once you've sent a patch out to the wild... s/cohernent/coherent/ -- 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
[RFC] [media] cx231xx: restore tuner settings on first open
Without this patch, MythTV requires some workarounds to be able to
capture analog TV on my HVR-850. I need to keep the v4l device open via
'sleep 365d /dev/video0' or some other mechanism or there will be no
recording. Also, I need to run vq4l2 and change the standard away and
back to NTSC or I'll get garbage. Both of these can be traced to the
settings (or lack there of) on the tuner.
The first problem is that we will tell applications that we are in NTSC
mode for the HVR-850 when they open the device for the first time after
plugging it in, but never actually set the TDA18271 to NTSC, so it
defaults to PAL_I. Applications may decide to not change the signal
standard, as they have been told it is already in the desired state.
This could be resolved by setting it during init (as we claim in the
query results), as it seems to survive putting the tuner into standby
mode.
The second problem is a bad interaction between driver behavior and
MythTV. MythTV opens the video device, tunes to the desired channel,
then closes the device. It then reopens the device and starts recording.
While this works for my WinTV-FM PCI card, the cx231xx driver puts the
tuner into standby after MythTV closes the device, and the tuner looses
the frequency when waking back up.
I solved both of these issues by just setting the standard and frequency
when opening the device for the first user. This fixes the immediate
problem, but I'm not sure it's the right fix, and I'm a bit
uncomfortable faking a call into the ioctl() routines.
What does the V4L2 API spec say about tuning frequency being persistent
when there are no users of a video capture device? Is MythTV wrong to
have that assumption, or is cx231xx wrong to not restore the frequency
when a user first opens the device?
Either way, I think MythTV should keep the device open until it is done
with it, as that would avoid added latency from putting the tuner to
sleep and waking it back up. But, I think we should address the issue in
the driver if it is not living up to the guarantees of the API.
diff --git a/drivers/media/video/cx231xx/cx231xx-video.c
b/drivers/media/video/cx231xx/cx231xx-video.c
index 7f916f0..2794396 100644
--- a/drivers/media/video/cx231xx/cx231xx-video.c
+++ b/drivers/media/video/cx231xx/cx231xx-video.c
@@ -2190,6 +2190,12 @@ static int cx231xx_v4l2_open(struct file *filp)
filp-private_data = fh;
if (fh-type == V4L2_BUF_TYPE_VIDEO_CAPTURE dev-users == 0) {
+ struct v4l2_frequency freq = {
+ .tuner = 0,
+ .type = V4L2_TUNER_ANALOG_TV,
+ .frequency = dev-ctl_freq,
+ };
+
dev-width = norm_maxw(dev);
dev-height = norm_maxh(dev);
@@ -2214,6 +2220,11 @@ static int cx231xx_v4l2_open(struct file *filp)
/* device needs to be initialized before isoc transfer */
dev-video_input = dev-video_input 2 ? 2 : dev-video_input;
+ /* Restore standard and channel, as they may be lost when
+* the tuner went to sleep.
+*/
+ vidioc_s_std(filp, fh, dev-norm);
+ vidioc_s_frequency(filp, fh, freq);
}
if (fh-radio) {
cx231xx_videodbg(video_open: setting radio device\n);
--
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
