cx25840: probe crashes for cx25837 chip on 2.6.37
Hello together! I was eager to test my patch for cx25840 that was included in 2.6.37, so I've updated my system and plugged in my Grabster AV400. But this resulted in a kernel bug printed to dmesg: dmesg begin usb 1-5: new high speed USB device using ehci_hcd and address 6 Linux video capture interface: v2.00 pvrusb2: Hardware description: Terratec Grabster AV400 pvrusb2: ** pvrusb2: WARNING: Support for this device (Terratec Grabster AV400) is experimental. pvrusb2: Important functionality might not be entirely working. pvrusb2: Please consider contacting the driver author to help with further stabilization of the driver. pvrusb2: ** usb 1-5: USB disconnect, address 6 usbcore: registered new interface driver pvrusb2 pvrusb2: 20110116 (from www.isely.net):Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner pvrusb2: Debug mask is 31 (0x1f) pvrusb2: Failed to submit write-control URB status=-19 pvrusb2: Device being rendered inoperable pvrusb2: ***WARNING*** pvrusb2 device hardware appears to be jammed and I can't clear it. pvrusb2: You might need to power cycle the pvrusb2 device in order to recover. usb 1-5: new high speed USB device using ehci_hcd and address 7 pvrusb2: Hardware description: Terratec Grabster AV400 pvrusb2: ** pvrusb2: WARNING: Support for this device (Terratec Grabster AV400) is experimental. pvrusb2: Important functionality might not be entirely working. pvrusb2: Please consider contacting the driver author to help with further stabilization of the driver. pvrusb2: ** cx25840 6-0044: cx25837-3 found @ 0x88 (pvrusb2_a) [ cut here ] kernel BUG at drivers/media/video/v4l2-ctrls.c:1143! invalid opcode: [#1] PREEMPT SMP last sysfs file: /sys/devices/pci:00/:00:02.2/usb1/1-5/i2c-6/6-0044/uevent CPU 1 Modules linked in: cx25840 pvrusb2 dvb_core cx2341x v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 tveeprom ipv6 xfs exportfs ext2 radeon snd_emu10k1 snd_intel8x0 ohci_hcd snd_rawmidi snd_ac97_codec ttm drm_kms_helper ac97_bus snd_seq_dummy skge ehci_hcd snd_seq_oss snd_seq_midi_event snd_seq snd_util_mem snd_seq_device snd_pcm_oss snd_hwdep snd_mixer_oss snd_pcm snd_timer emu10k1_gp drm i2c_algo_bit shpchp snd i2c_nforce2 soundcore usbcore processor pci_hotplug i2c_core parport_pc snd_page_alloc floppy serio_raw button psmouse ns558 edac_core ppdev k8temp edac_mce_amd evdev sg analog lp gameport pcspkr parport ext4 mbcache jbd2 crc16 sd_mod sr_mod cdrom sata_nv pata_acpi sata_sil24 pata_amd libata scsi_mod raid1 md_mod Pid: 2184, comm: pvrusb2-context Not tainted 2.6.37-ARCH #1 nForce/ RIP: 0010:[a020b352] [a020b352] v4l2_ctrl_cluster+0x32/0x40 [videodev] RSP: 0018:880033c61a30 EFLAGS: 00010246 RAX: 0001 RBX: 880038065800 RCX: 0001 RDX: RSI: 880039de1ee0 RDI: 0002 RBP: 880033c61a30 R08: R09: R10: R11: R12: 880039de1e78 R13: 8373 R14: 880039de1e00 R15: 00ed FS: 7f05b98a8700() GS:88003fd0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 7fff6c8c5fe0 CR3: 3c89b000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process pvrusb2-context (pid: 2184, threadinfo 880033c6, task 88003f8ada30) Stack: 880033c61aa0 a0310b99 8800 88003c99e3fc 880033c61ab0 0200 880039de1e08 880033c61ac0 880038065828 a0318590 a0318540 Call Trace: [a0310b99] cx25840_probe+0x479/0x840 [cx25840] [a0308694] i2c_device_probe+0x94/0xd0 [i2c_core] [812b0f0a] ? driver_sysfs_add+0x7a/0xb0 [812b11e6] driver_probe_device+0x96/0x1c0 [812b13b0] ? __device_attach+0x0/0x60 [812b13fb] __device_attach+0x4b/0x60 [812afdd4] bus_for_each_drv+0x64/0x90 [812b107f] device_attach+0x8f/0xb0 [812b0805] bus_probe_device+0x25/0x40 [812ae574] device_add+0x4e4/0x5c0 [812ba941] ? pm_runtime_init+0xd1/0xe0 [812ae669] device_register+0x19/0x20 [a03091d5] i2c_new_device+0x145/0x250 [i2c_core] [a00b77b6] v4l2_i2c_new_subdev_board+0x96/0x240 [v4l2_common] [a00b79e3] v4l2_i2c_new_subdev_cfg+0x83/0xb0 [v4l2_common] [a0363760] ? pvr2_context_notify+0x0/0x10 [pvrusb2] [a0363760] ? pvr2_context_notify+0x0/0x10 [pvrusb2] [a035b606] pvr2_hdw_initialize+0x346/0x1060 [pvrusb2] [a036394b] pvr2_context_thread_func+0x9b/0x320 [pvrusb2] [a03638b0] ? pvr2_context_thread_func+0x0/0x320 [pvrusb2] [81077db0] ? autoremove_wake_function+0x0/0x40 [813a6dc2] ? _raw_spin_unlock_irqrestore+0x32/0x40 [a03638b0] ?
Re: cx25840: probe crashes for cx25837 chip on 2.6.37
On 05.02.2011 22:25, Andy Walls wrote: On Sat, 2011-02-05 at 16:45 +0100, Sven Barth wrote: Hello together! I was eager to test my patch for cx25840 that was included in 2.6.37, so I've updated my system and plugged in my Grabster AV400. But this resulted in a kernel bug printed to dmesg: dmesg begin usb 1-5: new high speed USB device using ehci_hcd and address 6 Linux video capture interface: v2.00 pvrusb2: Hardware description: Terratec Grabster AV400 pvrusb2: ** pvrusb2: WARNING: Support for this device (Terratec Grabster AV400) is experimental. pvrusb2: Important functionality might not be entirely working. pvrusb2: Please consider contacting the driver author to help with further stabilization of the driver. pvrusb2: ** usb 1-5: USB disconnect, address 6 usbcore: registered new interface driver pvrusb2 pvrusb2: 20110116 (from www.isely.net):Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner pvrusb2: Debug mask is 31 (0x1f) pvrusb2: Failed to submit write-control URB status=-19 pvrusb2: Device being rendered inoperable pvrusb2: ***WARNING*** pvrusb2 device hardware appears to be jammed and I can't clear it. pvrusb2: You might need to power cycle the pvrusb2 device in order to recover. usb 1-5: new high speed USB device using ehci_hcd and address 7 pvrusb2: Hardware description: Terratec Grabster AV400 pvrusb2: ** pvrusb2: WARNING: Support for this device (Terratec Grabster AV400) is experimental. pvrusb2: Important functionality might not be entirely working. pvrusb2: Please consider contacting the driver author to help with further stabilization of the driver. pvrusb2: ** cx25840 6-0044: cx25837-3 found @ 0x88 (pvrusb2_a) [ cut here ] kernel BUG at drivers/media/video/v4l2-ctrls.c:1143! invalid opcode: [#1] PREEMPT SMP last sysfs file: /sys/devices/pci:00/:00:02.2/usb1/1-5/i2c-6/6-0044/uevent CPU 1 Modules linked in: cx25840 pvrusb2 dvb_core cx2341x v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 tveeprom ipv6 xfs exportfs ext2 radeon snd_emu10k1 snd_intel8x0 ohci_hcd snd_rawmidi snd_ac97_codec ttm drm_kms_helper ac97_bus snd_seq_dummy skge ehci_hcd snd_seq_oss snd_seq_midi_event snd_seq snd_util_mem snd_seq_device snd_pcm_oss snd_hwdep snd_mixer_oss snd_pcm snd_timer emu10k1_gp drm i2c_algo_bit shpchp snd i2c_nforce2 soundcore usbcore processor pci_hotplug i2c_core parport_pc snd_page_alloc floppy serio_raw button psmouse ns558 edac_core ppdev k8temp edac_mce_amd evdev sg analog lp gameport pcspkr parport ext4 mbcache jbd2 crc16 sd_mod sr_mod cdrom sata_nv pata_acpi sata_sil24 pata_amd libata scsi_mod raid1 md_mod Pid: 2184, comm: pvrusb2-context Not tainted 2.6.37-ARCH #1 nForce/ RIP: 0010:[a020b352] [a020b352] v4l2_ctrl_cluster+0x32/0x40 [videodev] RSP: 0018:880033c61a30 EFLAGS: 00010246 RAX: 0001 RBX: 880038065800 RCX: 0001 RDX: RSI: 880039de1ee0 RDI: 0002 RBP: 880033c61a30 R08: R09: R10: R11: R12: 880039de1e78 R13: 8373 R14: 880039de1e00 R15: 00ed FS: 7f05b98a8700() GS:88003fd0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 7fff6c8c5fe0 CR3: 3c89b000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process pvrusb2-context (pid: 2184, threadinfo 880033c6, task 88003f8ada30) Stack: 880033c61aa0 a0310b99 8800 88003c99e3fc 880033c61ab0 0200 880039de1e08 880033c61ac0 880038065828 a0318590 a0318540 Call Trace: [a0310b99] cx25840_probe+0x479/0x840 [cx25840] [a0308694] i2c_device_probe+0x94/0xd0 [i2c_core] [812b0f0a] ? driver_sysfs_add+0x7a/0xb0 [812b11e6] driver_probe_device+0x96/0x1c0 [812b13b0] ? __device_attach+0x0/0x60 [812b13fb] __device_attach+0x4b/0x60 [812afdd4] bus_for_each_drv+0x64/0x90 [812b107f] device_attach+0x8f/0xb0 [812b0805] bus_probe_device+0x25/0x40 [812ae574] device_add+0x4e4/0x5c0 [812ba941] ? pm_runtime_init+0xd1/0xe0 [812ae669] device_register+0x19/0x20 [a03091d5] i2c_new_device+0x145/0x250 [i2c_core] [a00b77b6] v4l2_i2c_new_subdev_board+0x96/0x240 [v4l2_common] [a00b79e3] v4l2_i2c_new_subdev_cfg+0x83/0xb0 [v4l2_common] [a0363760] ? pvr2_context_notify+0x0/0x10 [pvrusb2] [a0363760] ? pvr2_context_notify+0x0/0x10 [pvrusb2] [a035b606] pvr2_hdw_initialize+0x346/0x1060 [pvrusb2] [a036394b] pvr2_context_thread_func+0x9b/0x320 [pvrusb2
[PATCH] cx25840: fix probing of cx2583x chips
Fix the probing of cx2583x chips, because two controls were clustered that are not created for these chips. This regression was introduced in 2.6.36. Signed-off-by: Sven Barth pascaldra...@googlemail.com diff -aur linux-2.6.37/drivers/media/video/cx25840/cx25840-core.c linux-2.6.37-patched/drivers/media/video/cx25840/cx25840-core.c --- linux-2.6.37/drivers/media/video/cx25840/cx25840-core.c 2011-01-05 00:50:19.0 + +++ linux-2.6.37-patched/drivers/media/video/cx25840/cx25840-core.c 2011-02-05 15:58:27.733325238 + @@ -2031,7 +2031,8 @@ kfree(state); return err; } - v4l2_ctrl_cluster(2, state-volume); + if (!is_cx2583x(state)) + v4l2_ctrl_cluster(2, state-volume); v4l2_ctrl_handler_setup(state-hdl); cx25840_ir_probe(sd); -- 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: Old patches sent via the Mailing list
On 20.10.2010 14:00, Andy Walls wrote: On Wed, 2010-10-20 at 07:19 +0200, Sven Barth wrote: Am 18.10.2010 08:15, schrieb Mauro Carvalho Chehab: Em 17-10-2010 21:36, Andy Walls escreveu: The last time I sent this list, I was about to travel, and I may have missed some comments, or maybe I may just forgot to update. But I suspect that, for the list bellow, most of them are stuff where the driver maintainer just forgot at limbo. From the list of patches under review, we have: Waiting for new patch, signed, from Sven Barthpascaldra...@googlemail.com Apr,25 2010: Problem with cx25840 and Terratec Grabster AV400 http://patchwork.kernel.org/patch/94960 Sven Barthpascaldra...@googlemail.com Sven, We need a Signed-off-by: for your submitted patch: http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Sign_your_work Note, your patch has an obvious, unintentional white space change for if (std == V4L2_STD_NTSC_M_JP), so could you fix that up and send a new signed off version? Eh... I thought I had superseeded it with the patch from 10th July (mail title: [PATCH] Add support for AUX_PLL on cx2583x chips). It included a Signed-of by from me as well as Acked by from Mike and Andy and I also excluded the whitespace change ^^ Hi Sven, http://www.mail-archive.com/linux-media@vger.kernel.org/msg20296.html So you have. How embarrassing.:} Well... it's a bit hard to keep the overview in this list. ;) I only saw this thread about old patches by pure luck. And thank you for digging up the link, I only had the mail version lying around. [And finally I won't have to patch v4l manually anymore... yippieh! I'm looking forward to 2.6.37 :D (Good that I use a distro (ArchLinux) that has a rolling release style ^^) ] Regards, Sven -- 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: Old patches sent via the Mailing list
Am 18.10.2010 08:15, schrieb Mauro Carvalho Chehab: Em 17-10-2010 21:36, Andy Walls escreveu: On Sun, 2010-10-17 at 19:20 -0200, Mauro Carvalho Chehab wrote: Hi, I did a large effort during this weekend to handle the maximum amount of patches, in order to have them ready for 2.6.37. While there are still some patches marked as NEW at patchwork, and a few pending pull requests (mostly related to more kABI changes), there are still a list of patches that are marked as Under review. Except for 4 patches from me, related to Doc (that I'm keeping in this list just to remind me that I'll need to fix them when I have some time - just some automation stuff at DocBook), all other patches marked as Under review are stuff that I basically depend on others. The last time I sent this list, I was about to travel, and I may have missed some comments, or maybe I may just forgot to update. But I suspect that, for the list bellow, most of them are stuff where the driver maintainer just forgot at limbo. From the list of patches under review, we have: Waiting for new patch, signed, from Sven Barthpascaldra...@googlemail.com Apr,25 2010: Problem with cx25840 and Terratec Grabster AV400 http://patchwork.kernel.org/patch/94960 Sven Barthpascaldra...@googlemail.com Sven, We need a Signed-off-by: for your submitted patch: http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Sign_your_work Note, your patch has an obvious, unintentional white space change for if (std == V4L2_STD_NTSC_M_JP), so could you fix that up and send a new signed off version? Mauro, This patch makes obvious sense to me: don't perform audio register updates on a chip that doesn't have an audio processing block. Sven's approach was based on my recommended approach, after his initial discovery on how to get his audio working. Do we really need an S.O.B for something that appears to be common sense, and wouldn't have been implemented any other way, even if I had implemented it? The original patch were in the middle of a discussion, no proper description, bad whitespacing, etc. It is better to let the patch author to fix those issues, as they learn more about how to submit a patch. Anyway, I agree with you, the patch is obvious, and can proceed without the SOB. I did the usual CodingStyle fixups, put part of your above comment as the patch description, together with your ack and moved it forward. One patch less on my queue ;) Cheers, Mauro Eh... I thought I had superseeded it with the patch from 10th July (mail title: [PATCH] Add support for AUX_PLL on cx2583x chips). It included a Signed-of by from me as well as Acked by from Mike and Andy and I also excluded the whitespace change ^^ Regards, Sven -- 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] Add support for AUX_PLL on cx2583x chips
This adds support for the AUX_PLL in cx2583x chips which is available in
those although the audio part of the chip is not.
The AUX_PLL is used at least by Terratec in their Grabster AV400 device.
Signed-off-by: Sven Barth pascaldra...@googlemail.com
Acked-By: Mike Isely is...@pobox.com
diff -aur v4l-src/linux/drivers/media/video/cx25840//cx25840-audio.c
v4l-build/linux/drivers/media/video/cx25840//cx25840-audio.c
--- v4l-src/linux/drivers/media/video/cx25840//cx25840-audio.c
2009-10-18 21:08:26.497700904 +0200
+++ v4l-build/linux/drivers/media/video/cx25840//cx25840-audio.c
2010-07-09 22:35:31.067718241 +0200
@@ -438,41 +438,45 @@
{
struct cx25840_state *state = to_state(i2c_get_clientdata(client));
- /* assert soft reset */
- cx25840_and_or(client, 0x810, ~0x1, 0x01);
-
- /* stop microcontroller */
- cx25840_and_or(client, 0x803, ~0x10, 0);
-
- /* Mute everything to prevent the PFFT! */
- cx25840_write(client, 0x8d3, 0x1f);
-
- if (state-aud_input == CX25840_AUDIO_SERIAL) {
- /* Set Path1 to Serial Audio Input */
- cx25840_write4(client, 0x8d0, 0x01011012);
-
- /* The microcontroller should not be started for the
-* non-tuner inputs: autodetection is specific for
-* TV audio. */
- } else {
- /* Set Path1 to Analog Demod Main Channel */
- cx25840_write4(client, 0x8d0, 0x1f063870);
- }
+if (!is_cx2583x(state)) {
+ /* assert soft reset */
+ cx25840_and_or(client, 0x810, ~0x1, 0x01);
+
+ /* stop microcontroller */
+ cx25840_and_or(client, 0x803, ~0x10, 0);
+
+ /* Mute everything to prevent the PFFT! */
+ cx25840_write(client, 0x8d3, 0x1f);
+
+ if (state-aud_input == CX25840_AUDIO_SERIAL) {
+ /* Set Path1 to Serial Audio Input */
+ cx25840_write4(client, 0x8d0, 0x01011012);
+
+ /* The microcontroller should not be started for the
+* non-tuner inputs: autodetection is specific for
+* TV audio. */
+ } else {
+ /* Set Path1 to Analog Demod Main Channel */
+ cx25840_write4(client, 0x8d0, 0x1f063870);
+ }
+}
set_audclk_freq(client, state-audclk_freq);
- if (state-aud_input != CX25840_AUDIO_SERIAL) {
- /* When the microcontroller detects the
-* audio format, it will unmute the lines */
- cx25840_and_or(client, 0x803, ~0x10, 0x10);
- }
-
- /* deassert soft reset */
- cx25840_and_or(client, 0x810, ~0x1, 0x00);
-
- /* Ensure the controller is running when we exit */
- if (is_cx2388x(state) || is_cx231xx(state))
- cx25840_and_or(client, 0x803, ~0x10, 0x10);
+if (!is_cx2583x(state)) {
+ if (state-aud_input != CX25840_AUDIO_SERIAL) {
+ /* When the microcontroller detects the
+* audio format, it will unmute the lines */
+ cx25840_and_or(client, 0x803, ~0x10, 0x10);
+ }
+
+ /* deassert soft reset */
+ cx25840_and_or(client, 0x810, ~0x1, 0x00);
+
+ /* Ensure the controller is running when we exit */
+ if (is_cx2388x(state) || is_cx231xx(state))
+ cx25840_and_or(client, 0x803, ~0x10, 0x10);
+}
}
static int get_volume(struct i2c_client *client)
diff -aur v4l-src/linux/drivers/media/video/cx25840//cx25840-core.c
v4l-build/linux/drivers/media/video/cx25840//cx25840-core.c
--- v4l-src/linux/drivers/media/video/cx25840//cx25840-core.c 2010-06-26
17:56:26.238525747 +0200
+++ v4l-build/linux/drivers/media/video/cx25840//cx25840-core.c
2010-07-09 23:28:36.784067005 +0200
@@ -691,6 +691,11 @@
}
cx25840_and_or(client, 0x401, ~0x60, 0);
cx25840_and_or(client, 0x401, ~0x60, 0x60);
+
+/* Don't write into audio registers on cx2583x chips */
+if (is_cx2583x(state))
+ return;
+
cx25840_and_or(client, 0x810, ~0x01, 1);
if (state-radio) {
@@ -849,10 +854,8 @@
state-vid_input = vid_input;
state-aud_input = aud_input;
- if (!is_cx2583x(state)) {
- cx25840_audio_set_path(client);
- input_change(client);
- }
+ cx25840_audio_set_path(client);
+ input_change(client);
if (is_cx2388x(state)) {
/* Audio channel 1 src : Parallel 1 */
@@ -1482,8 +1485,6 @@
struct cx25840_state *state = to_state(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (is_cx2583x(state))
- return -EINVAL;
return set_input(client, state-vid_input, input);
}
@@ -1492,8 +1493,7 @@
struct
Re: Status of the patches under review at LMML (60 patches)
Hi!
On 08.07.2010 05:31, Mike Isely wrote:
These are cx25840 patches and I'm not the maintainer of that module. I
can't really speak to the correctness of the changes. Best I can do is
to try the patch with a few pvrusb2-driven devices here that use the
cx25840 module. I've done that now (HVR-1950 and PVR-USB2 model 24012)
and everything continues to work fine.
I also retested the patch (with the recent v4l changes) and my device
continues to work as expected (using your current snapshot from July,
Mike :) ).
Note, this part of the patch:
int hw_fix = state-pvr150_workaround;
-
- if (std == V4L2_STD_NTSC_M_JP) {
+ if (std == V4L2_STD_NTSC_M_JP) {
/* Japan uses EIAJ audio standard */
cx25840_write(client, 0x808, hw_fix ? 0x2f : 0xf7);
} else if (std == V4L2_STD_NTSC_M_KR) {
is a whitespace-only change which introduces a bogus tab and messes up
the indentation of that opening if-statement. It should probably be
removed from the patch.
I wonder how that came in there... my excuses for this (and also the
removed new line some lines below that).
Other than that, you have my ack:
Acked-By: Mike Iselyis...@pobox.com
-Mike
Hmm... I've read a bit in the wiki about submitting patches and read
that one should sign-off his/her patches... as I didn't do that back
then (as I thought that patch would be open for discussion ^^ - note to
self: add RFC next time), should I resend the patch with a comment and
the sign-off (and excluding the indentation mistake) or should I just
send a sign-off in reference to this patch? Or something else?
Regards,
Sven
--
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: Status of the patches under review at LMML (60 patches)
Hi! Am 06.07.2010 15:06, schrieb Mauro Carvalho Chehab: == Waiting for Mike Iselyis...@isely.net review == Apr,25 2010: Problem with cx25840 and Terratec Grabster AV400 http://patchwork.kernel.org/patch/94960 Is Mike really the maintainer of the cx25840 module and not only of the pvrusb2 one? If he's not the maintainer you should contact the real one, cause I don't think that Mike can help much regarding patches for the cx25840 in that case. Also I might need to adjust the patch cause of the recent changes that happened there the last few months. (I don't know when I'll find time for this...) Regards, Sven -- 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
Problem with cx25840 and Terratec Grabster AV400
Hello together!
I'm the owner of a Terratec Grabster AV400, which is supported by the
pvrusb2 (currently standalone version only). Video works well, but I
have a problem with audio, when I use an unmodified v4l-dvb: the audio
is too slow, as if the bitrate is set to low.
The device contains a cx25837-3 (according to dmesg) and audio routing
has to be set to CX25840_AUDIO_SERIAL.
The problem now is, that this audio route setting is never applied,
because there are (at least) two locations in cx25840-core.c where a
check with is_cx2583x is done.
Locally I've simply disabled that checks (see attached patch) and the
AV400 works as expected now. Of course this can't be the correct
solution for the official v4l. Also I have to apply that patch after
every kernel update (which happens rather often with ArchLinux ^^).
Thus I ask how this situation might be solved so that I can use the
AV400 without patching around in the source of v4l.
Attached:
* dmesg output with unpatched cx25840 module
* my quick dirty patch for cx25840-core.c
Regards,
Sven
usb 1-5: new high speed USB device using ehci_hcd and address 9
pvrusb2: Hardware description: Terratec Grabster AV400
cx25840 4-0044: cx25837-3 found @ 0x88 (pvrusb2_a)
pvrusb2: Attached sub-driver cx25840
pvrusb2: Supported video standard(s) reported available in hardware:
PAL-B/B1/D/D1/G/H/I/K/M/N/Nc/60;NTSC-M/
pvrusb2: Mapping standards mask=0xff
(PAL-B/B1/D/D1/G/H/I/K/M/N/Nc/60;NTSC-M/Mj/443/Mk;SECAM-B/D/G/H/K/K1/L/LC)
pvrusb2: Setting up 28 unique standard(s)
pvrusb2: Set up standard idx=0 name=PAL-B/G
pvrusb2: Set up standard idx=1 name=PAL-D/K
pvrusb2: Set up standard idx=2 name=SECAM-B/G
pvrusb2: Set up standard idx=3 name=SECAM-D/K
pvrusb2: Set up standard idx=4 name=NTSC-M
pvrusb2: Set up standard idx=5 name=NTSC-Mj
pvrusb2: Set up standard idx=6 name=NTSC-443
pvrusb2: Set up standard idx=7 name=NTSC-Mk
pvrusb2: Set up standard idx=8 name=PAL-B
pvrusb2: Set up standard idx=9 name=PAL-B1
pvrusb2: Set up standard idx=10 name=PAL-G
pvrusb2: Set up standard idx=11 name=PAL-H
pvrusb2: Set up standard idx=12 name=PAL-I
pvrusb2: Set up standard idx=13 name=PAL-D
pvrusb2: Set up standard idx=14 name=PAL-D1
pvrusb2: Set up standard idx=15 name=PAL-K
pvrusb2: Set up standard idx=16 name=PAL-M
pvrusb2: Set up standard idx=17 name=PAL-N
pvrusb2: Set up standard idx=18 name=PAL-Nc
pvrusb2: Set up standard idx=19 name=PAL-60
pvrusb2: Set up standard idx=20 name=SECAM-B
pvrusb2: Set up standard idx=21 name=SECAM-D
pvrusb2: Set up standard idx=22 name=SECAM-G
pvrusb2: Set up standard idx=23 name=SECAM-H
pvrusb2: Set up standard idx=24 name=SECAM-K
pvrusb2: Set up standard idx=25 name=SECAM-K1
pvrusb2: Set up standard idx=26 name=SECAM-L
pvrusb2: Set up standard idx=27 name=SECAM-LC
pvrusb2: Initial video standard auto-selected to PAL-B/G
pvrusb2: Device initialization completed successfully.
usb 1-5: firmware: requesting v4l-cx2341x-enc.fw
pvrusb2: registered device video0 [mpeg]
cx25840 4-0044: 0x is not a valid video input!
--- v4l-src/linux/drivers/media/video/cx25840/cx25840-core.c2010-04-24
10:48:56.392367351 +0200
+++ v4l-build/linux/drivers/media/video/cx25840/cx25840-core.c 2010-04-24
14:54:08.797561848 +0200
@@ -849,10 +849,10 @@
state-vid_input = vid_input;
state-aud_input = aud_input;
- if (!is_cx2583x(state)) {
+// if (!is_cx2583x(state)) {
cx25840_audio_set_path(client);
input_change(client);
- }
+// }
if (is_cx2388x(state)) {
/* Audio channel 1 src : Parallel 1 */
@@ -1504,8 +1504,8 @@
struct cx25840_state *state = to_state(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (is_cx2583x(state))
- return -EINVAL;
+/* if (is_cx2583x(state))
+ return -EINVAL;*/
return set_input(client, state-vid_input, input);
}
Re: Problem with cx25840 and Terratec Grabster AV400
On 24.04.2010 19:13, Mike Isely wrote: Actually the support in the pvrusb2 driver was never really completed. But since I don't have a sample of the hardware here I went on ahead and merged what was there so that it could get exposure and the remaining problems sorted out. -Mike Hi! Although you never really completed that support for the AV400 it runs pretty well once you've touched the cx25840 source. I'm using it for months now and it runs better than it did with Windows (I sometimes had troubles with audio there which led to an out of sync audio track). I wrote the last mail, because I want to sort out why the cx25837 chip in my device is behaving differently than expected by the corresponding driver and to remove the need to patch the v4l sources manually. Once I don't need to fear that the next system update breaks the device again (because cx25840.ko is overwritten), I'm more then willed to help you to complete the support for my device in your driver (feature testing, etc). Regards, Sven PS: Did you read my mail from last December? http://www.isely.net/pipermail/pvrusb2/2009-December/002716.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with cx25840 and Terratec Grabster AV400
Hi! On 24.04.2010 22:24, Mike Isely wrote: On Sat, 24 Apr 2010, Sven Barth wrote: Hi! Although you never really completed that support for the AV400 it runs pretty well once you've touched the cx25840 source. I'm using it for months now and it runs better than it did with Windows (I sometimes had troubles with audio there which led to an out of sync audio track). Unfortunately I can't really say it is supported in the pvrusb2 driver until it actually works well enough that a user doesn't have to hack driver source (pvrusb2 or otherwise). Otherwise I'm just going to get inundated with help requests for this. Not having a sample of the device here I'm handicapped from debugging such issues. I don't want to have this hacking as much as you do. But currently it's the only way that works for me (I'm really glad that it has come that far ^^)... I'll try to help here as good as I can (and time permits) to solve this issue. I've just made a change to the pvrusb2 driver to allow for the ability to mark a piece of hardware (such as this device) as experimental. Such devices will generate a warning in the kernel log upon initialization. The experimental marker doesn't impact the ability to use the device; it just triggers the warning message. Once we know the device is working acceptably well enough, the marker can be turned off. This should help avoid misleading others about whether or not the pvrusb2 driver fully supports a particular piece of hardware. No offense intended, but do you really think that people will read that? Normal users (using Ubuntu, etc) don't really care whether their device is marked as experimental or not... they just want it to work and thus can go to great lengths to disturb the developers working on their driver... PS: Did you read my mail from last December? http://www.isely.net/pipermail/pvrusb2/2009-December/002716.html Yeah, I saw it back then, and then I probably got distracted away :-( I know that problem pretty well. ^^ I was only curious. The key issue is that your hardware doesn't seem to work until you make those two changes to the v4l-dvb cx25840 driver. Obviously one can't just make those changes without understanding the implications for other users of the driver. I (or someone expert at the cx25840 module) needs to study that patch and understand what is best to do for the driver. -Mike It would be interesting to know why the v4l devs disabled the audio routing for cx2583x chips and whether it was intended that a cx25837 chip gets the same treatment as a e.g. cx25836. And those implications you're talking about is the reason why I wrote here: I want to check whether there is a better or more correct way than to disable those checks (it works here, because I have only that one device that contains a cx2583x chip...). Just a thought: can it be that my chip's audio routing isn't set to the correct value after initialization and thus it needs to be set at least once, while all other chips default to a working routing after initialization? Could be a design mistake done by Terratec... Regards, Sven -- 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
