Re: [PATCH] uvcvideo: Don't call vb2 mmap and get_unmapped_area with queue lock held
Bjørn Mork writes: > Laurent Pinchart writes: > >> Bjørn, does this fix the circular locking dependency you have reported in >> "[v3.19-rc7] possible circular locking dependency in uvc_queue_streamoff" ? >> The report mentions involves locks, so I'm not 100% this patch will fix the >> issue. > > Sorry, I forgot all about that report after firing it off... Should > have followed it up with some more details. > > Grepping my logs now I cannot find this warning at all after the one I > reported. I see it once before (while running 3.19-rc6). So it is > definitely not easily reproducible. And I have a bad feeling the > trigger might involve completely unrelated USB issues... > > In any case, thanks for the patch. I will test it for a while and let > you know if the same warning shows ut with it. But based on the rare > occurence, I don't think I ever will be able to positively confirm that > the warning is gone. FWIW, I have not seen the warning after applying this patch, so it appears to fix the problem. Thanks. If I'm wrong, then I'm sure Murphy will tell us as soon as I send this email :-) Bjørn -- 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] uvcvideo: Don't call vb2 mmap and get_unmapped_area with queue lock held
Laurent Pinchart writes: > Bjørn, does this fix the circular locking dependency you have reported in > "[v3.19-rc7] possible circular locking dependency in uvc_queue_streamoff" ? > The report mentions involves locks, so I'm not 100% this patch will fix the > issue. Sorry, I forgot all about that report after firing it off... Should have followed it up with some more details. Grepping my logs now I cannot find this warning at all after the one I reported. I see it once before (while running 3.19-rc6). So it is definitely not easily reproducible. And I have a bad feeling the trigger might involve completely unrelated USB issues... In any case, thanks for the patch. I will test it for a while and let you know if the same warning shows ut with it. But based on the rare occurence, I don't think I ever will be able to positively confirm that the warning is gone. Bjørn -- 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
[v3.19-rc7] possible circular locking dependency in uvc_queue_streamoff
FYI, in case this is of interest:
==
[ INFO: possible circular locking dependency detected ]
3.19.0-rc7+ #297 Tainted: GW
---
mpv/15932 is trying to acquire lock:
(s_active#37){.+}, at: []
kernfs_remove_by_name_ns+0x6b/0x87
but task is already holding lock:
(&queue->mutex){+.+.+.}, at: []
uvc_queue_streamoff+0x24/0x48 [uvcvideo]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&queue->mutex){+.+.+.}:
[] lock_acquire+0x149/0x191
[] mutex_lock_nested+0x6b/0x39e
[] uvc_queue_mmap+0x24/0x48 [uvcvideo]
[] uvc_v4l2_mmap+0x42/0x49 [uvcvideo]
[] v4l2_mmap+0x43/0x83 [videodev]
[] mmap_region+0x26f/0x44b
[] do_mmap_pgoff+0x2c2/0x32b
[] vm_mmap_pgoff+0x7a/0xad
[] SyS_mmap_pgoff+0x162/0x195
[] SyS_mmap+0x16/0x22
[] system_call_fastpath+0x12/0x17
-> #1 (&mm->mmap_sem){++}:
[] lock_acquire+0x149/0x191
[] might_fault+0x81/0xa4
[] kernfs_fop_write+0xb7/0x149
[] vfs_write+0xa2/0x122
[] SyS_write+0x50/0x85
[] system_call_fastpath+0x12/0x17
-> #0 (s_active#37){.+}:
[] __lock_acquire+0xaf0/0xe67
[] lock_acquire+0x149/0x191
[] __kernfs_remove+0x14d/0x2da
[] kernfs_remove_by_name_ns+0x6b/0x87
[] kernfs_remove_by_name+0xb/0xd
[] sysfs_unmerge_group+0x36/0x4c
[] rpm_sysfs_remove+0x14/0x16
[] dpm_sysfs_remove+0x2d/0x52
[] device_del+0x42/0x1f8
[] device_unregister+0x44/0x50
[] usb_remove_ep_devs+0x1c/0x29 [usbcore]
[] remove_intf_ep_devs+0x2f/0x45 [usbcore]
[] usb_set_interface+0x22f/0x2f3 [usbcore]
[] uvc_video_enable+0x31/0x14c [uvcvideo]
[] uvc_stop_streaming+0x24/0x50 [uvcvideo]
[] __vb2_queue_cancel+0x25/0x143 [videobuf2_core]
[] vb2_internal_streamoff+0x30/0x8f [videobuf2_core]
[] vb2_streamoff+0x3b/0x43 [videobuf2_core]
[] uvc_queue_streamoff+0x2f/0x48 [uvcvideo]
[] uvc_ioctl_streamoff+0x44/0x57 [uvcvideo]
[] v4l_streamoff+0x15/0x17 [videodev]
[] __video_do_ioctl+0x170/0x246 [videodev]
[] video_usercopy+0x2b4/0x589 [videodev]
[] video_ioctl2+0x10/0x12 [videodev]
[] v4l2_ioctl+0x78/0xf8 [videodev]
[] do_vfs_ioctl+0x47f/0x4c7
[] SyS_ioctl+0x4e/0x7f
[] system_call_fastpath+0x12/0x17
other info that might help us debug this:
Chain exists of:
s_active#37 --> &mm->mmap_sem --> &queue->mutex
Possible unsafe locking scenario:
CPU0CPU1
lock(&queue->mutex);
lock(&mm->mmap_sem);
lock(&queue->mutex);
lock(s_active#37);
*** DEADLOCK ***
2 locks held by mpv/15932:
#0: (&streaming->mutex){+.+.+.}, at: []
uvc_ioctl_streamoff+0x34/0x57 [uvcvideo]
#1: (&queue->mutex){+.+.+.}, at: []
uvc_queue_streamoff+0x24/0x48 [uvcvideo]
stack backtrace:
CPU: 1 PID: 15932 Comm: mpv Tainted: GW 3.19.0-rc7+ #297
Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
81df0580 8801be25f7c8 813d6111
81e16010 8801be25f818 813d3e26 8801be25f808
8801be16c990 8801be16d148 8801be16c990 8801be16d148
Call Trace:
[] dump_stack+0x4c/0x65
[] print_circular_bug+0x1f8/0x209
[] __lock_acquire+0xaf0/0xe67
[] ? mark_lock+0x2d/0x212
[] lock_acquire+0x149/0x191
[] ? kernfs_remove_by_name_ns+0x6b/0x87
[] __kernfs_remove+0x14d/0x2da
[] ? kernfs_remove_by_name_ns+0x6b/0x87
[] ? kernfs_find_ns+0xbe/0x100
[] kernfs_remove_by_name_ns+0x6b/0x87
[] kernfs_remove_by_name+0xb/0xd
[] sysfs_unmerge_group+0x36/0x4c
[] rpm_sysfs_remove+0x14/0x16
[] dpm_sysfs_remove+0x2d/0x52
[] device_del+0x42/0x1f8
[] ? mark_held_locks+0x54/0x76
[] device_unregister+0x44/0x50
[] usb_remove_ep_devs+0x1c/0x29 [usbcore]
[] remove_intf_ep_devs+0x2f/0x45 [usbcore]
[] usb_set_interface+0x22f/0x2f3 [usbcore]
[] uvc_video_enable+0x31/0x14c [uvcvideo]
[] uvc_stop_streaming+0x24/0x50 [uvcvideo]
[] __vb2_queue_cancel+0x25/0x143 [videobuf2_core]
[] vb2_internal_streamoff+0x30/0x8f [videobuf2_core]
[] vb2_streamoff+0x3b/0x43 [videobuf2_core]
[] uvc_queue_streamoff+0x2f/0x48 [uvcvideo]
[] uvc_ioctl_streamoff+0x44/0x57 [uvcvideo]
[] v4l_streamoff+0x15/0x17 [videodev]
[] __video_do_ioctl+0x170/0x246 [videodev]
[] video_usercopy+0x2b4/0x589 [videodev]
[] ? v4l2_is_known_ioctl+0x20/0x20 [videodev]
[] ? native_sched_clock+0x35/0x37
[] ? sched_clock_local+0x12/0x75
[] ? sched_clock_cpu+0x9d/0xb6
[] video_ioctl2+0x10/0x12 [videodev]
[] v4l2_ioctl+0x78/0xf8 [videodev]
[] do_vfs_ioctl+0x47f/0x4c7
[] ? rcu_read_unlock+0x56/0x5f
[] ? __fget+0x6d/0x78
[] ? __fget_light+0x45/0x52
[] SyS_ioctl+0x4e/0x7f
[] system_call_fastpath+0x12/0x17
--
T
Re: [PATCH 11/11] libdvbv5: fix PMT parser
André Roth writes: > On Tue, 25 Mar 2014 21:51:49 +0100 > Bjørn Mork wrote: > >> > - * Copyright (c) 2011-2012 - Mauro Carvalho Chehab >> > - * Copyright (c) 2012 - Andre Roth >> > + * Copyright (c) 2013 - Andre Roth >> > * >> > * This program is free software; you can redistribute it and/or >> > * modify it under the terms of the GNU General Public License >> >> This copyright change looked strange to me. Accidental deletion? > > Hi Bjørn, > > thanks for pointing this out. > originally I was adding mauro to my dvb files as the "owner" of dvb in > v4l. mauro then stated on some files that this was not his code and as > the PMT is originally my code, I corrected this here. > > @mauro: please correct me if I'm wrong... Correcting the copyright is of course fine, but I think it would be good to document that in the patch description so people like me don't end up asking unnecessary questions :-) > I'm a bit confused about the copyright year and author. Is this still > needed in the age of git ? What is the policy for them ? IANAL. But looking at this from a practical point of view, I believe that this info is useful whether it is required or not. Reading the copyright owner(s) out of a git log can be a lot of work, and it isn't necessariliy correct either - your copyright can be assigned to e.g. your employer or to the FSF. It's also difficult to judge who of many contributors have made changes big enough to make them copyright owners. Some changes can be small in code size but still major, while other changes can touch almost every line but still only be a minor editorial fixup. And why is it useful who owns a copyright and when the copyrighted work was produced? If relicensing your code ever becomes a question, then we need to know who to contact. You might think that relicensing isn't going to happen. But there are real world examples where code has ended up beeing linked to libraries with a GPL conflicting license, and therefore needed an exception. The classical example is linking with openssl. And the year is useful because copyright expires some years (depending on country of origin, but typical 50) after the authors death. You write code that will live forever, right? :-) Bjørn -- 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 11/11] libdvbv5: fix PMT parser
André Roth writes: > --- a/lib/libdvbv5/descriptors/pmt.c > +++ b/lib/libdvbv5/descriptors/pmt.c > @@ -1,6 +1,5 @@ > /* > - * Copyright (c) 2011-2012 - Mauro Carvalho Chehab > - * Copyright (c) 2012 - Andre Roth > + * Copyright (c) 2013 - Andre Roth > * > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License This copyright change looked strange to me. Accidental deletion? Bjørn -- 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: Bug#719623: linux-image-3.10-2-amd64: kernel panic on inserting DVB-T stick
6.863906] [] ? cpu_startup_entry+0x10d/0x187 [ 846.863906] [] ? start_kernel+0x3e8/0x3f3 [ 846.863906] [] ? repair_env_string+0x54/0x54 [ 846.863906] [] ? x86_64_start_kernel+0xf2/0xfd [ 846.863906] Code: 25 09 00 00 c6 83 da 08 00 00 03 8b 45 54 48 01 83 b6 08 00 00 8b 45 50 48 01 83 db 08 00 00 8b 4d 18 69 c1 ff ff 00 00 03 4d 14 <48> f7 f1 89 83 a8 09 00 00 e9 68 fe ff ff 48 8b 7f 10 e8 79 92 [ 846.863906] RIP [] smsdvb_onresponse+0x264/0xa86 [smsdvb] [ 846.863906] RSP Reported-by: Johannes Rohr Reference: http://bugs.debian.org/719623 Cc: Mauro Carvalho Chehab Signed-off-by: Bjørn Mork --- drivers/media/common/siano/smsdvb-main.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/common/siano/smsdvb-main.c b/drivers/media/common/siano/smsdvb-main.c index 0862622..63676a8 100644 --- a/drivers/media/common/siano/smsdvb-main.c +++ b/drivers/media/common/siano/smsdvb-main.c @@ -276,7 +276,8 @@ static void smsdvb_update_per_slices(struct smsdvb_client_t *client, /* Legacy PER/BER */ tmp = p->ets_packets * 65535; - do_div(tmp, p->ts_packets + p->ets_packets); + if (p->ts_packets + p->ets_packets) + do_div(tmp, p->ts_packets + p->ets_packets); client->legacy_per = tmp; } -- 1.7.10.4
Re: [GIT PULL for v3.11-rc1] media patches for v3.11
Mauro Carvalho Chehab writes: > mode change 100755 => 100644 lib/build_OID_registry > mode change 100755 => 100644 scripts/Lindent > mode change 100755 => 100644 scripts/bloat-o-meter > mode change 100755 => 100644 scripts/checkincludes.pl > mode change 100755 => 100644 scripts/checkkconfigsymbols.sh > mode change 100755 => 100644 scripts/checkpatch.pl > mode change 100755 => 100644 scripts/checkstack.pl > mode change 100755 => 100644 scripts/checksyscalls.sh > mode change 100755 => 100644 scripts/checkversion.pl > mode change 100755 => 100644 scripts/cleanfile > mode change 100755 => 100644 scripts/cleanpatch > mode change 100755 => 100644 scripts/coccicheck > mode change 100755 => 100644 scripts/config > mode change 100755 => 100644 scripts/decodecode > mode change 100755 => 100644 scripts/depmod.sh > mode change 100755 => 100644 scripts/diffconfig > mode change 100755 => 100644 scripts/extract-ikconfig > mode change 100755 => 100644 scripts/extract-vmlinux > mode change 100755 => 100644 scripts/get_maintainer.pl > mode change 100755 => 100644 scripts/gfp-translate > mode change 100755 => 100644 scripts/headerdep.pl > mode change 100755 => 100644 scripts/headers.sh > mode change 100755 => 100644 scripts/kconfig/check.sh > mode change 100755 => 100644 scripts/kconfig/merge_config.sh > mode change 100755 => 100644 scripts/kernel-doc > mode change 100755 => 100644 scripts/makelst > mode change 100755 => 100644 scripts/mkcompile_h > mode change 100755 => 100644 scripts/mkuboot.sh > mode change 100755 => 100644 scripts/namespace.pl > mode change 100755 => 100644 scripts/package/mkspec > mode change 100755 => 100644 scripts/patch-kernel > mode change 100755 => 100644 scripts/recordmcount.pl > mode change 100755 => 100644 scripts/setlocalversion > mode change 100755 => 100644 scripts/show_delta > mode change 100755 => 100644 scripts/sign-file > mode change 100755 => 100644 scripts/tags.sh > mode change 100755 => 100644 scripts/ver_linux > mode change 100755 => 100644 tools/hv/hv_get_dhcp_info.sh > mode change 100755 => 100644 tools/hv/hv_get_dns_info.sh > mode change 100755 => 100644 tools/hv/hv_set_ifconfig.sh > mode change 100755 => 100644 tools/nfsd/inject_fault.sh > mode change 100755 => 100644 tools/perf/python/twatch.py > mode change 100755 => 100644 > tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/EventClass.py > mode change 100755 => 100644 > tools/perf/scripts/python/bin/net_dropmonitor-record > mode change 100755 => 100644 > tools/perf/scripts/python/bin/net_dropmonitor-report > mode change 100755 => 100644 tools/perf/scripts/python/net_dropmonitor.py > mode change 100755 => 100644 tools/perf/util/PERF-VERSION-GEN > mode change 100755 => 100644 tools/perf/util/generate-cmdlist.sh > mode change 100755 => 100644 tools/power/cpupower/utils/version-gen.sh > mode change 100755 => 100644 tools/testing/ktest/compare-ktest-sample.pl > mode change 100755 => 100644 tools/testing/ktest/ktest.pl You didn't really mean to do that, did you? Bjørn -- 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: HD Capture Card (HDMI and Component) output raw pixels
James Board writes: > You are right. According to your numbers, this card can't work. So > why would BlackMagic design an HDMI capture card with only one PCIe > lane if it can't possibly work? It must work somehow. I must be > missing some crucial piece of information. > > The card doesn't support hardware encoding, right? If so, raw pixels > are the only output. Maybe the card uses more than one PCIe lane? > What makes you think the card only uses a single lane? http://www.blackmagicdesign.com/products/intensity/techspecs/ says so. It also says HD Format Support: 1080i50, 1080i59.94, 1080i60, 1080p23.98, 1080p24, 1080p25, 1080p29.97, 1080p30, 720p50, 720p59.94 and 720p60. which makes the 1080p50 calculation a bit irrelevant. > Are they using lossless compression to get the raw pixels data rate > under 200-250 MB/sec, which is the PCIe speed? None of the supported formats need more than ~180 MB/sec. Bjørn -- 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 stable < v3.7] media mantis: fix silly crash case
Hello, Please apply mainline commit e1d45ae to any maintained stable kernel prior to v3.7. I just hit this bug on a Debian 3.2.41-2+deb7u2 kernel: May 19 06:52:54 canardo kernel: [ 49.013774] BUG: unable to handle kernel NULL pointer dereference at 0308 May 19 06:52:54 canardo kernel: [ 49.017735] IP: [] dvb_unregister_frontend+0x10/0xf4 [dvb_core] May 19 06:52:54 canardo kernel: [ 49.017735] PGD 0 May 19 06:52:54 canardo kernel: [ 49.017735] Oops: [#1] SMP May 19 06:52:54 canardo kernel: [ 49.017735] CPU 2 May 19 06:52:54 canardo kernel: [ 49.017735] Modules linked in: tda10023 tda10021 ir_lirc_codec lirc_dev ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder mantis(+) ir_rc6_decoder snd_pcm mantis_core dvb_core ir_rc5_decoder ir_nec_decoder io_edgeport radeon snd_page_alloc snd_timer rc_core ttm snd usbserial soundcore serio_raw drm_kms_helper acpi_cpufreq drm mperf i2c_i801 power_supply i2c_algo_bit iTCO_wdt pcspkr joydev coretemp iTCO_vendor_support evdev asus_atk0110 i2c_core button processor thermal_sys ext3 mbcache jbd dm_mod raid1 md_mod microcode usbhid hid sg sd_mod crc_t10dif mptsas ata_generic scsi_transport_sas mptscsih firewire_ohci uhci_hcd pata_jmicron ahci libahci mptbase atl1 mii libata ehci_hcd firewire_core crc_itu_t scsi_mod e1000e usbcore usb_common [last unloaded: scsi_wait_scan] May 19 06:52:54 canardo kernel: [ 49.017735] May 19 06:52:54 canardo kernel: [ 49.017735] Pid: 612, comm: modprobe Not tainted 3.2.0-4-amd64 #1 Debian 3.2.41-2+deb7u2 System manufacturer P5K/P5K May 19 06:52:54 canardo kernel: [ 49.017735] RIP: 0010:[] [] dvb_unregister_frontend+0x10/0xf4 [dvb_core] May 19 06:52:54 canardo kernel: [ 49.017735] RSP: 0018:88021274bcc8 EFLAGS: 00010246 May 19 06:52:54 canardo kernel: [ 49.017735] RAX: 0023 RBX: 880213571000 RCX: 8802135d3208 May 19 06:52:54 canardo kernel: [ 49.017735] RDX: 0022 RSI: 880213078ac0 RDI: May 19 06:52:54 canardo kernel: [ 49.017735] RBP: R08: 0011 R09: 0011 May 19 06:52:54 canardo kernel: [ 49.017735] R10: R11: R12: May 19 06:52:54 canardo kernel: [ 49.017735] R13: 8802135714a0 R14: 880213571838 R15: 880213571058 May 19 06:52:54 canardo kernel: [ 49.017735] FS: 7f03b3934700() GS:88021fd0() knlGS: May 19 06:52:54 canardo kernel: [ 49.017735] CS: 0010 DS: ES: CR0: 8005003b May 19 06:52:54 canardo kernel: [ 49.017735] CR2: 0308 CR3: 000214969000 CR4: 06e0 May 19 06:52:54 canardo kernel: [ 49.017735] DR0: DR1: DR2: May 19 06:52:54 canardo kernel: [ 49.017735] DR3: DR6: 0ff0 DR7: 0400 May 19 06:52:54 canardo kernel: [ 49.017735] Process modprobe (pid: 612, threadinfo 88021274a000, task 8802125d2970) May 19 06:52:54 canardo kernel: [ 49.017735] Stack: May 19 06:52:54 canardo kernel: [ 49.017735] 880213571080 81072f0e 880213571000 a03ba000 May 19 06:52:54 canardo kernel: [ 49.017735] 8802135714a0 8104be19 880213571410 880213571000 May 19 06:52:54 canardo kernel: [ 49.017735] 880213571410 a03ffd6f 880213571790 880213571850 May 19 06:52:54 canardo kernel: [ 49.017735] Call Trace: May 19 06:52:54 canardo kernel: [ 49.017735] [] ? __symbol_put+0x29/0x2e May 19 06:52:54 canardo kernel: [ 49.017735] [] ? tasklet_kill+0x4a/0x60 May 19 06:52:54 canardo kernel: [ 49.017735] [] ? mantis_dvb_init+0x3ac/0x402 [mantis_core] May 19 06:52:54 canardo kernel: [ 49.017735] [] ? mantis_pci_probe+0x173/0x270 [mantis] May 19 06:52:54 canardo kernel: [ 49.017735] [] ? local_pci_probe+0x39/0x68 May 19 06:52:54 canardo kernel: [ 49.017735] [] ? pci_device_probe+0xcd/0xfa May 19 06:52:54 canardo kernel: [ 49.017735] [] ? driver_probe_device+0xa8/0x138 May 19 06:52:54 canardo kernel: [ 49.017735] [] ? __driver_attach+0x4f/0x6f May 19 06:52:54 canardo kernel: [ 49.017735] [] ? driver_probe_device+0x138/0x138 May 19 06:52:54 canardo kernel: [ 49.017735] [] ? bus_for_each_dev+0x4f/0x7a May 19 06:52:54 canardo kernel: [ 49.017735] [] ? bus_add_driver+0xa5/0x1f5 May 19 06:52:54 canardo kernel: [ 49.017735] [] ? mantis_pci_probe+0x270/0x270 [mantis] May 19 06:52:54 canardo kernel: [ 49.017735] [] ? driver_register+0x8d/0xf5 May 19 06:52:54 canardo kernel: [ 49.017735] [] ? mantis_pci_probe+0x270/0x270 [mantis] May 19 06:52:54 canardo kernel: [ 49.017735] [] ? __pci_register_driver+0x4d/0xb6 May 19 06:52:54 canardo kernel: [ 49.017735] [] ? mantis_pci_probe+0x270/0x270 [mantis] May 19 06:52:54 canardo kernel: [ 49.017735] [] ? do_one_initcall+0x75/0x12c May 19 06:52:54 canardo kernel: [ 49.017735] [] ? sys_i
Re: [PATCH 4/6] siano: remove the remaining CamelCase compliants
Mauro Carvalho Chehab writes:
> Remove the remaining CamelCase checkpatch.pl compliants.
> There are still a few left, but those are due to USB and
> DVB APIs.
[..]
> @@ -840,31 +840,31 @@ int smscore_configure_board(struct smscore_device_t
> *coredev)
> }
>
> if (board->mtu) {
> - struct sms_msg_data MtuMsg;
> + struct sms_msg_data mtu_msg;
> sms_debug("set max transmit unit %d", board->mtu);
>
> - MtuMsg.x_msg_header.msg_src_id = 0;
> - MtuMsg.x_msg_header.msg_dst_id = HIF_TASK;
> - MtuMsg.x_msg_header.msg_flags = 0;
> - MtuMsg.x_msg_header.msg_type = MSG_SMS_SET_MAX_TX_MSG_LEN_REQ;
> - MtuMsg.x_msg_header.msg_length = sizeof(MtuMsg);
> - MtuMsg.msgData[0] = board->mtu;
> + mtu_msg.x_msg_header.msg_src_id = 0;
> + mtu_msg.x_msg_header.msg_dst_id = HIF_TASK;
> + mtu_msg.x_msg_header.msg_flags = 0;
> + mtu_msg.x_msg_header.msg_type = MSG_SMS_SET_MAX_TX_MSG_LEN_REQ;
> + mtu_msg.x_msg_header.msg_length = sizeof(mtu_msg);
> + mtu_msg.msg_data[0] = board->mtu;
>
Ah, right. Why don't you just squash patch 1 and 4 together, reducing
the set with about the size of patch 4, and making all this somewhat
more meaningful?
Tounching the exact same lines twice in the same patchset, doing the
exact same type of cleanup, does *not* help review.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] siano: get rid of CammelCase from smscoreapi.h
Mauro Carvalho Chehab writes:
> It is almost impossible to see a compliant with checkpatch.pl
> on those Siano drivers, as there are simply too much violations
> on it. So, now that a big change was done, the better is to
> cleanup the checkpatch compliants.
>
> Let's first replace all CammelCase symbols found at smscoreapi.h
> using camel_case namespace. That removed 144 checkpatch.pl
> compliants on this file. Of course, the other files need to be
> fixed accordingly.
[..]
> @@ -840,14 +840,14 @@ int smscore_configure_board(struct smscore_device_t
> *coredev)
> }
>
> if (board->mtu) {
> - struct SmsMsgData_ST MtuMsg;
> + struct sms_msg_data MtuMsg;
> sms_debug("set max transmit unit %d", board->mtu);
>
> - MtuMsg.xMsgHeader.msgSrcId = 0;
> - MtuMsg.xMsgHeader.msgDstId = HIF_TASK;
> - MtuMsg.xMsgHeader.msgFlags = 0;
> - MtuMsg.xMsgHeader.msgType = MSG_SMS_SET_MAX_TX_MSG_LEN_REQ;
> - MtuMsg.xMsgHeader.msgLength = sizeof(MtuMsg);
> + MtuMsg.x_msg_header.msg_src_id = 0;
> + MtuMsg.x_msg_header.msg_dst_id = HIF_TASK;
> + MtuMsg.x_msg_header.msg_flags = 0;
> + MtuMsg.x_msg_header.msg_type = MSG_SMS_SET_MAX_TX_MSG_LEN_REQ;
> + MtuMsg.x_msg_header.msg_length = sizeof(MtuMsg);
> MtuMsg.msgData[0] = board->mtu;
>
> coredev->sendrequest_handler(coredev->context, &MtuMsg,
etc. This didn't help one bit, did it? There are exacly the same
number of CamelCased lines here as before your patch. Why is that?
Bjørn
--
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 V1 7/8] smi2021: Add smi2021_bl.c
Jon Arne Jørgensen writes:
> This is the smi2021-bootloader module.
> This module will upload the firmware for the different somagic devices.
I really don't understand why you want to make that a separate module.
Building both the bootlader driver and the real driver into the same
module will make sure that either both or none are available, document
the relationship to the end user, and allow you to tell the user that
firmware files may be needed for the real driver by using the
MODULE_FIRMWARE macro (which you should do, IMHO).
> +static unsigned int firmware_version;
> +module_param(firmware_version, int, 0644);
> +MODULE_PARM_DESC(firmware_version,
> + "Firmware version to be uploaded to device\n"
> + "if there are more than one firmware present");
> +
> +struct usb_device_id smi2021_bootloader_id_table[] = {
> + { USB_DEVICE(0x1c88, 0x0007) },
> + { }
> +};
> +
> +struct smi2021_firmware {
> + int id;
> + const char *name;
> + int found;
> +};
> +
> +struct smi2021_firmware available_fw[] = {
> + {
> + .id = 0x3c,
> + .name = "smi2021_3c.bin",
> + },
> + {
> + .id = 0x3e,
> + .name = "smi2021_3e.bin",
> + },
> + {
> + .id = 0x3f,
> + .name = "smi2021_3f.bin",
> + }
> +};
How does the user know which firmware to select? Will any of them work,
or are they device specific? Either way I believe you should publish all
three names using MODULE_FIRMWARE.
> +static int smi2021_load_firmware(struct usb_device *udev,
> + const struct firmware *firmware)
> +{
> + int i, size, rc = 0;
> + u8 *chunk;
> + u16 ack = 0x;
> +
> + if (udev == NULL)
> + goto end_out;
Is this possible?
> + size = FIRMWARE_CHUNK_SIZE + FIRMWARE_HEADER_SIZE;
> + chunk = kzalloc(size, GFP_KERNEL);
> + chunk[0] = 0x05;
> + chunk[1] = 0xff;
> +
> + if (chunk == NULL) {
This on the other hand, will happen. But you have already oopsed when
you test it here...
Bjørn
--
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 V1 5/8] smi2021: Add smi2021_video.c
Hans Verkuil writes:
>> +/*
>> + *
>> + * The device delivers data in chunks of 0x400 bytes.
>> + * The four first bytes is a magic header to identify the chunks.
>> + * 0xaa 0xaa 0x00 0x00 = saa7113 Active Video Data
>> + * 0xaa 0xaa 0x00 0x01 = PCM - 24Bit 2 Channel audio data
>> + */
>> +static void process_packet(struct smi2021_dev *dev, u8 *p, int len)
>> +{
>> +int i;
>> +u32 *header;
>> +
>> +if (len % 0x400 != 0) {
>> +printk_ratelimited(KERN_INFO "smi2021::%s: len: %d\n",
>> +__func__, len);
>> +return;
>> +}
>> +
>> +for (i = 0; i < len; i += 0x400) {
>> +header = (u32 *)(p + i);
>> +switch (__cpu_to_be32(*header)) {
>
> That's not right. You probably mean __be32_to_cpu, that makes more sense.
>
>> +case 0x: {
>> +parse_video(dev, p+i+4, 0x400-4);
>> +break;
>> +}
>> +case 0x0001: {
>> +smi2021_audio(dev, p+i+4, 0x400-4);
>> +break;
>> +}
This could be just me, but I would have done it like this to take
advantage of compile time constant conversions (and also dropping the
noisy extra {}s):
switch (*header) {
case cpu_to_be32(0x):
parse_video(dev, p+i+4, 0x400-4);
break;
case cpu_to_be32(0x0001):
smi2021_audio(dev, p+i+4, 0x400-4);
break;
..
>From the name of the function I assume the difference may actually be
measurable here if this runs for every processed packet.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.7] [media] mantis: Terratec Cinergy C PCI HD (CI)
Manu Abraham writes: > Terratec Cinregy C is VP-2033 and not VP-2040. Can you please enlighten me on how to tell this difference? I have two of these cards: bjorn@canardo:~$ lspci -vvnns 05:00 05:00.0 Multimedia controller [0480]: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] [1822:4e35] (rev 01) Subsystem: TERRATEC Electronic GmbH Device [153b:1178] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- GSI 16 (level, low) -> IRQ 16 [ 35.847869] DVB: registering new adapter (Mantis DVB adapter) [ 37.358998] DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... [ 37.359079] Mantis :05:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 37.607414] DVB: registering new adapter (Mantis DVB adapter) [ 38.486159] DVB: registering adapter 1 frontend 0 (Philips TDA10023 DVB-C)... But as both the VP-2033 and VP-2040 code support both TDA10021 and TDA10023 there is obviously some other difference between these. Bridge version maybe? Or something else? Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.7] [media] mantis: Terratec Cinergy C PCI HD (CI)
Mauro Carvalho Chehab writes:
> Hmm... there's something wrong: this would be the revert patch, as produced
> by git revert:
>
> diff --git a/drivers/media/pci/mantis/mantis_cards.c
> b/drivers/media/pci/mantis/mantis_cards.c
> index 0207d1f..095cf3a 100644
> --- a/drivers/media/pci/mantis/mantis_cards.c
> +++ b/drivers/media/pci/mantis/mantis_cards.c
> @@ -275,7 +275,7 @@ static struct pci_device_id mantis_pci_table[] = {
> MAKE_ENTRY(TWINHAN_TECHNOLOGIES, MANTIS_VP_2033_DVB_C, &vp2033_config),
> MAKE_ENTRY(TWINHAN_TECHNOLOGIES, MANTIS_VP_2040_DVB_C, &vp2040_config),
> MAKE_ENTRY(TECHNISAT, CABLESTAR_HD2, &vp2040_config),
> - MAKE_ENTRY(TERRATEC, CINERGY_C, &vp2040_config),
> + MAKE_ENTRY(TERRATEC, CINERGY_C, &vp2033_config),
> MAKE_ENTRY(TWINHAN_TECHNOLOGIES, MANTIS_VP_3030_DVB_T, &vp3030_config),
> { }
> };
> diff --git a/drivers/media/pci/mantis/mantis_core.c
> b/drivers/media/pci/mantis/mantis_core.c
> index 684d906..22524a8 100644
> --- a/drivers/media/pci/mantis/mantis_core.c
> +++ b/drivers/media/pci/mantis/mantis_core.c
> @@ -121,7 +121,7 @@ static void mantis_load_config(struct mantis_pci *mantis)
> mantis->hwconfig = &vp2033_mantis_config;
> break;
> case MANTIS_VP_2040_DVB_C: /* VP-2040 */
> - case CINERGY_C: /* VP-2040 clone */
> + case TERRATEC_CINERGY_C_PCI:/* VP-2040 clone */
> case TECHNISAT_CABLESTAR_HD2:
> mantis->hwconfig = &vp2040_mantis_config;
> break;
>
> There's something wrong there: the comments at "mantis_core", before this
> patch, is saying that TERRATEC_CINERGY_C_PCI is a VP-2040 clone.
>
> That doesn't look right: this card is either a VP-2033 clone (as stated on
> mantis_cards), or a VP-2040 (as stated on mantis_core).
Just delete the whole mantis_core.c file. It has never been built in
the in-kernel driver. See, no reference to it at all:
bjorn@nemi:/usr/local/src/git/linux$ cat drivers/media/dvb/mantis/Makefile
mantis_core-objs := mantis_ioc.o\
mantis_uart.o \
mantis_dma.o\
mantis_pci.o\
mantis_i2c.o\
mantis_dvb.o\
mantis_evm.o\
mantis_hif.o\
mantis_ca.o \
mantis_pcmcia.o \
mantis_input.o
mantis-objs := mantis_cards.o \
mantis_vp1033.o \
mantis_vp1034.o \
mantis_vp1041.o \
mantis_vp2033.o \
mantis_vp2040.o \
mantis_vp3030.o
hopper-objs := hopper_cards.o \
hopper_vp3028.o
obj-$(CONFIG_MANTIS_CORE) += mantis_core.o
obj-$(CONFIG_DVB_MANTIS)+= mantis.o
obj-$(CONFIG_DVB_HOPPER)+= hopper.o
ccflags-y += -Idrivers/media/dvb/dvb-core/ -Idrivers/media/dvb/frontends/
Bjørn
--
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] [media] mantis: merge both vp2033 and vp2040 drivers
Manu Abraham writes: > That's just peanuts you are talking about. The memory usage appears only > if you are using the module. 200 lines of .text is nothing. OK. Deleting 200 completely useless lines of code is nothing? I don't think we live in the same world. > That exists to > differentiate between the 2 devices, not to make both hardware look the same. Right. And every single USB hard drive out there should have it's own duplicated usb-storage driver? I don't think so... I am sure you are right that the cards are different. It just doesn't matter as long as the drivers are identical. Thank you Mauro for doing this long awaited cleanup. Getting rid of all the duplicated and unused code in this driver will make it easier for others to get involved in fixing the real bugs. Bjørn -- 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] Terratec Cinergy C PCI HD (CI)
"Igor M. Liplianin" writes:
> This patch seems for rectifying a typo. But actually the difference between
> mantis_vp2040.c and mantis_vp2033.c code is a card name only.
Yes, there are major code duplication issues in this driver.
> Signed-off-by: Igor M. Liplianin
> diff -r 990a92e2410f linux/drivers/media/dvb/mantis/mantis_cards.c
> --- a/linux/drivers/media/dvb/mantis/mantis_cards.c Wed May 09 01:37:05
> 2012 +0300
> +++ b/linux/drivers/media/dvb/mantis/mantis_cards.c Wed May 09 14:04:31
> 2012 +0300
> @@ -276,7 +276,7 @@
> MAKE_ENTRY(TWINHAN_TECHNOLOGIES, MANTIS_VP_2033_DVB_C, &vp2033_config),
> MAKE_ENTRY(TWINHAN_TECHNOLOGIES, MANTIS_VP_2040_DVB_C, &vp2040_config),
> MAKE_ENTRY(TECHNISAT, CABLESTAR_HD2, &vp2040_config),
> - MAKE_ENTRY(TERRATEC, CINERGY_C, &vp2033_config),
> + MAKE_ENTRY(TERRATEC, CINERGY_C, &vp2040_config),
> MAKE_ENTRY(TWINHAN_TECHNOLOGIES, MANTIS_VP_3030_DVB_T, &vp3030_config),
> { }
> };
What's the point? It's a constructed difference. Makes more sense to
refactor and merge all the duplicated code instead of maintaining this
meaningless code split.
> diff -r 990a92e2410f linux/drivers/media/dvb/mantis/mantis_core.c
> --- a/linux/drivers/media/dvb/mantis/mantis_core.cWed May 09 01:37:05
> 2012 +0300
> +++ b/linux/drivers/media/dvb/mantis/mantis_core.cWed May 09 14:04:31
> 2012 +0300
> @@ -121,7 +121,7 @@
> mantis->hwconfig = &vp2033_mantis_config;
> break;
> case MANTIS_VP_2040_DVB_C: /* VP-2040 */
> - case TERRATEC_CINERGY_C_PCI:/* VP-2040 clone */
> + case CINERGY_C: /* VP-2040 clone */
> case TECHNISAT_CABLESTAR_HD2:
> mantis->hwconfig = &vp2040_mantis_config;
> break;
And this file should never have been merged into the mainline kernel at
all. If you wonder how a bug like that could survive without being
noticed, then the explanation is simple: This code has never been built
as part of the driver in the mainline kernel.
I tried submitting a cleanup patch to have it removed a long time ago:
http://patchwork.linuxtv.org/patch/3680/
but it doesn't seem to have gone anywhere, like most of the patches for
this driver - silently ignored until everyone forgets it and moves on.
The code could certainly benefit from a major cleanup, but I don't see
how that would ever happen. It sort of works. Better leave it there
and spend valuable time elsewhere.
Bjørn
--
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] Various nits, fixes and hacks for mantis CA support on SMP
"Steinar H. Gunderson" writes: > On Mon, Mar 19, 2012 at 11:05:10AM -0300, Mauro Carvalho Chehab wrote: >> A "conglomerate of patches" can't be applied upstream. Instead, you should >> be sending us a patch series, preserving the original author/signed-off-by >> for each one, if the patches were nod written by you, and add your >> Signed-off-by: at the end of each patch. > > This is true. I was, however, mainly looking for feedback -- it seems there > is very little interest, though. The user base is too small to get any feedback without getting the patches into mainline. I suggest you submit the parts you'd like to use yourself. That's the only way to get them tested. I do have two mantis cards, but I don't have any CAM and I don't have access to any DVB-C signal anymore. So that's why I didn't provide any feedback despite being historically interested in this driver. Bjørn -- 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: Smart card reader support for Anysee DVB devices
Antti Palosaari writes: > If you would like to help me then you can find out correct device name > and whats needed for that. I mainly see following possibilities; > * /dev/ttyAnyseeN > * /dev/ttyDVBN > * /dev/adapterN/serial You should probably include the TTY maintainer in that discussion. I assume this device won't really be a TTY device? Then it probably shouldn't be named like one. Bjørn -- 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: checkpatch.pl WARNING: Do not use whitespace before Signed-off-by:
Antti Palosaari writes: > I am almost sure this have been working earlier, but now it seems like > nothing is acceptable for checkpatch.pl! I did surely about 20 --amend > and tried to remove everything, without luck. Could someone point out > whats new acceptable logging format for checkpatch.pl ? > > [crope@localhost linux]$ git show > 1b19e42952963ae2a09a655f487de15b7c81c5b7 |./scripts/checkpatch.pl - > WARNING: Do not use whitespace before Signed-off-by: Don't know if checkpatch used to accept that, but you can use "--format=email" to make it work with git show: bjorn@canardo:/usr/local/src/git/linux$ git show --format=email 1b19e42952963ae2a09a655f487de15b7c81c5b7|./scripts/checkpatch.pl - total: 0 errors, 0 warnings, 48 lines checked Your patch has no obvious style problems and is ready for submission. Bjørn -- 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: Smart card reader support for Anysee DVB devices
Antti Palosaari writes: > Since Anysee device itself does not have CCID interface it is needed > to make virtual USB device in order to get CCID support. I have never > seen virtual USB devices like that, but there is VHCI in current > kernel staging that actually does something like that over IP. Don't know if you have seen this already, but there's a virtual CCID device implementation in QEMU. See http://wiki.qemu.org/Features/Smartcard Should be a good starting point. Combine it withe the VHCI driver from USBIP and you have your CCID device. Bjørn -- 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: Anyone tested the DVB-T2 dual tuner TBS6280?
Steve Kerrison writes:
> This TBS card has only just been brought to my attention. I cannot tell
> what PCIe chip it uses and if it's supported. The alleged Linux driver
> download for it doesn't have the cxd2820r code in it, so I can't see
> that having much chance of working.
There's a binary-only tbs62x0fe_driver for x86_{32,64} in the archive,
so it _might_ work. But I don't think anyone here will recommend
something like that... You may just as well run Windows instead, and at
least get a somewhat tested binary driver.
Bjørn
--
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 4/5] cxd2099: Fix compilation of ngene/ddbridge for DVB_CXD2099=n
Oliver Endriss writes: > Fix compilation of ngene/ddbridge for DVB_CXD2099=n. > > Note: Bug was introduced by commit 'cxd2099: Update to latest version'. Shouldn't that patch instead be fixed and resubmitted? Bjørn -- 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] vtunerc - virtual DVB device driver
Devin Heitmueller writes: > The introduction of this patch makes it trivial for a third party to > provide closed-source userland support for tuners while reusing all > the existing GPL driver code that makes up the framework. Wouldn't it be just as trivial to bundle the closed-source tuner support with this patch or a similar GPL licensed driver? This doesn't change anything wrt closed source drivers. Bjørn -- 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] vtunerc - virtual DVB device driver
Devin Heitmueller writes: > Nothing prevents a third-party from writing closed source drivers. > What we do *not* think is fair though is that those third parties > should be able to take advantage of all the GPL code that makes up the > DVB core, and the man-years spent developing that code. You could use the same argument against adding a loadable module interface to the Linux kernel (and I'm pretty sure it was used). Thankfully, usability won back then. Or we most likely wouldn't have had a single Linux DVB driver. Or Linux at all, except as a historical footnote. Honza posted a GPL licensed driver and gave a pretty good usage scenario. Please don't reject it based on fear of abuse. If you think about it, almost any usability improvement will also make abuse easier. And if you reject all of them based on such fear, then your system will die. Thanks. Bjørn -- 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] [media] DVB API: Mention the dvbM device
Signed-off-by: Bjørn Mork --- Don't know why it was left out, but I found it very confusing when it is mention further down. However, this does make the next paragraph wrong, as there is no "dvr" specific include file. Documentation/DocBook/media/dvb/intro.xml |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/media/dvb/intro.xml b/Documentation/DocBook/media/dvb/intro.xml index 8223639..c75dc7c 100644 --- a/Documentation/DocBook/media/dvb/intro.xml +++ b/Documentation/DocBook/media/dvb/intro.xml @@ -154,6 +154,10 @@ are called: +/dev/dvb/adapterN/dvrM, + + + /dev/dvb/adapterN/caM, where N enumerates the DVB PCI cards in a system starting -- 1.7.2.5 -- 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] V4L1 API has been moved into "legacy" on the linuxtv.org site
Signed-off-by: Bjørn Mork --- Documentation/video4linux/API.html |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/video4linux/API.html b/Documentation/video4linux/API.html index d72fd2a..256f8ef 100644 --- a/Documentation/video4linux/API.html +++ b/Documentation/video4linux/API.html @@ -9,7 +9,7 @@ - http://www.linuxtv.org/downloads/video4linux/API/V4L1_API.html";>V4L original API + http://linuxtv.org/downloads/legacy/video4linux/API/V4L1_API.html";>V4L original API Obsoleted by V4L2 API -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 2.6.40] PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C)
Antti Palosaari writes: > On 06/01/2011 04:27 PM, Mauro Carvalho Chehab wrote: >> Em 25-05-2011 17:42, Antti Palosaari escreveu: >>> Antti Palosaari (7): >>>em28xx-dvb: add module param "options" and use it for LNA >> >> That patch is ugly, for several reasons: >> >> 1) we don't want a generic "options" parameter, whose meaning changes from >> device to devices; > > I agree it is not proper solution, but in my mind it is better to > offer some solution than no solution at all. > >> 2) what happens if someone has two em28xx devices plugged? > > It depends depends devices, currently only nanoStick T2 only looks > that param, other just ignore. If there is two nanoStics then both > have same LNA settings. > > That's just like same behaviour as for example remote controller > polling. Or for example DiBcom driver LNA, since it does have similar > module param already. Will you you commit it if I rename it similarly > as DiBcom? > >> 3) the better would be to detect if LNA is needed, or to add a DVBS2API >> call to enable/disable LNA. > > True, but it needs some research. There is many hardware which gets > signal input from demod or tuner and makes some fine tune according to > that. We need to define some new callbacks for demod and tuner in > order to do this kind of actions. > Or just add new LNA param to API use it manually. Or option 4) just enable the LNA unconditionally. I did some testing in my environment, and I was unable to tune anything on either DVB-T or DVB-C without the LNA enabled. I'm of course aware that this depends on your signal, but have you actually seen a real life signal where tuning fails with the LNA enabled and works without it? I do believe that my DVB-C signal at least is pretty strong. Bjørn -- 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: [bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency
Antti Palosaari writes: > On 06/03/2011 03:50 PM, Bjørn Mork wrote: > >> This probably means that a generic i2c_tuner wrapper, similar to >> dvb_attach, would be useful. > > For the cxd2820r it is also possible to return I2C adapter as pointer > from dvb_attach like pointer to FE0 is carried for FE1 > dvb_attach. What you think about that? I don't feel competent to answer that at all. It does seem like overloading an existing interface, but it might be OK. I just grepped a bit around for EXPORT_SYMBOL of anything except foo_attach, and found that there are a few frontend drivers which exports multiple symbols: bjorn@canardo:/usr/local/src/git/linux-2.6$ grep EXPORT_SYMBOL drivers/media/dvb/frontends/*.c|grep -v _attach drivers/media/dvb/frontends/cx24113.c:EXPORT_SYMBOL(cx24113_agc_callback); drivers/media/dvb/frontends/cx24123.c:EXPORT_SYMBOL(cx24123_get_tuner_i2c_adapter); drivers/media/dvb/frontends/cxd2820r_core.c:EXPORT_SYMBOL(cxd2820r_get_tuner_i2c_adapter); drivers/media/dvb/frontends/dib0070.c:EXPORT_SYMBOL(dib0070_ctrl_agc_filter); drivers/media/dvb/frontends/dib0070.c:EXPORT_SYMBOL(dib0070_get_rf_output); drivers/media/dvb/frontends/dib0070.c:EXPORT_SYMBOL(dib0070_set_rf_output); drivers/media/dvb/frontends/dib0070.c:EXPORT_SYMBOL(dib0070_wbd_offset); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_dcc_freq); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_pwm_gain_reset); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_gain_control); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_get_current_gain); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_get_wbd_offset); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_get_tune_state); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_set_tune_state); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_register); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_fw_register); drivers/media/dvb/frontends/dib3000mc.c:EXPORT_SYMBOL(dib3000mc_get_tuner_i2c_master); drivers/media/dvb/frontends/dib3000mc.c:EXPORT_SYMBOL(dib3000mc_pid_control); drivers/media/dvb/frontends/dib3000mc.c:EXPORT_SYMBOL(dib3000mc_pid_parse); drivers/media/dvb/frontends/dib3000mc.c:EXPORT_SYMBOL(dib3000mc_set_config); drivers/media/dvb/frontends/dib3000mc.c:EXPORT_SYMBOL(dib3000mc_i2c_enumeration); drivers/media/dvb/frontends/dib7000m.c:EXPORT_SYMBOL(dib7000m_get_i2c_master); drivers/media/dvb/frontends/dib7000m.c:EXPORT_SYMBOL(dib7000m_pid_filter_ctrl); drivers/media/dvb/frontends/dib7000m.c:EXPORT_SYMBOL(dib7000m_pid_filter); drivers/media/dvb/frontends/dib7000m.c:EXPORT_SYMBOL(dib7000m_i2c_enumeration); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_set_wbd_ref); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_update_pll); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_set_gpio); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_ctrl_timf); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000pc_detection); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_get_i2c_master); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_pid_filter_ctrl); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_pid_filter); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_i2c_enumeration); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7090_get_i2c_tuner); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7090_tuner_sleep); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7090_agc_restart); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7090_get_adc_power); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7090_slave_reset); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_set_wbd_ref); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_set_gpio); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_pwm_agc_reset); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_get_adc_power); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_get_tune_state); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_set_tune_state); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_set_slave_frontend); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_remove_slave_frontend); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_get_slave_frontend); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_i2c_enumeration); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_get_i2c_master); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_pid_filter_ctrl); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_pid_filter); drivers/media/dvb/frontends/dib9000.c:EXPORT_SYMBOL(dib9000_fw_set_component_bus_speed); drivers/media/dvb/frontends/dib9000.c:EXPORT_SYMBOL(dib9000_get_tuner_interface); drivers/media/dv
Re: [bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency
Antti Palosaari writes: > There is some other FEs having also I2C adapter, I wonder how those > handle this situation. I looked example from cx24123 and s5h1420 > drivers, both used by flexcop. > > Did you see what is magic used those devices? None. They have the same problem, creating hard module dependencies even if they use dvb_attach() and CONFIG_MEDIA_ATTACH is set: bjorn@canardo:~$ modinfo b2c2-flexcop filename: /lib/modules/2.6.32-5-amd64/kernel/drivers/media/dvb/b2c2/b2c2-flexcop.ko license:GPL description:B2C2 FlexcopII/II(b)/III digital TV receiver chip author: Patrick Boettcher http://vger.kernel.org/majordomo-info.html
Re: [bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency
Bjørn Mork writes:
> diff --git a/drivers/media/video/em28xx/em28xx-dvb.c
> b/drivers/media/video/em28xx/em28xx-dvb.c
> index 7904ca4..d994592 100644
> --- a/drivers/media/video/em28xx/em28xx-dvb.c
> +++ b/drivers/media/video/em28xx/em28xx-dvb.c
> @@ -669,7 +669,8 @@ static int dvb_init(struct em28xx *dev)
> &em28xx_cxd2820r_config, &dev->i2c_adap, NULL);
> if (dvb->fe[0]) {
> struct i2c_adapter *i2c_tuner;
> - i2c_tuner = cxd2820r_get_tuner_i2c_adapter(dvb->fe[0]);
> + /* we don't really attach i2c_tuner. Just reusing the
> symbol logic */
> + i2c_tuner = dvb_attach(cxd2820r_get_tuner_i2c_adapter,
> dvb->fe[0]);
Except that this really messes up the reference count, and need to have
a matching symbol_put... So you should probably code it with
symbol_request()/symbol_put() if you want to go this way instead of
the dvb_attach shortcut .
Bjørn
--
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: [bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency
Another possible solution... This is my last one, I promise :-)
I looked at dvb_attach() and realized that you can ab^H^Hreuse it. This
makes the patch tiny, and allow you to continue hiding
struct cxd2820r_priv.
Bjørn
>From b570bbad12c1d164ed92c6711a1775db29c4c0a7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?=
Date: Wed, 1 Jun 2011 12:48:25 +0200
Subject: [PATCH] em28xx-dvb: Use dvb_attach to call cxd2820r_get_tuner_i2c_adapter()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This avoids a hard module dependency on cxd2820r. Even though we
don't really attach anything in this call, we can stil reuse
dvb_attach since the called function is expected to return a
pointer.
Signed-off-by: Bjørn Mork
---
drivers/media/video/em28xx/em28xx-dvb.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-dvb.c b/drivers/media/video/em28xx/em28xx-dvb.c
index 7904ca4..d994592 100644
--- a/drivers/media/video/em28xx/em28xx-dvb.c
+++ b/drivers/media/video/em28xx/em28xx-dvb.c
@@ -669,7 +669,8 @@ static int dvb_init(struct em28xx *dev)
&em28xx_cxd2820r_config, &dev->i2c_adap, NULL);
if (dvb->fe[0]) {
struct i2c_adapter *i2c_tuner;
- i2c_tuner = cxd2820r_get_tuner_i2c_adapter(dvb->fe[0]);
+ /* we don't really attach i2c_tuner. Just reusing the symbol logic */
+ i2c_tuner = dvb_attach(cxd2820r_get_tuner_i2c_adapter, dvb->fe[0]);
/* FE 0 attach tuner */
if (!dvb_attach(tda18271_attach, dvb->fe[0], 0x60,
i2c_tuner, &em28xx_cxd2820r_tda18271_config)) {
--
1.7.2.5
Re: [bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency
Antti Palosaari writes:
> On 06/01/2011 12:45 PM, Bjørn Mork wrote:
>> Don't know the proper fix. My naïve quick-fix was just to move struct
>> cxd2820r_priv into cxd2820r.h and making the function static inlined.
>> However, I do see that you may not want the struct in cxd2820r.h. But I
>> trust that you have a brilliant solution to the problem :-)
>
> Actually I don't have any idea about that. Help is welcome.
Well, my straight forward approach is attached if you find that useful.
I removed the whole function call, since it was only ever called from
one place. But that is your call.
I assume the fancy solution involves symbol trickery ala what
dvb_attach() does. You do of course know that the symbol is available
at the point where em28xx-dvb calls it, as the cxd2820r_attach() must
have succeeded. So "all" you need to do is to prevent the module tools
from being too smart.
Bjørn
>From 857331b809fca1003056dbc0f01f917e792981db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?=
Date: Tue, 31 May 2011 15:16:39 +0200
Subject: [PATCH] em28xx-dvb: avoid unwanted dependency on cxd2820r
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Calling cxd2820r_get_tuner_i2c_adapter() creates a dependency on cxd2820r
even if CONFIG_MEDIA_ATTACH is set. Avoid this
Signed-off-by: Bjørn Mork
---
drivers/media/dvb/frontends/cxd2820r.h | 27 +--
drivers/media/dvb/frontends/cxd2820r_core.c |7 ---
drivers/media/dvb/frontends/cxd2820r_priv.h | 18 --
drivers/media/video/em28xx/em28xx-dvb.c |4 ++--
4 files changed, 19 insertions(+), 37 deletions(-)
diff --git a/drivers/media/dvb/frontends/cxd2820r.h b/drivers/media/dvb/frontends/cxd2820r.h
index ad17845..e0eeea8 100644
--- a/drivers/media/dvb/frontends/cxd2820r.h
+++ b/drivers/media/dvb/frontends/cxd2820r.h
@@ -85,6 +85,23 @@ struct cxd2820r_config {
u8 gpio_dvbc[3];
};
+struct cxd2820r_priv {
+ struct i2c_adapter *i2c;
+ struct dvb_frontend fe[2];
+ struct cxd2820r_config cfg;
+ struct i2c_adapter tuner_i2c_adapter;
+
+ struct mutex fe_lock; /* FE lock */
+ int active_fe:2; /* FE lock, -1=NONE, 0=DVB-T/T2, 1=DVB-C */
+
+ int ber_running:1;
+
+ u8 bank[2];
+ u8 gpio[3];
+
+ fe_delivery_system_t delivery_system;
+ int last_tune_failed:1; /* for switch between T and T2 tune */
+};
#if defined(CONFIG_DVB_CXD2820R) || \
(defined(CONFIG_DVB_CXD2820R_MODULE) && defined(MODULE))
@@ -93,9 +110,6 @@ extern struct dvb_frontend *cxd2820r_attach(
struct i2c_adapter *i2c,
struct dvb_frontend *fe
);
-extern struct i2c_adapter *cxd2820r_get_tuner_i2c_adapter(
- struct dvb_frontend *fe
-);
#else
static inline struct dvb_frontend *cxd2820r_attach(
const struct cxd2820r_config *config,
@@ -106,13 +120,6 @@ static inline struct dvb_frontend *cxd2820r_attach(
printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
return NULL;
}
-static inline struct i2c_adapter *cxd2820r_get_tuner_i2c_adapter(
- struct dvb_frontend *fe
-)
-{
- return NULL;
-}
-
#endif
#endif /* CXD2820R_H */
diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c b/drivers/media/dvb/frontends/cxd2820r_core.c
index 0779f69..48e0265 100644
--- a/drivers/media/dvb/frontends/cxd2820r_core.c
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c
@@ -771,13 +771,6 @@ static struct i2c_algorithm cxd2820r_tuner_i2c_algo = {
.functionality = cxd2820r_tuner_i2c_func,
};
-struct i2c_adapter *cxd2820r_get_tuner_i2c_adapter(struct dvb_frontend *fe)
-{
- struct cxd2820r_priv *priv = fe->demodulator_priv;
- return &priv->tuner_i2c_adapter;
-}
-EXPORT_SYMBOL(cxd2820r_get_tuner_i2c_adapter);
-
static struct dvb_frontend_ops cxd2820r_ops[2];
struct dvb_frontend *cxd2820r_attach(const struct cxd2820r_config *cfg,
diff --git a/drivers/media/dvb/frontends/cxd2820r_priv.h b/drivers/media/dvb/frontends/cxd2820r_priv.h
index 25adbee..5adeccd 100644
--- a/drivers/media/dvb/frontends/cxd2820r_priv.h
+++ b/drivers/media/dvb/frontends/cxd2820r_priv.h
@@ -46,24 +46,6 @@ struct reg_val_mask {
u8 mask;
};
-struct cxd2820r_priv {
- struct i2c_adapter *i2c;
- struct dvb_frontend fe[2];
- struct cxd2820r_config cfg;
- struct i2c_adapter tuner_i2c_adapter;
-
- struct mutex fe_lock; /* FE lock */
- int active_fe:2; /* FE lock, -1=NONE, 0=DVB-T/T2, 1=DVB-C */
-
- int ber_running:1;
-
- u8 bank[2];
- u8 gpio[3];
-
- fe_delivery_system_t delivery_system;
- int last_tune_failed:1; /* for switch between T and T2 tune */
-};
-
/* cxd2820r_core.c */
extern int cxd2820r_debug;
diff --git a/drivers/media/video/em28xx/em28xx-dvb.c b/drivers/media/video/em28xx/em28xx-dvb.c
index 7904ca4..e723c61 100644
--- a/drivers/media/video/em28xx/em28xx-dvb.c
+++ b/drivers/media/video/em28xx/em28xx-dvb.c
@@ -668,8 +668,8 @@ static int dvb_init(struct em28xx *dev)
dvb->fe[0] = dvb_attach(cxd2820r_attach,
&
[bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency
Hello, I noticed this warning WARNING: "cxd2820r_get_tuner_i2c_adapter" [/usr/local/src/git/linux-2.6/drivers/media/video/em28xx/em28xx-dvb.ko] undefined! while building the driver in 2.6.32 with backported 290e support. This warning does not appear with 3.0.0-rc1, but the call still does cause a hard dependency on cxd2820r even if you build with CONFIG_MEDIA_ATTACH=y: bjorn@canardo:/usr/local/src/git/linux-2.6$ modinfo drivers/media/video/em28xx/em28xx-dvb.ko filename: drivers/media/video/em28xx/em28xx-dvb.ko license:GPL author: Mauro Carvalho Chehab description:driver for em28xx based DVB cards depends:cxd2820r,dvb-core,em28xx,usbcore vermagic: 3.0.0-rc1+ SMP mod_unload modversions parm: debug:enable debug messages [dvb] (int) parm: adapter_nr:DVB adapter numbers (array of short) I assume this is unwanted. As you can see, cxd2820r is the only frontend dependency Don't know the proper fix. My naïve quick-fix was just to move struct cxd2820r_priv into cxd2820r.h and making the function static inlined. However, I do see that you may not want the struct in cxd2820r.h. But I trust that you have a brilliant solution to the problem :-) Thanks for your great work on the cxd2820r driver and nanostick T2 290e support! Bjørn -- 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
Writing descriptive commit messages (was Re: PCTV nanoStick T2 290e support - Thank you!)
Bjørn Mork writes:
> Rémi Denis-Courmont writes:
>> On Fri, 27 May 2011 13:36:37 +0200, Bjørn Mork wrote:
>>
>>> I'm a bit curious about this device. It seems to only be marketed as a
>>> DVB-T2 device in areas where that spec is used. But looking at your
>>> driver, it seems that the device also supports DVB-C. Is that correct?
>>
>> At least, DVB-C worked for me.
>
> Thanks. Then I've ordered one of these :-)
Received and tested.
Being quite conservative wrt kernel updates, I did a quick-n-dirty
backport of the PCTV nanoStick T2 290e support to 2.6.32. I chose to
keep it as simple as possible, by ignoring as much as possible of the
unrelated changes to the em28xx driver since 2.6.32. This was quite
educational.
One surprising issue that others might want to be aware of, was that
commit ca3dfd6a6f8364c1d51e548adb4564702f1141e9
Author: Mauro Carvalho Chehab
Date: Fri Sep 10 17:29:14 2010 -0300
[media] em28xx: Add support for Leadership ISDB-T
This device uses an em2874B + Sharp 921 One Seg frontend.
Signed-off-by: Douglas Schilling Landgraf
Signed-off-by: Mauro Carvalho Chehab
actually has important side effects making it a *requirement* for 290e
support (and possibly other cards added after that commit). The commit
message is completely misleading. These changes to
drivers/media/video/em28xx/em28xx-cards.c are in no way described by it,
and do affect much more than the "Leadership ISDB-T" card:
@@ -2430,8 +2460,36 @@ void em28xx_card_setup(struct em28xx *dev)
dev->board.is_webcam = 0;
else
dev->progressive = 1;
- } else
- em28xx_set_model(dev);
+ }
+
+ if (!dev->board.is_webcam) {
+ switch (dev->model) {
+ case EM2820_BOARD_UNKNOWN:
+ case EM2800_BOARD_UNKNOWN:
+ /*
+* The K-WORLD DVB-T 310U is detected as an MSI Digivox AD.
+*
+* This occurs because they share identical USB vendor and
+* product IDs.
+*
+* What we do here is look up the EEPROM hash of the K-WORLD
+* and if it is found then we decide that we do not have
+* a DIGIVOX and reset the device to the K-WORLD instead.
+*
+* This solution is only valid if they do not share eeprom
+* hash identities which has not been determined as yet.
+*/
+ if (em28xx_hint_board(dev) < 0)
+ em28xx_errdev("Board not discovered\n");
+ else {
+ em28xx_set_model(dev);
+ em28xx_pre_card_setup(dev);
+ }
+ break;
+ default:
+ em28xx_set_model(dev);
+ }
+ }
em28xx_info("Identified as %s (card=%d)\n",
dev->board.name, dev->model);
@@ -2749,8 +2807,8 @@ static int em28xx_init_dev(struct em28xx **devhandle,
struct usb_device *udev,
em28xx_pre_card_setup(dev);
if (!dev->board.is_em2800) {
- /* Sets I2C speed to 100 KHz */
- retval = em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x40);
+ /* Resets I2C speed */
+ em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, dev->board.i2c_speed);
if (retval < 0) {
em28xx_errdev("%s: em28xx_write_regs_req failed!"
" retval [%d]\n",
Could we please not do things like that? That part should have been a
separate commit with a descriptive commit message.
Thanks.
Bjørn
--
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: [linux-dvb] Terratec Cinergy C HD - CAM support.... Need help?
Willem van Asperen writes: > Actually, doing this on s2-liplianin-41388e396e0f (the one I downloaded > today) > gets: > $ grep mantis_ca_init *.c > > mantis_ca.c:int mantis_ca_init(struct mantis_pci *mantis) > mantis_dvb.c: mantis_ca_init(mantis); > > And in the function __devinit mantis_dvb_init(struct mantis_pci *mantis) it > actually says: > > ... > dvb_net_init(&mantis->dvb_adapter, &mantis->dvbnet, &mantis->demux.dmx); > tasklet_init(&mantis->tasklet, mantis_dma_xfer, (unsigned long) mantis); > mantis_frontend_init(mantis); > mantis_ca_init(mantis); > > return 0; > ... > > So it seems that this mantis_ca_init call is actually made nowadays. In the s2-liplianin yes. Not in mainline. Investigating the differences might be useful. Bjørn -- 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: [linux-dvb] Terratec Cinergy C HD - CAM support.... Need help?
Marc Coevoet writes: > Op 27-05-11 21:48, Willem van Asperen schreef: >> >> a) CAM support is currently not implemented for terratec HD > > For all cards? The CA code in the mantis driver isn't actually hooked into the driver anywhere, so that't correct: No CAM will currently work with the Terratec Cinergy C HD. Exported, but never called: bjorn@canardo:/usr/local/src/git/linux-2.6/drivers/media/dvb/mantis$ grep mantis_ca_init *.c mantis_ca.c:int mantis_ca_init(struct mantis_pci *mantis) mantis_ca.c:EXPORT_SYMBOL_GPL(mantis_ca_init); I don't know why, but I assume it's the same as with the remote control code that was recently fixed Christoph Pinkl: The code probably wasn't considered production ready when the driver was merged, and was therefore "temporarily" disabled until it could be fixed. Bjørn -- 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: PCTV nanoStick T2 290e support - Thank you!
Steve Kerrison writes: > The demodulator chip supports T,T2 and C. > > Here in the UK you're not really allowed to attach cable receivers that > aren't supplied by the cable company (Virgin Media). That and the fact > that it has no access module for obvious reasons, I guess PCTV Systems > didn't see the benefit in marketing the C functionality. Well, I found it a bit weird that they do announce DVB-T + DVB-C support for the "PCTV QuatroStick nano" (which has the exact same form factor and look, and therefore obviously no CA slot either): http://www.pctvsystems.com/Products/ProductsEuropeAsia/Hybridproducts/PCTVQuatroSticknano/tabid/254/language/en-GB/Default.aspx While the "PCTV nanoStick T2" is announced as only DVB-T2 + DVB-T: http://www.pctvsystems.com/Products/ProductsEuropeAsia/Digitalproducts/PCTVnanoStickT2/tabid/248/language/en-GB/Default.aspx That's why I asked, even though the driver clearly supports DVB-C. But you may be right that this is because the "nanoStick T2" currently is targeted for the UK. Around here, we've actually got some cable companies supporting TV sets with integrated receivers. Of course requiring their CAM. They probably still don't like the thought of PC based receivers, but there is some hope... > I don't actually know if the windows driver supports C mode, it would be > amusing if we deliver more functionality with the Linux driver :) I thought downloading the Windows driver would tell, but a) I cannot seem to find the Windows driver for this device, and b) this info isn't easily found in the drivers I looked at So who knows? It would certainly be amusing. Bjørn -- 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: PCTV nanoStick T2 290e support - Thank you!
Rémi Denis-Courmont writes: > On Fri, 27 May 2011 13:36:37 +0200, Bjørn Mork wrote: > >> I'm a bit curious about this device. It seems to only be marketed as a >> DVB-T2 device in areas where that spec is used. But looking at your >> driver, it seems that the device also supports DVB-C. Is that correct? > > At least, DVB-C worked for me. Thanks. Then I've ordered one of these :-) Bjørn -- 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: PCTV nanoStick T2 290e support - Thank you!
Antti Palosaari writes: > On 05/27/2011 12:25 AM, Nicolas WILL wrote: >> Just installed mine for MythTV. >> >> Works great on the first try! >> >> Many, many thanks! > > Thank you for the feedback! I'm a bit curious about this device. It seems to only be marketed as a DVB-T2 device in areas where that spec is used. But looking at your driver, it seems that the device also supports DVB-C. Is that correct? Bjørn -- 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] Add remote control support for mantis
"Christoph Pinkl" writes: > X-Mailer: Microsoft Office Outlook 12.0 This will not work. Use git-send-email or a working email client. See http://www.kernel.org/doc/Documentation/email-clients.txt for further hints. Bjørn -- 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: dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
HoP writes: > 2011/5/12 Bjørn Mork : >> Andreas Oberritter writes: >> >>> Please try the patches submitted for testing: >>> >>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg31194.html >> >> Ah, great! Thanks. Nothing better than a problem already solved. > > Not solved. Andreas did an attempt to solve it (at least as far as I know > patches not get accepted yet), so please report your result of testing. Sure. Now, the only machine I've got with DVB cards is running a stock Debian 2.6.32 kernel and I prefer not to mess with that. But I did a quick-n-dirty "backport" of the API changes to 2.6.32, built a new dvb_core module and loaded that. And the results are good, as expected. All parameters are now in sync. Both these adapters have been tuned by VDR (which uses the new API): bjorn@canardo:/usr/local/src/git/linux-2.6$ /tmp/dvb_fe_test /dev/dvb/adapter0/frontend0 == /dev/dvb/adapter0/frontend0 == name: Philips TDA10023 DVB-C type: FE_QAM == FE_GET_FRONTEND == frequency : 264006739 inversion : off (0) symbol_rate : 690 fec_inner : FEC_NONE (0) modulation: QAM_256 (5) == FE_GET_PROPERTY == [17] DTV_DELIVERY_SYSTEM : SYS_DVBC_ANNEX_AC (1) [03] DTV_FREQUENCY : 264006739 [06] DTV_INVERSION : off (0) [08] DTV_SYMBOL_RATE : 690 [09] DTV_INNER_FEC : FEC_NONE (0) [04] DTV_MODULATION : QAM_256 (5) [35] DTV_API_VERSION : 5.1 [05] DTV_BANDWIDTH_HZ: BANDWIDTH_AUTO (3) bjorn@canardo:/usr/local/src/git/linux-2.6$ /tmp/dvb_fe_test /dev/dvb/adapter1/frontend0 == /dev/dvb/adapter1/frontend0 == name: Philips TDA10023 DVB-C type: FE_QAM == FE_GET_FRONTEND == frequency : 272006739 inversion : off (0) symbol_rate : 690 fec_inner : FEC_NONE (0) modulation: QAM_256 (5) == FE_GET_PROPERTY == [17] DTV_DELIVERY_SYSTEM : SYS_DVBC_ANNEX_AC (1) [03] DTV_FREQUENCY : 272006739 [06] DTV_INVERSION : off (0) [08] DTV_SYMBOL_RATE : 690 [09] DTV_INNER_FEC : FEC_NONE (0) [04] DTV_MODULATION : QAM_256 (5) [35] DTV_API_VERSION : 5.1 [05] DTV_BANDWIDTH_HZ: BANDWIDTH_AUTO (3) I've obviously messed up the API_VERSION, so this is probably more dirty than quick But all the important values, like frequency, inversion and inner_fec, are now in sync. Thanks a lot. Feel free to add Tested-by: Bjørn Mork to the whole patch series if that matters to anyone. I'd really like this to go into 2.6.40 if that is possible. It would have been nice to see it in 2.6.32-longerm was well, but I guess that's out of the question since it builds on top of other API changes (DVBT2). Bjørn -- 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: dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
Andreas Oberritter writes: > Please try the patches submitted for testing: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg31194.html Ah, great! Thanks. Nothing better than a problem already solved. Bjørn -- 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
dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
I see in drivers/media/dvb/dvb-core/dvb_frontend.c that there is some
synchronization between the old and the new API.
But it is incomplete: The new FE_GET_PROPERTY will report only cached
values, which is whatever the application has written and not the
actual tuned values like FE_GET_FRONTEND will. The problem is that
FE_GET_PROPERTY only will call fe->ops.get_property even for legacy
drivers. It could have fallen back to calling fe->ops.get_frontend
followed by a cache synchronization.
Is this difference intentional (because it costs too much, doesn't
matter, or whatever)? Or should I prepare a patch for dvb_frontend.c?
I made a small util comparing the two APIs, basically just doing
fd = open("/dev/dvb/adapter0/frontend0", O_RDONLY);
ioctl(fd, FE_GET_INFO, &fe_info);
ioctl(fd, FE_GET_FRONTEND, &fe_param);
ioctl(fd, FE_GET_PROPERTY, &dtv_props);
close(fd);
and pretty-printing some of the results from the three ioctl()s. It
reports typically something like this:
bjorn@canardo:~$ /tmp/dvb_fe_test /dev/dvb/adapter1/frontend0
== /dev/dvb/adapter1/frontend0 ==
name: Philips TDA10023 DVB-C
type: FE_QAM
== FE_GET_FRONTEND ==
frequency : 394013477
inversion : off (0)
symbol_rate : 690
fec_inner : FEC_NONE (0)
modulation: QAM_256 (5)
== FE_GET_PROPERTY ==
[17] DTV_DELIVERY_SYSTEM : SYS_DVBC_ANNEX_AC (1)
[03] DTV_FREQUENCY : 39400
[06] DTV_INVERSION : auto (2)
[08] DTV_SYMBOL_RATE : 690
[09] DTV_INNER_FEC : FEC_AUTO (9)
[04] DTV_MODULATION : QAM_256 (5)
[35] DTV_API_VERSION : 5.1
[05] DTV_BANDWIDTH_HZ: BANDWIDTH_AUTO (3)
Notice how FE_GET_PROPERTY returns "auto" settings for inversion and
inner_fec, while FE_GET_FRONTEND reports the actual values currently set
in the tuner. Also notice how the frequency differs.
It's not a big issue I believe, but I do find this a bit confusing as
two different apps using different APIs will report different settings.
Bjørn
--
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: Technisat Cablestar HD2 not automatically detected by kernel > 2.6.33?
Jos Hoekstra writes:
> I got this card and it doesn't seem to be detected by Ubuntu 10.4.2
> with kernel 2.6.35(-25-generic #44~lucid1-Ubuntu SMP Tue Jan 25
> 19:17:25 UTC 2011 x86_64 GNU/Linux)
>
> The wiki seems to indicate that this card is supported as of kernel
> 2.6.33, however it doesn't show up as a dvb-adapter.
[..]
> After rebooting it however seems I need to manually modprobe mantis
> and restart the backend to have mythtv work with this card. Is there a
> way to make these modules load automatically after a reboot?
This is fixed by the following trivial patch, which was finally included
in kernel 2.6.38:
commit 116d588ea21cf0278a4de1e3272e9c3220a647e7
Author: Manu Abraham
Date: Thu Feb 11 04:11:05 2010 -0300
[media] Mantis, hopper: use MODULE_DEVICE_TABLE
use the macro to make modules auto-loadable
Thanks to Ozan Çağlayan for pointing it out
Signed-off-by: Manu Abraham
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb/mantis/hopper_cards.c
b/drivers/media/dvb/mantis/hopper_cards.c
index 09e9fc7..70e73af 100644
--- a/drivers/media/dvb/mantis/hopper_cards.c
+++ b/drivers/media/dvb/mantis/hopper_cards.c
@@ -251,6 +251,8 @@ static struct pci_device_id hopper_pci_table[] = {
{ }
};
+MODULE_DEVICE_TABLE(pci, hopper_pci_table);
+
static struct pci_driver hopper_pci_driver = {
.name = DRIVER_NAME,
.id_table = hopper_pci_table,
diff --git a/drivers/media/dvb/mantis/mantis_cards.c
b/drivers/media/dvb/mantis/mantis_cards.c
index cf4b39f..40da225 100644
--- a/drivers/media/dvb/mantis/mantis_cards.c
+++ b/drivers/media/dvb/mantis/mantis_cards.c
@@ -281,6 +281,8 @@ static struct pci_device_id mantis_pci_table[] = {
{ }
};
+MODULE_DEVICE_TABLE(pci, mantis_pci_table);
+
static struct pci_driver mantis_pci_driver = {
.name = DRIVER_NAME,
.id_table = mantis_pci_table,
The best way to work around the problem until you upgrade your kernel to
2.6.38 or newer, is probably just adding mantis to /etc/modules.
Bjørn
--
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] [media] mantis: trivial module parameter documentation fix
The default for "verbose" is 0. Update description to match. Signed-off-by: Bjørn Mork --- drivers/media/dvb/mantis/hopper_cards.c |2 +- drivers/media/dvb/mantis/mantis_cards.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/dvb/mantis/hopper_cards.c b/drivers/media/dvb/mantis/hopper_cards.c index 70e73af..1402062 100644 --- a/drivers/media/dvb/mantis/hopper_cards.c +++ b/drivers/media/dvb/mantis/hopper_cards.c @@ -44,7 +44,7 @@ static unsigned int verbose; module_param(verbose, int, 0644); -MODULE_PARM_DESC(verbose, "verbose startup messages, default is 1 (yes)"); +MODULE_PARM_DESC(verbose, "verbose startup messages, default is 0 (no)"); #define DRIVER_NAME"Hopper" diff --git a/drivers/media/dvb/mantis/mantis_cards.c b/drivers/media/dvb/mantis/mantis_cards.c index 40da225..05cbb9d 100644 --- a/drivers/media/dvb/mantis/mantis_cards.c +++ b/drivers/media/dvb/mantis/mantis_cards.c @@ -52,7 +52,7 @@ static unsigned int verbose; module_param(verbose, int, 0644); -MODULE_PARM_DESC(verbose, "verbose startup messages, default is 1 (yes)"); +MODULE_PARM_DESC(verbose, "verbose startup messages, default is 0 (no)"); static int devs; -- 1.7.2.5 -- 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: S2-3200 switching-timeouts on 2.6.38
Rico Tzschichholz writes: >> Actually, quite a lot of effort was put in to get that part right. It >> does the reverse thing that's to be done. >> The revamped version is here [1] If the issue persists still, then it >> needs to be investigated further. >> >> [1] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html > > I am not sure how this is related to stb6100? > > Does that mean the current stb0899 patch [2] isnt ready to be proposed > for 2.6.39 yet? Or does the stb6100 patch has a better design to solve > this issue which should be adapted for stb0899 then? I believe the point was that the real issue was a noise problem in the stb6100 tuner driver, and that the stb0899 frontend patch just papered over this. > I was hoping to see it included before the merge window is closed again. > > [2] https://patchwork.kernel.org/patch/244201/ Please test the driver with the patch Manu refers to and report if there still are issues. The patch is now upstream in the 2.6.38 kernel, so testing it should be fairly easy. Do you still have this issue with a plain 2.6.38 driver? Bjørn -- 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: S2-3200 switching-timeouts on 2.6.38
Manu Abraham writes: > On Tue, Mar 22, 2011 at 1:46 AM, Randy Dunlap wrote: >> On Mon, 21 Mar 2011 20:46:23 +0100 Rico Tzschichholz wrote: >> >>> Hello, >>> >>> I would like to know if there is any intention to include this patch >>> soon? https://patchwork.kernel.org/patch/244201/ >> >> There are MANY posted but unmerged patches in patchwork from the linux-media >> mailing list. What is going on (or not going on) with patch merging? > > Actually, quite a lot of effort was put in to get that part right. It > does the reverse thing that's to be done. > The revamped version is here [1] If the issue persists still, then it > needs to be investigated further. > > [1] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html So the patch state should be "Rejected" and not "Under Review". Would certainly help us all if the patchwork state was updated whenever a patch actually was processed... Bjørn -- 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] [media] use pci_dev->revision
pci_setup_device() has saved the PCI revision in the pci_dev
struct since Linux 2.6.23. Use it.
Cc: Auke Kok
Signed-off-by: Bjørn Mork
---
I assume some of these drivers could have the revision
removed from their driver specific structures as well, but
I haven't done that to avoid unnecessary ABI changes.
drivers/media/common/saa7146_core.c|7 +--
drivers/media/dvb/b2c2/flexcop-pci.c |4 +---
drivers/media/dvb/bt8xx/bt878.c|2 +-
drivers/media/dvb/mantis/mantis_pci.c |5 ++---
drivers/media/video/bt8xx/bttv-driver.c|2 +-
drivers/media/video/cx18/cx18-driver.c |2 +-
drivers/media/video/cx23885/cx23885-core.c |2 +-
drivers/media/video/cx88/cx88-mpeg.c |2 +-
drivers/media/video/cx88/cx88-video.c |2 +-
drivers/media/video/ivtv/ivtv-driver.c |4 +---
drivers/media/video/saa7134/saa7134-core.c |2 +-
drivers/media/video/saa7164/saa7164-core.c |2 +-
drivers/media/video/zoran/zoran_card.c |2 +-
13 files changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/media/common/saa7146_core.c
b/drivers/media/common/saa7146_core.c
index 9f47e38..9af2140 100644
--- a/drivers/media/common/saa7146_core.c
+++ b/drivers/media/common/saa7146_core.c
@@ -378,12 +378,7 @@ static int saa7146_init_one(struct pci_dev *pci, const
struct pci_device_id *ent
dev->pci = pci;
/* get chip-revision; this is needed to enable bug-fixes */
- err = pci_read_config_dword(pci, PCI_CLASS_REVISION, &dev->revision);
- if (err < 0) {
- ERR(("pci_read_config_dword() failed.\n"));
- goto err_disable;
- }
- dev->revision &= 0xf;
+ dev->revision = pci->revision;
/* remap the memory from virtual to physical address */
diff --git a/drivers/media/dvb/b2c2/flexcop-pci.c
b/drivers/media/dvb/b2c2/flexcop-pci.c
index 227c020..326d2e8 100644
--- a/drivers/media/dvb/b2c2/flexcop-pci.c
+++ b/drivers/media/dvb/b2c2/flexcop-pci.c
@@ -290,10 +290,8 @@ static void flexcop_pci_dma_exit(struct flexcop_pci
*fc_pci)
static int flexcop_pci_init(struct flexcop_pci *fc_pci)
{
int ret;
- u8 card_rev;
- pci_read_config_byte(fc_pci->pdev, PCI_CLASS_REVISION, &card_rev);
- info("card revision %x", card_rev);
+ info("card revision %x", fc_pci->pdev->revision);
if ((ret = pci_enable_device(fc_pci->pdev)) != 0)
return ret;
diff --git a/drivers/media/dvb/bt8xx/bt878.c b/drivers/media/dvb/bt8xx/bt878.c
index 99d6209..b34fa95 100644
--- a/drivers/media/dvb/bt8xx/bt878.c
+++ b/drivers/media/dvb/bt8xx/bt878.c
@@ -460,7 +460,7 @@ static int __devinit bt878_probe(struct pci_dev *dev,
goto fail0;
}
- pci_read_config_byte(dev, PCI_CLASS_REVISION, &bt->revision);
+ bt->revision = dev->revision;
pci_read_config_byte(dev, PCI_LATENCY_TIMER, &lat);
diff --git a/drivers/media/dvb/mantis/mantis_pci.c
b/drivers/media/dvb/mantis/mantis_pci.c
index 10a432a..371558a 100644
--- a/drivers/media/dvb/mantis/mantis_pci.c
+++ b/drivers/media/dvb/mantis/mantis_pci.c
@@ -48,7 +48,7 @@
int __devinit mantis_pci_init(struct mantis_pci *mantis)
{
- u8 revision, latency;
+ u8 latency;
struct mantis_hwconfig *config = mantis->hwconfig;
struct pci_dev *pdev= mantis->pdev;
int err, ret = 0;
@@ -95,9 +95,8 @@ int __devinit mantis_pci_init(struct mantis_pci *mantis)
}
pci_read_config_byte(pdev, PCI_LATENCY_TIMER, &latency);
- pci_read_config_byte(pdev, PCI_CLASS_REVISION, &revision);
mantis->latency = latency;
- mantis->revision = revision;
+ mantis->revision = pdev->revision;
dprintk(MANTIS_ERROR, 0, "Mantis Rev %d [%04x:%04x], ",
mantis->revision,
diff --git a/drivers/media/video/bt8xx/bttv-driver.c
b/drivers/media/video/bt8xx/bttv-driver.c
index 91399c9..a97cf27 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -4303,7 +4303,7 @@ static int __devinit bttv_probe(struct pci_dev *dev,
goto fail0;
}
- pci_read_config_byte(dev, PCI_CLASS_REVISION, &btv->revision);
+ btv->revision = dev->revision;
pci_read_config_byte(dev, PCI_LATENCY_TIMER, &lat);
printk(KERN_INFO "bttv%d: Bt%d (rev %d) at %s, ",
bttv_num,btv->id, btv->revision, pci_name(dev));
diff --git a/drivers/media/video/cx18/cx18-driver.c
b/drivers/media/video/cx18/cx18-driver.c
index b1c3cbd..9d7f8f2 100644
--- a/drivers/media/video/cx18/cx18-driver.c
+++ b/drivers/media/video/cx18/cx18-driver.c
@@ -810,7 +810,7 @@ static int cx18_setup_pci(struct cx18 *cx, struct pci_dev
*pci_dev,
cmd |= PCI_COMMAND_MEMORY
Re: DVB driver for TerraTec H7 - how do I install them?
Torfinn Ingolfsen writes: > That is the point: TerraTec states that these are third-party drivers, > and they provide no support (as far as "we can't give you a better > answer"). > So I am just trying to find out where those drivers came from, and if > somebody has any experience / a how-to or something. > > This list seemed to to be the logical place to ask. Sure is. But even if you get past the build errors, you'll soon discover that Terratec "forgot" to include the necessary firmware as well. You can find it and some other hints in this thread: http://www.vdr-portal.de/board/thread.php?threadid=103040 Bjørn -- 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 03/16] ngene: Firmware 18 support
Oliver Endriss writes:
> + case 18:
> + size = 0;
> + fw_name = "ngene_18.fw";
> + break;
> }
>
> if (request_firmware(&fw, fw_name, &dev->pci_dev->dev) < 0) {
> @@ -1266,6 +1270,8 @@ static int ngene_load_firm(struct ngene *dev)
> ": Copy %s to your hotplug directory!\n", fw_name);
> return -1;
> }
> + if (size == 0)
> + size = fw->size;
> if (size != fw->size) {
> printk(KERN_ERR DEVICE_NAME
> ": Firmware %s has invalid size!", fw_name);
Just a stupid question: Why remove the size verification for version 18
while keeping it for the other firmware revisions?
Bjørn
--
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
Ozan Çağlayan writes: > Pazartesi 18 Ekim 2010 günü (saat 00:20:31) Mauro Carvalho Chehab şunları > yazmıştı: >> Hi, > >> Jun,21 2010: Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make > modules http://patchwork.kernel.org/patch/107147 Manu > > This was first spotted by me in February 2010 in this list. Then several > people in this list spotted that the modules were missing > MODULE_DEVICE_TABLE. > Well I thought that it should already be merged during the last 10 months but > I'm surprised to see that it's not. > > Note that without this patch those drivers are not automatically loaded by > udev so all other efforts of improving the mantis stuff stays insignificant > for end-users. well, the excellent Debian kernel team actually accepted this patch when adding the backported mantis driver to their 2.6.32 kernel, so at least Debian end users do get auto loading: bj...@nemi:~$ modinfo mantis filename: /lib/modules/2.6.32-5-amd64/kernel/drivers/media/dvb/mantis/mantis.ko license:GPL author: Manu Abraham description:MANTIS driver alias: pci:v1822d4E35sv1822sd0024bc*sc*i* alias: pci:v1822d4E35sv153Bsd1178bc*sc*i* alias: pci:v1822d4E35sv1AE4sd0002bc*sc*i* alias: pci:v1822d4E35sv1822sd0043bc*sc*i* alias: pci:v1822d4E35sv1822sd0008bc*sc*i* alias: pci:v1822d4E35sv153Bsd1179bc*sc*i* alias: pci:v1822d4E35sv1AE4sd0003bc*sc*i* alias: pci:v1822d4E35sv1AE4sd0001bc*sc*i* alias: pci:v1822d4E35sv1822sd0031bc*sc*i* alias: pci:v1822d4E35sv1822sd0014bc*sc*i* alias: pci:v1822d4E35sv1822sd0016bc*sc*i* depends: mantis_core,stv0299,i2c-core,stb0899,zl10353,tda10023,tda10021,stb6100,mb86a16,lnbp21,tda665x vermagic: 2.6.32-5-amd64 SMP mod_unload modversions parm: verbose:verbose startup messages, default is 1 (yes) (int) bj...@nemi:~$ dpkg -S /lib/modules/2.6.32-5-amd64/kernel/drivers/media/dvb/mantis/mantis.ko linux-image-2.6.32-5-amd64: /lib/modules/2.6.32-5-amd64/kernel/drivers/media/dvb/mantis/mantis.ko bj...@nemi:~$ apt-cache policy linux-image-2.6.32-5-amd64 linux-image-2.6.32-5-amd64: Installed: 2.6.32-28 Candidate: 2.6.32-28 Version table: *** 2.6.32-28 0 990 http://ftp.no.debian.org/debian/ squeeze/main amd64 Packages 600 http://ftp.no.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status (Note that the extensive "depends" shows that it's still missing one of the other critical patches) > Can this be fixed ASAP? At least it's now queued for 2.6.38: bj...@canardo:/usr/local/src/git/linux-2.6$ git shortlog origin..media_tree/staging/for_v2.6.38 drivers/media/dvb/mantis/ Ben Hutchings (1): [media] Mantis: Rename gpio_set_bits to mantis_gpio_set_bits Bjørn Mork (1): [media] Mantis: use dvb_attach to avoid double dereferencing on module removal David Härdeman (1): [media] ir-core: make struct rc_dev the primary interface Manu Abraham (1): [media] Mantis, hopper: use MODULE_DEVICE_TABLE Marko Ristola (1): [media] Mantis: append tasklet maintenance for DVB stream delivery Mauro Carvalho Chehab (4): [media] rc: rename the remaining things to rc_core [media] rc: Rename remote controller type to rc_type instead of ir_type [media] rc: Name RC keymap tables as rc_map_table [media] rc: use rc_map_ prefix for all rc map tables And I will submit it to stable as soon as it's in Linus' tree, unless someone beats me to it... Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.38] mantis for_2.6.38
Mauro Carvalho Chehab writes: > Em 12-11-2010 12:43, Bjørn Mork escreveu: >> >> git://git.mork.no/mantis.git for_2.6.38 > > Didn't work: > > git pull git://git.mork.no/mantis.git for_2.6.38 > fatal: Couldn't find remote ref for_2.6.38 Damn, sorry about that. Was supposed to be git://git.mork.no/mantis.git for_v2.6.38 Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.38] mantis for_2.6.38
Hello, I've been waiting for this list of patchwork patches to be included for quite a while, and have now taken the liberty to clean them up as necessary and add them to a git tree, based on the current media_tree for_v2.6.38 branch, with exceptions as noted below: > == mantis patches - Waiting for Manu Abraham > == > > Apr,15 2010: [5/8] ir-core: convert mantis from ir-functions.c > http://patchwork.kernel.org/patch/92961 David Härdeman > already applied as commit f0bdee26a2dc904c463bae1c2ae9ad06f97f100d > Jun,20 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, > improve http://patchwork.kernel.org/patch/107036 Marko Ristola > duplicate of http://patchwork.kernel.org/patch/118173 > Jun,20 2010: [2/2] DVB/V4L: mantis: remove unused files > http://patchwork.kernel.org/patch/107062 Bjørn Mork > Jun,20 2010: mantis: use dvb_attach to avoid double dereferencing on module > removal http://patchwork.kernel.org/patch/107063 Bjørn Mork > Jun,21 2010: Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make > modules http://patchwork.kernel.org/patch/107147 Manu Abraham > > Jul, 3 2010: mantis: Rename gpio_set_bits to mantis_gpio_set_bits > http://patchwork.kernel.org/patch/109972 Ben Hutchings > > Jul, 8 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, > improve http://patchwork.kernel.org/patch/110909 Marko Ristola > another duplicate of http://patchwork.kernel.org/patch/118173 > Jul, 9 2010: Mantis: append tasklet maintenance for DVB stream delivery > http://patchwork.kernel.org/patch/111090 Marko Ristola > > Jul,10 2010: Mantis driver patch: use interrupt for I2C traffic instead of > busy reg http://patchwork.kernel.org/patch/111245 Marko Ristola > > Jul,19 2010: Twinhan DTV Ter-CI (3030 mantis) > http://patchwork.kernel.org/patch/112708 Niklas Claesson > Missing Signed-off-by, and I'm also a bit confused wrt what the patch actually is. Needs further cleanup. > Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per > interrupt http://patchwork.kernel.org/patch/118173 Marko Ristola > > Oct,10 2010: [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 > demod http://patchwork.kernel.org/patch/244201 Tuxoholic > The following changes since commit af9f14f7fc31f0d7b7cdf8f7f7f15a3c3794aea3[media] IR: add tv power scancode to rc6 mce keymap are available in the git repository at: git://git.mork.no/mantis.git for_2.6.38 Ben Hutchings (1): V4L/DVB: mantis: Rename gpio_set_bits to mantis_gpio_set_bits Bjørn Mork (2): V4L/DVB: mantis: use dvb_attach to avoid double dereferencing on module removal V4L/DVB/V4L: mantis: remove unused files Manu Abraham (1): Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable Marko Ristola (3): V4L/DVB: mantis: append tasklet maintenance for DVB stream delivery Refactor Mantis DMA transfer to deliver 16Kb TS data per interrupt media: mantis: use interrupt for I2C traffic instead of busy registry polling tuxoho...@hotmail.de (1): V4L/DVB: faster DVB-S lock for mantis cards using stb0899 demod drivers/media/dvb/frontends/stb0899_algo.c | 33 +++-- drivers/media/dvb/mantis/hopper_cards.c|4 +- drivers/media/dvb/mantis/hopper_vp3028.c |6 +- drivers/media/dvb/mantis/mantis_cards.c| 18 ++- drivers/media/dvb/mantis/mantis_common.h |9 +- drivers/media/dvb/mantis/mantis_core.c | 235 drivers/media/dvb/mantis/mantis_core.h | 57 --- drivers/media/dvb/mantis/mantis_dma.c | 92 --- drivers/media/dvb/mantis/mantis_dvb.c | 17 ++- drivers/media/dvb/mantis/mantis_i2c.c | 128 drivers/media/dvb/mantis/mantis_ioc.c |4 +- drivers/media/dvb/mantis/mantis_ioc.h |2 +- drivers/media/dvb/mantis/mantis_vp1033.c |2 +- drivers/media/dvb/mantis/mantis_vp1034.c | 10 +- drivers/media/dvb/mantis/mantis_vp1041.c |6 +- drivers/media/dvb/mantis/mantis_vp2033.c |5 +- drivers/media/dvb/mantis/mantis_vp2040.c |4 +- drivers/media/dvb/mantis/mantis_vp3030.c |8 +- 18 files changed, 208 insertions(+), 432 deletions(-) Note that some of these patches will trigger checkpatch long line warnings due to deliberate choices. I have no strong feelings about reformatting them, but I believe the review is easier the less I have changed the original patchworks patch... I sincerely hope this will make your job easier. Thanks for reviewing, Bjørn -- 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: V4L/DVB/IR patches pending merge
Mauro Carvalho Chehab writes: > == mantis patches - Waiting for Manu Abraham > == > > Apr,15 2010: [5/8] ir-core: convert mantis from ir-functions.c > http://patchwork.kernel.org/patch/92961 David Härdeman > > Jun,20 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, > improve http://patchwork.kernel.org/patch/107036 Marko Ristola > > Jun,20 2010: [2/2] DVB/V4L: mantis: remove unused files > http://patchwork.kernel.org/patch/107062 Bjørn Mork > Jun,20 2010: mantis: use dvb_attach to avoid double dereferencing on module > removal http://patchwork.kernel.org/patch/107063 Bjørn Mork > Jun,21 2010: Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make > modules http://patchwork.kernel.org/patch/107147 Manu Abraham > > Jul, 3 2010: mantis: Rename gpio_set_bits to mantis_gpio_set_bits > http://patchwork.kernel.org/patch/109972 Ben Hutchings > > Jul, 8 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, > improve http://patchwork.kernel.org/patch/110909 Marko Ristola > > Jul, 9 2010: Mantis: append tasklet maintenance for DVB stream delivery > http://patchwork.kernel.org/patch/111090 Marko Ristola > > Jul,10 2010: Mantis driver patch: use interrupt for I2C traffic instead of > busy reg http://patchwork.kernel.org/patch/111245 Marko Ristola > > Jul,19 2010: Twinhan DTV Ter-CI (3030 mantis) > http://patchwork.kernel.org/patch/112708 Niklas Claesson > > Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per > interrupt http://patchwork.kernel.org/patch/118173 Marko Ristola > > Oct,10 2010: [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 > demod http://patchwork.kernel.org/patch/244201 Tuxoholic > > Jun,11 2010: stb0899: Removed an extra byte sent at init on DiSEqC bus > http://patchwork.kernel.org/patch/105621 Florent AUDEBERT > > > What to say? Well, still waiting for Manu to handle those patches. He said he > had a problem with > his dish and should be working on it next week. Let's hope we can finally > have some movement > on those patches in time for .37. Can we agree that this was yet another useless waiting exercise? Please start learning from experience. You are just repeating the same mistake again and again. Its rather frustrating to watch. Like watching a rat in a maze banging it's head against the same wall over and over again. Bjørn -- 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: linuxtv.org Wiki
Mauro Carvalho Chehab writes: > It is a wiki for a community effort. If you found it outdated, please help us > on keeping it uptodated. Yes, I know and I do wish I could write somethingmore up-to-date. My problem with that is that I do not feel I know enough about your requirements for driver submission to actually write anything on that. I just know barely enough to see that the information in the wiki must be outdated. Bjørn -- 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
linuxtv.org Wiki (was Re: cx23885 module)
Steven Toth writes: > On 10/22/10 9:02 AM, Daniel Lee Kim wrote: > >> One more question, is there a place I can go to learn how to compile just the >> cx23885.ko module? I am not able to compile only that module and so I have to >> wait until it compiles all the modules. I apologize as this is my first time >> tweaking a driver module. I've searched all over the net but have not found >> anyone who wrote about this. Thanks, > > The wiki at linuxtv.org should contain everything you need for > compiling, modifying and submitting patches. It should, but it does not. Following the path from www.linuxtv.org => V4L-DVB Wiki => Developer Section => How to submit patches you end up at http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches which states 'For V4L-DVB driver modules and/or documentation, patches should be created against the master V4L-DVB mercurial tree; for instructions on obtaining and building these sources, see the "How to Obtain, Build and Install V4L-DVB Device Drivers" article.' and the "How to Obtain, Build and Install V4L-DVB Device Drivers" article contains more of the same outdated information, with its references to to 2.6.16 backwards compatibility and Mercurial. For a new developer coming from the outside, this is worse than not having any information at all. Anyone reading this list will know that the above quote is plain misleading. But as a new developer you have no way to know whether other information in the same page, or even the whole Wiki, is just as misleading. So you cannot trust any of it. Making the Wiki useless. Never write documentation you do not plan to keep updated. Delete outdated documentation if you don't have time/resources to update it. Misleading documentation is much, much worse than no documentation. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 0/8] dsbr100: driver cleanup and fixes
David Ellingsworth writes: >> I will also check your patches soon. I have this old hardware at home. >> > > The sooner the better. These patches have been waiting for review > since May. I'd rather not have to rebase them and resend them a third > time. The current review process for drivers abandoned by the original author is not working. I really, really fail too see the problem with just letting a clean compile-tested patchset like yours through after, let's say, a week without any comments at all. That's probably the only way it is ever going to be tested by someone with the actual hardware. Worst case is that some of the patches will have to be reverted in the next release (and stable point release). That's not going to be problematic at all, given that the patchset only touches a single driver in maintenance mode. Please Mauro, can you implement some sort of deadline for your review cycles? Half a year is nowhere close to acceptable for non- controversial stuff like this. Spotting the non-controversial patches is easy BTW: Just look for those with no comments at all... Bjørn -- 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: MSI DigiVox Trio (Analog, DVB-C, DVB-T)
Matthias Larisch writes: > Hello! > > I recently bought a DigiVox Trio by MSI. This card contains the > following chips: > > nxp tda18271hdc2 (tuner) > micronas drx 3926ka3 (demodulator, 3in1) > em2884 > atmlh946 64c (eeprom) > micronas avf 4910ba1 > > so it is comparable to the Terratec Cinergy HTC USB XS HD and the > TerraTec H5. > > There is basically everything missing: > -EM2884 Support > -DRX 3926 Support > -AVF 4910 Support > > Is anyone working on any of them? I would really like to help to get > some of this stuff working! I know how to code and have much interest in > hardware/technology but no know how in linux-driver programming or > tv-card programming. If there is anything I could do just tell me. I believe Terratec's comment regarding the TerraTec H5 applies: http://linux.terratec.de/tv_en.html Sorry. It's like this: If you see "Micronas", then don't buy. Bjørn -- 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
saa7146 and tda100123 print debug messages at an inappropriate KERN_WARNING/KERN_ERR level
Hello, I do from time to time manage to hang my system in a way where IO-APIC interrupt processing halts. This is probably not related to V4L/DVB. In this situation, the saa7146 and tda10023 will of course fail (cannot blame them for that), and this failure makes them fill the console with pointless debug messages. Which I do blame them for, and is what I'd like to avoid. A typical example of such log messages: Aug 14 08:04:24 canardo kernel: [33080.584008] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.612006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.640005] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.656005] DVB: TDA10023(1): tda10023_writereg, writereg error (reg == 0x00, val == 0x32, ret == -5) Aug 14 08:04:24 canardo kernel: [33080.668007] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.696008] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.724018] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.752013] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.768008] DVB: TDA10023(1): tda10023_writereg, writereg error (reg == 0x00, val == 0x33, ret == -5) Aug 14 08:04:24 canardo kernel: [33080.780007] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.808009] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.836005] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.864005] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.880005] DVB: TDA10023(1): tda10023_readreg: readreg error (reg == 0x11, ret == -5) Aug 14 08:04:24 canardo kernel: [33080.892006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.920008] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.948006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.976006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.992041] DVB: TDA10023(1): tda10023_readreg: readreg error (reg == 0x11, ret == -5) Aug 14 08:04:24 canardo kernel: [33081.004005] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.032009] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.060006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.088006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.104004] tda10023: lock tuner fails Aug 14 08:04:24 canardo kernel: [33081.116007] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.144007] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.172007] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.26] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.228006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.256008] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.284006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.312008] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.328004] tda10023: unlock tuner fails Aug 14 08:04:24 canardo kernel: [33081.340006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.368008] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.396006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.424005] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.440026] DVB: TDA10023(1): tda10023_readreg: readreg error (reg == 0x03, ret == -5)
Re: [GIT PULL for 2.6.36] drivers/media updates
Mauro Carvalho Chehab writes: > Please pull from: > ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git > v4l_for_linus Not a single patch touching the mantis driver, although there have been several posted to the list over the last few months. Care to explain what that means? And *please* do not point to some "driver maintainer". There is none. If there were, then (s)he would have been active here. Bjørn -- 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] Mantis: append tasklet maintenance for DVB stream delivery
Marko Ristola writes:
> 20.06.2010 16:51, Bjørn Mork kirjoitti:
>> Note that mantis_core_exit() is never called. Unless I've missed
>> something, the drivers/media/dvb/mantis/mantis_core.{h,c} files can
>> just be deleted. They look like some development leftovers?
>>
>>
> I see. mantis_core.ko kernel module exists though.
> Maybe the mantis/Makefile references for mantis_core.c, mantis.c and
> hopper.c are just some leftovers too.
>
> I moved tasklet_enable/disable calls into mantis_dvb.c where almost
> all other tasklet code is located.
>
> So the following reasoning still holds:
>
> 1. dvb_dmxdev_filter_stop() calls mantis_dvb_stop_feed: mantis_dma_stop()
> 2. dvb_dmxdev_filter_stop() calls release_ts_feed() or some other
> filter freeing function.
> 3. tasklet: mantis_dma_xfer calls dvb_dmx_swfilter to copy DMA
> buffer's content into freed memory, accessing freed spinlocks.
> This case might occur while tuning into another frequency.
> Perhaps cdurrhau has found some version from this bug at
> http://www.linuxtv.org/pipermail/linux-dvb/2010-June/032688.html:
>> This is what I get on the remote console via IPMI:
>> 40849.442492] BUG: soft lockup - CPU#2 stuck for 61s! [section
>> handler:4617]
>
>
> New reasoning for the patch (same as the one above, but from higher level):
> After dvb-core has called mantis-fe->stop_feed(dvbdmxfeed) the last
> time (count to zero),
> no data should ever be copied with dvb_dmx_swfilter() by a tasklet:
> the target structure might be in an unusable state.
> Caller of mantis_fe->stop_feed() assumes that feeding is stopped after
> stop_feed() has been called, ie. dvb_dmx_swfilter()
> isn't running, and won't be called.
>
> There is a risk that dvb_dmx_swfilter() references freed resources
> (memory or spinlocks or ???) causing instabilities.
> Thus tasklet_disable(&mantis->tasklet) must be called inside of
> mantis-fe->stop_feed(dvbdmxfeed) when necessary.
>
> Signed-off-by: Marko Ristola
Tested-by: Bjørn Mork
I have successfully used this patch with a "Terratec Cinergy C PCI HD"
card in a system with a quad-core CPU and one other DVB-C card. I
believe it does improve stability under these conditions.
Don't know if this helps anyone, but I guess it can't harm in an
environment where there are noone willing to do even an Acked-by...
Bjørn
> diff --git a/drivers/media/dvb/mantis/mantis_dvb.c
> b/drivers/media/dvb/mantis/mantis_dvb.c
> index 99d82ee..a9864f7 100644
> --- a/drivers/media/dvb/mantis/mantis_dvb.c
> +++ b/drivers/media/dvb/mantis/mantis_dvb.c
> @@ -117,6 +117,7 @@ static int mantis_dvb_start_feed(struct
> dvb_demux_feed *dvbdmxfeed)
> if (mantis->feeds == 1) {
> dprintk(MANTIS_DEBUG, 1, "mantis start feed & dma");
> mantis_dma_start(mantis);
> +tasklet_enable(&mantis->tasklet);
> }
>
> return mantis->feeds;
> @@ -136,6 +137,7 @@ static int mantis_dvb_stop_feed(struct
> dvb_demux_feed *dvbdmxfeed)
> mantis->feeds--;
> if (mantis->feeds == 0) {
> dprintk(MANTIS_DEBUG, 1, "mantis stop feed and dma");
> +tasklet_disable(&mantis->tasklet);
> mantis_dma_stop(mantis);
> }
>
> @@ -216,6 +218,7 @@ int __devinit mantis_dvb_init(struct mantis_pci *mantis)
>
> dvb_net_init(&mantis->dvb_adapter, &mantis->dvbnet,
> &mantis->demux.dmx);
> tasklet_init(&mantis->tasklet, mantis_dma_xfer, (unsigned long)
> mantis);
> +tasklet_disable(&mantis->tasklet);
> if (mantis->hwconfig) {
> result = config->frontend_init(mantis, mantis->fe);
> if (result < 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
Re: [PATCH] Mantis DMA transfer cleanup, fixes data corruption and a race, improves performance. (signed-off this time)
Marko Ristola writes: > This is a resend of the exactly same patch > than I sent 2010-06-20, to sign off it. > > Signed-off-by: Marko M Ristola I have successfully used this patch with a "Terratec Cinergy C PCI HD" since Marko posted it on 2010-06-20. My impression is that it does improve driver stability, although I do not have any hard numbers to support that. Anyway, if it helps review, feel free to add Tested-by: Bjørn Mork to the patch. BTW, I have imported this patch in a local git repository for my own use, together with a few other mantis patches currently under review. Please let me know if any of you would want to pull from there to make the process easier. The repository is currently based on git://linuxtv.org/v4l-dvb.git devel/for_v2.6.36 Bjørn -- 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
The mantis driver is now in Debian
Just a FYI: Thanks to the excellent Debian kernel team, the mantis driver (backported from linux 2.6.34) is now included in Debian kernel images starting with version 2.6.32-16. This means that mantis based cards will work out of the box in the next stable Debian release, "squeeze". This info should probably go into the assorted wiki-pages with all sorts of outdated documentation on how to download and build the driver, but I'm not nuch of a wiki writer. I prefer putting it here for Google to find... I addition to the Debian kernel team, I owe a big thanks to those of you who have written the driver, helped pushing it upstream, and continue to support it. Thank you! Bjørn -- 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 (85 patches) and some misc notes about the devel procedures
Mauro Carvalho Chehab writes: > Em 01-07-2010 08:46, Bjørn Mork escreveu: >> Any chance of a new status update anytime soon? > > Updated today, after two or three weeks spent to handle the backlog. Great! Thanks. It's really appreciated, and I do note that it made quite a few people finally ack/nak the patches they were supposed to review. >> I'm particularily >> interested in getting a forced status change on any patch which was >> "under review" at the time of the last status message. I believe it's >> reasonable to expect two months "review" to be more than enough. If >> the patches are found unacceptable, then it's much better to have them >> rejected with a "please fix foo and resubmit" than the current total >> silence called "review". > > The patches marked as under review means that I'm expecting an action > from someone else (the patch author or the driver author/maintainer). Well, I'm of course not in a position to tell you how to do your job, so please regard this as a humble suggestion only... But I believe you make your job much harder by defining a number of "unofficial" driver maintainers and giving them indefinite slack, while at the same time *you* are the one having to keep track of all their outstanding patches. Either you delegate the maintainance properly, documenting it in MAINTAINERS and pointing there whenever someone sends a patch directly to you, or you might as well just do the ack/nak yourself based on the mailing list feedback. Putting yourself in the middle, taking the patch queue responsibility, but not the ack/nak responsibility, is just wasting your time on accounting and other boring work... I do believe that having the original author(s) maintain a driver is a very good idea as long as they are still actively maintaining it. But this must be based on actual maintainance, and not some misunderstood "ownership based on previous contributions". That's what the CREDITS file is for. Please look at other subsystems with a large number of old drivers, like e.g. networking. It's not like it's possible to have every tiny patch approved by the original author all the time. This does not hinder some newer drivers having very active official maintainers, like the Intel e1000(e) drivers, nor does it hinder the original authors from participating on the mailing list giving their comments and ack/nak if they want. But if they don't respond on the list, davem will just make a decision for himself without waiting for it. > So, if you have patches there still under review, you're helping us > if you direct your complains to the one that it is sitting on the top > of them. Oh, it's not so much my submissions bothering me (I have received some very good feedback on this list), but the fact that some drivers do not get any updates at all, even though patches are submitted to this mailing list. Not to mention the problem that patch submissions will (and do) stop due to the lack of any feedback whatsoever. Most people have better things to do than writing to /dev/null, and that's the feeling this queuing-for-original-author-review system leaves. Bjørn -- 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: V4L2 radio drivers for TI-WL7
Hans Verkuil writes: > On Friday 02 July 2010 09:01:34 Pavan Savoy wrote: >> Hi, >> >> We have/in process of developing a V4L2 driver for the FM Radio on the Texas >> Instruments WiLink 7 module. >> >> For transport/communication with the chip, we intend to use the shared >> transport driver currently staged in mainline at drivers/staging/ti-st/. >> >> To which tree should I generate patches against? is the tree >> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git >> fine ? to be used with the v4l_for_2.6.35 branch ? > > You patch against git://git.linuxtv.org/v4l-dvb.git. Could the MAINTAINERS entry be updated to refelct this? It currently has MEDIA INPUT INFRASTRUCTURE (V4L/DVB) M: Mauro Carvalho Chehab P: LinuxTV.org Project L: linux-media@vger.kernel.org W: http://linuxtv.org Q: http://patchwork.kernel.org/project/linux-media/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git S: Maintained F: Documentation/dvb/ F: Documentation/video4linux/ F: drivers/media/ F: include/media/ F: include/linux/dvb/ F: include/linux/videodev*.h Misleading documentation is even worse than no documentation Bjørn -- 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: TerraTec Cinergy Hybrid Stick [0ccd:00a5] - worth trying?
"Dirk Langner" writes:
> I'm really pissed that whenever I try to find a TV-USB-stick (analog
> in my case), it's not in the shops any longer or it's not listed on
> the linuxtv validated sticks. The names of the USB sticks are only
> slightly changed, which may mean, this is only a rebranding or a
> completely new hardware (even without name change). Therefore is the
> support for these sticks kind of a lottery and one first have to buy
> them, check the USB id and whether it's supported or not. Seems, that
> the product cycles are too short for us linux-users :(
>
> Ok, genug gekotzt, now to the facts: I've purchased the USB-stick
> TerraTec Cinergy Hybrid Stick, although it's a little older (1/2 year)
> it is still in the shops.
Well, Terratec are more helpful than most vendors, so that might not be
a bad choice. Did you see http://linux.terratec.de/ ?
I'm afraid your card isn't there, but...
> Vendor: TerraTec
> Model: Cinergy Hybrid Stick
> Vendor/Product ID: 0ccd:00a5
> Supports DVB-T and Analog Cable (tested already successful on Windows)
This card is supported by the tm6000 driver currently in staging:
bj...@canardo:~$ grep 00A5 /usr/local/src/git/linux-2.6/drivers/staging/tm6000/*
/usr/local/src/git/linux-2.6/drivers/staging/tm6000/tm6000-cards.c: {
USB_DEVICE(0x0ccd, 0x00A5), .driver_info =
TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE },
You may want to try that. I have no idea how well it works, if at all...
Bjørn
--
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 (85 patches) and some misc notes about the devel procedures
Mauro Carvalho Chehab writes: > My original idea were to send one of such emails per week, Nearly two months has passed since this message. I apologize if I missed something, but I have not seen another status update. Is it just me? Anyway, since the last status I've seen, 2.6.34 has been released, the 2.6.35 merge window has been open and then closed, and a number of new patches have been collected in https://patchwork.kernel.org/project/linux-media/list/ , many of which seem rather trivial. Any chance of a new status update anytime soon? I'm particularily interested in getting a forced status change on any patch which was "under review" at the time of the last status message. I believe it's reasonable to expect two months "review" to be more than enough. If the patches are found unacceptable, then it's much better to have them rejected with a "please fix foo and resubmit" than the current total silence called "review". Thanks, Bjørn -- 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: CI-Module not working on Technisat Cablestar HD2
Pascal Hahn writes: > Thanks for the feedback already. Do you know which kernel version this > driver is functional in out of the top of your head? > > I tried multiple kernels and had no luck getting it to work so far. If you are talking about the mantis driver in Linus' mainline kernels, then it isn't updated at all since it was merged. No need to try different kernels. They are all the same with respect to this driver. But the mantis driver went through a lot of changes during the very active development before it was merged, and the CA code used to be enabled at some point. But I do not know if it worked. And there were most likely very good reasons to disable it... Google will know. Bjørn -- 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: CI-Module not working on Technisat Cablestar HD2
Pascal Hahn writes:
> I can't see any of the expected mantis_ca_init but couldn't figure out
> in the code where that gets called.
I don't think it is. It was at some point, but it seems to be removed.
Most likely because it wasn't considered ready at the time this driver
was merged(?)
BTW, there is a potentional null dereference in mantis_irq_handler(),
which will do
ca = mantis->mantis_ca;
..
if (stat & MANTIS_INT_IRQ0) {
dprintk(MANTIS_DEBUG, 0, "<%s>", label[1]);
mantis->gpif_status = rst_stat;
wake_up(&ca->hif_write_wq);
schedule_work(&ca->hif_evm_work);
}
This will blow up if (stat & MANTIS_INT_IRQ0) is true, since
mantis->mantis_ca never is allocated. But then I guess that the
hardware should normally prevent (stat & MANTIS_INT_IRQ0) from being
true as long as the ca system isn't initiated, so this does not pose a
problem in practice.
Still doesn't look good.
Bjørn
--
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] Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable
VDR User writes: > Instead of copy&paste patches from Manu's tree, maybe it's better to > just wait for him to push all the changes into v4l. I certainly agree that having him push all the changes would be much better. And nothing would please me more than seeing this happen. But I do *not* agree that "just wait" is better. We have waited for 4 months. It did not work. Why do you think that waiting more will work better? > There have been > many bug fixes & improvements Manu has done that haven't been pushed > into v4l yet I guess there is. I only know of the two now 4 months old bug fixes in http://jusst.de/hg/mantis-v4l-dvb but there can of course be much more happening without me knowing. There could be other trees. But without pointers (we have a perfectly good MAINTAINERS for this), it's very hard to find such things. In fact, I do have some problems getting oriented in the V4L/DVB world. There seem to be a number of dead development trees scattered all around. But I guess that's to be expected, since there have been major reorganisations lately. To the better, IMHO. I'm looking forward to having Linus' kernel track the V4L/DVB development more closely, and not having to replace a whole subsystem every time I want to test a new driver. > and I think it's better to sync the entire driver instead > of cherry picking patches here & there. Yes. And I did hesitate to do this. But this one patch is really wanted to make the driver fully functional (users do expect PCI drivers to autoload nowadays). It could have been in 2.6.34. As it looks now, it won't make 2.6.35... Why wait? What's the point of collecting a large number (or small number for that sake) of patches in some development tree only very few developers even know exists? Push them upstream as soon as possible. The initial driver development is of course something else. I appreciate the need to develop something working before pushing it. But simple fixes like this one? Just push it. Bjørn -- 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] Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable
Thanks to Ozan ?a?layan for pointing it out
From: Manu Abraham
Signed-off-by: Manu Abraham
[bj...@mork.no: imported from
http://jusst.de/hg/mantis-v4l-dvb/raw-rev/3731f71ed6bf]
Signed-off-by: Bjørn Mork
Cc: sta...@kernel.org
---
This patch is so obviously correct that I do not know how to write it
differently.
It is copied from the mercurial repostory at http://jusst.de/hg/mantis-v4l-dvb/
where it has been resting for more than 4 months. I certainly hope everyone is
OK with me just forwarding it like this... My only agenda is a fully functional
mantis driver in the kernel.
This patch does nothing but add all the relevant device id's for these two
drivers, so
I consider it material for stable as well.
Bjørn
drivers/media/dvb/mantis/hopper_cards.c |2 ++
drivers/media/dvb/mantis/mantis_cards.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/mantis/hopper_cards.c
b/drivers/media/dvb/mantis/hopper_cards.c
index d073c61..1bf03ac 100644
--- a/drivers/media/dvb/mantis/hopper_cards.c
+++ b/drivers/media/dvb/mantis/hopper_cards.c
@@ -250,6 +250,8 @@ static struct pci_device_id hopper_pci_table[] = {
{ }
};
+MODULE_DEVICE_TABLE(pci, hopper_pci_table);
+
static struct pci_driver hopper_pci_driver = {
.name = DRIVER_NAME,
.id_table = hopper_pci_table,
diff --git a/drivers/media/dvb/mantis/mantis_cards.c
b/drivers/media/dvb/mantis/mantis_cards.c
index 16f1708..64970cf 100644
--- a/drivers/media/dvb/mantis/mantis_cards.c
+++ b/drivers/media/dvb/mantis/mantis_cards.c
@@ -280,6 +280,8 @@ static struct pci_device_id mantis_pci_table[] = {
{ }
};
+MODULE_DEVICE_TABLE(pci, mantis_pci_table);
+
static struct pci_driver mantis_pci_driver = {
.name = DRIVER_NAME,
.id_table = mantis_pci_table,
--
1.7.1
--
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] V4L/DVB: mantis: use dvb_attach to avoid double dereferencing on module removal
Convert the driver to use the dvb_attach macro to avoid the hard dependency
on the frontend drivers. The hard dependecy will result in loading a
number of unused frontends, and unwanted automatic dereferencing.
This fixes a bug where unloading the mantis driver will derefence any
attached frontend twice, which will cause an oops if the same frontend is
used by another driver.
Signed-off-by: Bjørn Mork
Cc: sta...@kernel.org
---
drivers/media/dvb/mantis/hopper_vp3028.c |2 +-
drivers/media/dvb/mantis/mantis_vp1033.c |2 +-
drivers/media/dvb/mantis/mantis_vp1034.c |2 +-
drivers/media/dvb/mantis/mantis_vp1041.c |6 +++---
drivers/media/dvb/mantis/mantis_vp2033.c |4 ++--
drivers/media/dvb/mantis/mantis_vp2040.c |4 ++--
drivers/media/dvb/mantis/mantis_vp3030.c |4 ++--
7 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/media/dvb/mantis/hopper_vp3028.c
b/drivers/media/dvb/mantis/hopper_vp3028.c
index 96674c7..567ed24 100644
--- a/drivers/media/dvb/mantis/hopper_vp3028.c
+++ b/drivers/media/dvb/mantis/hopper_vp3028.c
@@ -57,7 +57,7 @@ static int vp3028_frontend_init(struct mantis_pci *mantis,
struct dvb_frontend *
if (err == 0) {
msleep(250);
dprintk(MANTIS_ERROR, 1, "Probing for 10353 (DVB-T)");
- fe = zl10353_attach(&hopper_vp3028_config, adapter);
+ fe = dvb_attach(zl10353_attach, &hopper_vp3028_config, adapter);
if (!fe)
return -1;
diff --git a/drivers/media/dvb/mantis/mantis_vp1033.c
b/drivers/media/dvb/mantis/mantis_vp1033.c
index 4a723bd..deec927 100644
--- a/drivers/media/dvb/mantis/mantis_vp1033.c
+++ b/drivers/media/dvb/mantis/mantis_vp1033.c
@@ -173,7 +173,7 @@ static int vp1033_frontend_init(struct mantis_pci *mantis,
struct dvb_frontend *
msleep(250);
dprintk(MANTIS_ERROR, 1, "Probing for STV0299 (DVB-S)");
- fe = stv0299_attach(&lgtdqcs001f_config, adapter);
+ fe = dvb_attach(stv0299_attach, &lgtdqcs001f_config, adapter);
if (fe) {
fe->ops.tuner_ops.set_params = lgtdqcs001f_tuner_set;
diff --git a/drivers/media/dvb/mantis/mantis_vp1034.c
b/drivers/media/dvb/mantis/mantis_vp1034.c
index 8e6ae55..bf62338 100644
--- a/drivers/media/dvb/mantis/mantis_vp1034.c
+++ b/drivers/media/dvb/mantis/mantis_vp1034.c
@@ -82,7 +82,7 @@ static int vp1034_frontend_init(struct mantis_pci *mantis,
struct dvb_frontend *
msleep(250);
dprintk(MANTIS_ERROR, 1, "Probing for MB86A16 (DVB-S/DSS)");
- fe = mb86a16_attach(&vp1034_mb86a16_config, adapter);
+ fe = dvb_attach(mb86a16_attach, &vp1034_mb86a16_config,
adapter);
if (fe) {
dprintk(MANTIS_ERROR, 1,
"found MB86A16 DVB-S/DSS frontend @0x%02x",
diff --git a/drivers/media/dvb/mantis/mantis_vp1041.c
b/drivers/media/dvb/mantis/mantis_vp1041.c
index d1aa2bc..38a436c 100644
--- a/drivers/media/dvb/mantis/mantis_vp1041.c
+++ b/drivers/media/dvb/mantis/mantis_vp1041.c
@@ -316,14 +316,14 @@ static int vp1041_frontend_init(struct mantis_pci
*mantis, struct dvb_frontend *
if (err == 0) {
mantis_frontend_soft_reset(mantis);
msleep(250);
- mantis->fe = stb0899_attach(&vp1041_stb0899_config, adapter);
+ mantis->fe = dvb_attach(stb0899_attach, &vp1041_stb0899_config,
adapter);
if (mantis->fe) {
dprintk(MANTIS_ERROR, 1,
"found STB0899 DVB-S/DVB-S2 frontend @0x%02x",
vp1041_stb0899_config.demod_address);
- if (stb6100_attach(mantis->fe, &vp1041_stb6100_config,
adapter)) {
- if (!lnbp21_attach(mantis->fe, adapter, 0, 0))
+ if (dvb_attach(stb6100_attach, mantis->fe,
&vp1041_stb6100_config, adapter)) {
+ if (!dvb_attach(lnbp21_attach, mantis->fe,
adapter, 0, 0))
dprintk(MANTIS_ERROR, 1, "No LNBP21
found!");
}
} else {
diff --git a/drivers/media/dvb/mantis/mantis_vp2033.c
b/drivers/media/dvb/mantis/mantis_vp2033.c
index 10ce817..06da0dd 100644
--- a/drivers/media/dvb/mantis/mantis_vp2033.c
+++ b/drivers/media/dvb/mantis/mantis_vp2033.c
@@ -132,7 +132,7 @@ static int vp2033_frontend_init(struct mantis_pci *mantis,
struct dvb_frontend *
msleep(250);
dprintk(MANTIS_ERROR, 1, "Probing for CU1216 (DVB-C)");
- fe = tda10021_attach(&vp2033_tda1002x_cu1216_config,
+ fe = dvb_attach(tda10021_attach, &vp2033_tda1002x_cu1216_config,
[PATCH 2/2] DVB/V4L: mantis: remove unused files
The files mantis_core.c and mantis_core.h are not used anywhere, so
delete them
Signed-off-by: Bjørn Mork
---
drivers/media/dvb/mantis/mantis_core.c | 238
drivers/media/dvb/mantis/mantis_core.h | 57
2 files changed, 0 insertions(+), 295 deletions(-)
delete mode 100644 drivers/media/dvb/mantis/mantis_core.c
delete mode 100644 drivers/media/dvb/mantis/mantis_core.h
diff --git a/drivers/media/dvb/mantis/mantis_core.c
b/drivers/media/dvb/mantis/mantis_core.c
deleted file mode 100644
index 8113b23..000
--- a/drivers/media/dvb/mantis/mantis_core.c
+++ /dev/null
@@ -1,238 +0,0 @@
-/*
- Mantis PCI bridge driver
-
- Copyright (C) Manu Abraham (abraham.m...@gmail.com)
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-*/
-
-#include "mantis_common.h"
-#include "mantis_core.h"
-#include "mantis_vp1033.h"
-#include "mantis_vp1034.h"
-#include "mantis_vp1041.h"
-#include "mantis_vp2033.h"
-#include "mantis_vp2040.h"
-#include "mantis_vp3030.h"
-
-static int read_eeprom_byte(struct mantis_pci *mantis, u8 *data, u8 length)
-{
- int err;
- struct i2c_msg msg[] = {
- {
- .addr = 0x50,
- .flags = 0,
- .buf = data,
- .len = 1
- }, {
- .addr = 0x50,
- .flags = I2C_M_RD,
- .buf = data,
- .len = length
- },
- };
-
- err = i2c_transfer(&mantis->adapter, msg, 2);
- if (err < 0) {
- dprintk(verbose, MANTIS_ERROR, 1,
- "ERROR: i2c read: < err=%i d0=0x%02x d1=0x%02x >",
- err, data[0], data[1]);
-
- return err;
- }
-
- return 0;
-}
-
-static int write_eeprom_byte(struct mantis_pci *mantis, u8 *data, u8 length)
-{
- int err;
-
- struct i2c_msg msg = {
- .addr = 0x50,
- .flags = 0,
- .buf = data,
- .len = length
- };
-
- err = i2c_transfer(&mantis->adapter, &msg, 1);
- if (err < 0) {
- dprintk(verbose, MANTIS_ERROR, 1,
- "ERROR: i2c write: < err=%i length=0x%02x d0=0x%02x,
d1=0x%02x >",
- err, length, data[0], data[1]);
-
- return err;
- }
-
- return 0;
-}
-
-static int get_mac_address(struct mantis_pci *mantis)
-{
- int err;
-
- mantis->mac_address[0] = 0x08;
- err = read_eeprom_byte(mantis, &mantis->mac_address[0], 6);
- if (err < 0) {
- dprintk(verbose, MANTIS_ERROR, 1, "Mantis EEPROM read error");
-
- return err;
- }
- dprintk(verbose, MANTIS_ERROR, 0,
- "MAC Address=[%02x:%02x:%02x:%02x:%02x:%02x]\n",
- mantis->mac_address[0], mantis->mac_address[1],
- mantis->mac_address[2], mantis->mac_address[3],
- mantis->mac_address[4], mantis->mac_address[5]);
-
- return 0;
-}
-
-#define MANTIS_MODEL_UNKNOWN "UNKNOWN"
-#define MANTIS_DEV_UNKNOWN "UNKNOWN"
-
-struct mantis_hwconfig unknown_device = {
- .model_name = MANTIS_MODEL_UNKNOWN,
- .dev_type = MANTIS_DEV_UNKNOWN,
-};
-
-static void mantis_load_config(struct mantis_pci *mantis)
-{
- switch (mantis->subsystem_device) {
- case MANTIS_VP_1033_DVB_S: /* VP-1033 */
- mantis->hwconfig = &vp1033_mantis_config;
- break;
- case MANTIS_VP_1034_DVB_S: /* VP-1034 */
- mantis->hwconfig = &vp1034_mantis_config;
- break;
- case MANTIS_VP_1041_DVB_S2: /* VP-1041 */
- case TECHNISAT_SKYSTAR_HD2:
- mantis->hwconfig = &vp1041_mantis_config;
- break;
- case MANTIS_VP_2033_DVB_C: /* VP-2033 */
- mantis->hwconfig = &vp2033_mantis_config;
- break;
- case MANTIS_VP_2040_DVB_C: /* VP
Re: Cinergy C PCI HD with current v4l-dvb - PATCH for review/pull included
Bjørn Mork writes: > Marko Ristola writes: > >> 4. There is some problem with rmmod mantis, do lsmod: >> Module Size Used by >> tda100215486 4294967291 >> modprobe mantis >> tda100215486 4294967292 mantis >> So the reference count from mantis to tda10021 gets corrupted at rmmod. >> I have Fedora 13 kernel, 2.6.33.5-124.fc13.x86_64 > > FWIW, I do not see this running a Debian kernel (2.6.32-5-amd64) with a > backported mantis driver (from 2.6.35-rc1). > > Module Size Used by > tda100214774 1 mantis > # rmmod mantis > tda100214774 0 > # modprobe mantis > tda100214774 1 mantis Sorry, you are of course quite right, Marko: There is such a bug, and it will in fact cause an oops if this double dereferencing causes a frontend driver which is in use to be unloaded. But it will only affect the frontend drivers actually in use, which is why I didn't see it above (my card uses tda10023). The cause of this (and the unwanted loading of a gazillion unused frontend drivers), is that the mantis driver doesn't use dvb_attach. I will follow up with a patch to fix this Bjørn -- 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] Mantis: append tasklet maintenance for DVB stream delivery
Marko Ristola writes:
> The following schedule might also be a problem:
> 1. mantis_core_exit: mantis_dma_stop()
> 2. mantis_core_exit: mantis_dma_exit().
Note that mantis_core_exit() is never called. Unless I've missed
something, the drivers/media/dvb/mantis/mantis_core.{h,c} files can
just be deleted. They look like some development leftovers?
Bjørn
--
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: Cinergy C PCI HD with current v4l-dvb - PATCH for review/pull included
[ I think this should have been posted to linux-media@vger.kernel.org instead ] Marko Ristola writes: > Hello all interested in a robust Mantis driver. > > I have done some Mantis DMA fixes about two to four years ago > into v4l-dvb/linux/drivers/dvb/media/mantis/mantis_dma.c, > but they were discarded then, but the problems remained. > Those fixes helped at least one individual with Cinergy C PCI HD card > too by lessening the number > of artifacts and making the card usable. I sent the patches for many > Finnish people at those years. I find this very interesting. I have two DVB-C cards, where one of them is a Terratec Cinergy C, and I do see the occasional stuck CPUs. Never realized that the mantis driver might be the cause of that. > For Mauro and other maintainers - the patch in this email is now > against current Mercurial http://linuxtv.org/hg/v4l-dvb branch. > What do you think about this patch? Could you apply it? > I accept that this code may be added to Linux Kernel, or somewhere > else, licensed as GPLv2. > This code is fully written by me (Marko Ristola). > Signed-off-by: Marko Ristola I am not Mauro (or other maintainers :-), but I guess you will have a much better chance getting this properly reviewed if you move to git, split up the patch according to your very good 4 point description, and use that description as a commit message for the patches. This will also allow the rest of us to test the effect of each issue independently. > The patch does two things (other two things are just thoughts, related > to robustness): > 1. Don't flush 64K garbage at stream start, occurs if mantis_dma_start > is run more than once. > This fix could be done with altering only about two lines of code by > fixing the broken DMA RISC program code. > (Bug description: At line[0] RISC IRQ will store line=15 on current > code, causing copying of lines between 0 and 14, and next time 15 from > previous DVB TS stream (total 64K garbage). After that line=0 contains > current stream, no garbage. > Bug fix description: RISC program must store at interrupt the active > line variable's value, instead of ( (line - 1) mod 16)). This sounds like a real bug. Maybe a candidate for stable as well? > On my patch, it seems, that risc_step=0 point could be used for the > interrupt instead of risc_step=1, thus making the code a bit easier to > understand. > > 2. Alter DMA transfer so, that each DMA transfer copies only complete > packets (either 188 or 204 bytes) with each DMA transfer. > The hypothesis is that if a DMA transfer transfers only a part of the > 188/204 sized packet, > that packet gets corrupted (last bytes of 2048 sized block). > My DMA transfers are aligned by 64 bytes in CPU memory (DMA buffer > start + multiple of 16x(188 or 204)). I cannot really understand how such corruption could happen, unless there are other bugs here? And if there are, then anything hiding them would be bad... > 3. tasklet_enable/ tasklet_disable for DMA start/stop is commented out > on my patch. > I think that tasklet enabling maintenance should be done at these > points, but I don't know > whether the lack of those might cause spin lock failures. Lack of > these might > cause problems while switching channels (EPG search switches frequency). Sounds reasonable. Did you try it? > 4. There is some problem with rmmod mantis, do lsmod: > Module Size Used by > tda100215486 4294967291 > modprobe mantis > tda100215486 4294967292 mantis > So the reference count from mantis to tda10021 gets corrupted at rmmod. > I have Fedora 13 kernel, 2.6.33.5-124.fc13.x86_64 FWIW, I do not see this running a Debian kernel (2.6.32-5-amd64) with a backported mantis driver (from 2.6.35-rc1). Module Size Used by tda100214774 1 mantis # rmmod mantis tda100214774 0 # modprobe mantis tda100214774 1 mantis > The second modification is the reason for the big number of changes. > This is also the patch, that isn't easily acceptable, because it is hard > to proof that the packets do get corrupted at DMA transfer cutting > points, or that the hard lockups/reboots are caused > by the DMA transfer misalignment by 188/204 bytes. > The reasoning for the fix is, that without this alignment change there > were too many artefacts (VDR DVB > recordings lost sound after a while, thus VDR recording feature was > unusable). This sounds a bit like magic to me. Any idea why such a change would make any difference? > But with these modifications on recordings the sound was > usable. Picture artefacts weren't so fatal at real time, even > though on Windows side there were much less picture artefacts. I haven't really thought much about artefacts, but I do notice a sharp high pitched sound now and then. Might be a symptom? > For historical reasons, I need still to modprobe mantis by hand, > and then the drivers get probed and loaded. Usua
Re: Is anybody working on TechniSat CableStar Combo HD CI USB device?
Markus Rechberger writes: > Trident is also still improving the quality of their driver and > firmware, it very much makes > sense that they handle their driver especially since those DRX drivers > are very complex > (basically too complex for being handled by the community, the drivers > would just > end up somewhere unmaintained). Ouch. That makes me wonder about the state of the Windows drivers for those devices... Better stay away from them, I guess. Bjørn -- 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: Terratec Cinergy C DVB-C card problems
Rune Evjen writes: > For some reason this module is not automatically loaded during boot > with ubuntu, but I added 'modprobe mantis' to /etc/rc.local so that it > loads during bootup. The mantis driver in linux 2.6.33-2.6.35-rc1 is still missing this patch: http://jusst.de/hg/mantis-v4l-dvb/raw-rev/3731f71ed6bf You can apply that on top of your Ubuntu 2.6.33 kernel if you want to add auto loading. Bjørn -- 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: Terratec Cinergy C DVB-C card problems
Billy Brumley writes: > I've got a terratec cinergy c dvb-c card, fresh install of ubuntu > 10.04 lucid i386. Card is here: > > http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_C_DVB-C I don't know what's wrong with your installation, but you may want to try installing the mantis driver without completely replacing the dvb-core. FYI, the mantis driver will be included in the next Debian 2.6.32 based kernel release thanks to the excellent Debian kernel team: http://bugs.debian.org/57724 . I guess that means that it will be available in Unbuntu soon as well. Anyway, the patch from that bug report should easily apply to any 2.6.32 kernel without having to mess with the whole DVB system. Bjørn -- 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: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34
Hans de Goede writes: > I notice in the original bug report that you claim that the lower framerate > clip with 2.6.34 has "much better quality", could you define this a bit > better. Sorry for the confusion, but this wasn't me. I just read the bug report. Bjørn -- 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: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34
Mauro Carvalho Chehab writes: > Em 02-06-2010 18:09, Andrew Morton escreveu: >> On Sun, 30 May 2010 14:29:55 GMT >> bugzilla-dae...@bugzilla.kernel.org wrote: >> >>> https://bugzilla.kernel.org/show_bug.cgi?id=16077 >> >> 2.6.33 -> 2.6.34 performance regression in dvb webcam frame rates. > > I don't think this is a regression. Probably, the new code is allowing a > higher > resolution. As the maximum bandwidth from the sensor to the USB bridge doesn't > change, and a change from QVGA to VGA implies on 4x more pixels per frame, as > consequence, the number of frames per second will likely reduce by a factor > of 4x. > > I've asked the reporter to confirm what resolutions he is setting on 2.6.33 > and on 2.6.34, just to double check if my thesis is correct. Well, the two video clips attached to the bug shows the same resolution but a much, much lower video (and overall) bitrate in 2.6.34. Output from mediainfo: General Complete name: 2.6.33-02063303-generic #02063303.ogv Format : OGG File size: 672 KiB Duration : 6s 331ms Overall bit rate : 870 Kbps Video ID : 20423689 (0x137A409) Format : Theora Duration : 6s 333ms Bit rate : 714 Kbps Width: 320 pixels Height : 240 pixels Display aspect ratio : 4:3 Frame rate : 30.000 fps Bits/(Pixel*Frame) : 0.310 Stream size : 552 KiB (82%) Writing library : Xiph.Org libtheora 1.1 20090822 (Thusnelda) Audio ID : 1459180980 (0x56F955B4) Format : Vorbis Format settings, Floor : 1 Duration : 6s 331ms Bit rate mode: Constant Bit rate : 112 Kbps Channel(s) : 2 channels Sampling rate: 44.1 KHz Stream size : 86.6 KiB (13%) Writing library : libVorbis 20090709 (UTC 2009-07-09) General Complete name: 2.6.34-999-generic #201005121008.ogv Format : OGG File size: 276 KiB Duration : 15s 424ms Overall bit rate : 146 Kbps Video ID : 12773534 (0xC2E89E) Format : Theora Duration : 15s 433ms Bit rate : 19.8 Kbps Width: 320 pixels Height : 240 pixels Display aspect ratio : 4:3 Frame rate : 30.000 fps Bits/(Pixel*Frame) : 0.009 Stream size : 37.2 KiB (14%) Writing library : Xiph.Org libtheora 1.1 20090822 (Thusnelda) Audio ID : 1010301390 (0x3C37F9CE) Format : Vorbis Format settings, Floor : 1 Duration : 15s 424ms Bit rate mode: Constant Bit rate : 112 Kbps Channel(s) : 2 channels Sampling rate: 44.1 KHz Stream size : 211 KiB (76%) Writing library : libVorbis 20090709 (UTC 2009-07-09) Bjørn -- 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: ideal DVB-C PCI/e card?
Markus Rechberger writes: > There are a few DVB-C/T/(analogTV) USB devices, our USB Sticks are > well supported and tested with Linux. Sorry, I wasn't precise enough. You are correct. There are USB DVB-C sticks with Linux support. The thing is that my requirements aren't really Linux support, but *open source* support. I should be more careful saying so. Sorry for the confusion. Bjørn -- 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: ideal DVB-C PCI/e card?
Jed writes: > Just curious, why did you pick VDR over MythTV? > I would rather use the later + OSCam (maybe) if feasible. It's mostly because I had no experience with either and tried VDR first. And then I never got around to trying MythTV. I don't know if MythTV would fit. Probably would. My impression was that it was mainly targeted at media portal + analogue TV while VDR was made for live DVB from the start, which was why I trid VDR first. One of my requirements was that I could tune to any channel by simply accessing a streaming URL, i.e. without touching any portal at all. I started my small project mainly because I have ethernet around the house but not coax, and I got a request for live TV two floors away from the nearest coax cable. VDR with the streamdev plugin turned out to be an excellent headless streaming server. It is perfectly suitable for the more primitive streaming display devices, like popcornhour boxes or TV sets with ethernet, which are great for watching live streams but suck when it comes to portal "browsing". One application I looked at initially was mumudvb, since it is targeted towards live streaming. I must admit that I liked the idea of just multicasting all channels all the time, but unfortunately that would have required 7 or 8 tuners just to get the "free" channels from my cable operator. Which of course would be out of the question even if dual DVB-C cards existed. And more HD channels are probably going to make this even more difficult. And I really won't have more than a couple of channel "consumers" anyway so it would most certainly be way overkill. But fun though :-) Bjørn -- 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: [stable] [PATCH v2] V4L/DVB: budget: Oops: "BUG: unable to handle kernel NULL pointer dereference"
Greg KH writes: > Any reason why this patch isn't in Linus's tree yet? Not to my knowledge. Anyone? I must admit that I do not entirely understand the flow of bugfix patches for V4L/DVB. There doesn't seem to be any collection point for those, only a git tree for development and a mercurial tree for a backported version of the development tree. Is that correct, or is the reason this patch isn't merged that I missed something here? I do note that MAINTAINERS point to git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git but this tree doesn't seem to be actually used? No bugfixes for any part of the subsystem in 2.5 months seems unlikely... Sorry if I've missed this in any of the V4L development docs. I'd really appreciate it if anyone pointed me in the right direction. Bjørn -- 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: mantis crashes
Vidar Tyldum Hansen writes: > Things left to try hardware-wise is to switch to a different PCI slot, > but I guess I'll go down the new kernel route... I'll have to do some > research regarding v4l versions in .31, .32 and .33 to figure out to > which kernel I can 'backport' mantis without replacing v4l completely. I attached a patch for 2.6.32 to http://bugs.debian.org/577264 This keeps most of the existing DVB subsystem intact, only adding new files with the exception of the necessary one-liner in tda10021.c to avoid unwanted binding to tda10023. I based the patch on the driver in 2.6.34-rc4, but updating it with newer versions should be trivial. Bjørn -- 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: mantis crashes
Vidar Tyldum Hansen writes: > Hello list, > > I am having issues with my TerraTec Cinergy C DVB-C, described in detail > here: https://bugzilla.kernel.org/show_bug.cgi?id=15750 > > The essence is that machine would reboot or hang at random intervals if > the card is actively used (mythtv or tvheadend running for instance). > Just loading the mantis module and let the card idle does not trigger > anything. Does the 2.6.31-20-generic Ubuntu kernel come bundled with the mantis driver, or did you build this yourself? If so, from where and which version? AFAIK, mantis wasn't included in mainline until 2.6.33. I've just filed a wishlist bug for Debian's 2.6.32 so I'd really be interested in any Ubuntu work on this... > I am trying to figure out if this is a driver or hardware issue, and by > enabling more verbose logging on the mantis module I ended up with the > syslog output attached to the bug report. It shows binary garbage and > function calls for parts of the kernel not in use by the machine in > question right before the crash occurred. > > I have not been able to find a different card to test with yet. > > So, based on this, is it possible to conclude whom to blame for the > crash? FWIW I have exactly the same card with no such problems observed. I am using a standard Debian 2.6.32-4-amd64 kernel with mantis driver taken from vanilla 2.6.34-rc4 (after patching mantis-input.c to compensate for the recent ir layer changes). This is also what I submitted to Debian in the wishlist bug report. Bjørn -- 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] V4L/DVB: budget-av: wait longer for frontend to power on
Mauro Carvalho Chehab writes: > Oliver Endriss wrote: > >> Mauro, please do not apply this patch! > > Don't worry, I won't apply this patch. >> >> Afaik there is no tuner which takes 5 seconds to initialize. (And if >> there was one, it would be a bad idea to add a 5s delay for all tuners!) > > Yes, that's my point: if is there such hardware, the fix should touch > only on the hardware with that broken design. > > (btw, there is one tuner that takes almost 30 seconds to initialize: > the firmware load for xc3028 on tm6000 rev A should go on slow speed, > otherwise, it fails loading - the i2c implementation on tm6000 were > really badly designed) > >> The saa7146_i2c_writeout errors are likely caused by broken hardware. > > I think so. You are so right both of you. Please drop the patch. I believe this problem was yet another symptom of my faulty SATA hard drive. The driver is working fine with the default 100 ms timeout after replacing that drive. Sorry about all the unnecessary work I created for you, and thanks for taking the time to review this even though you suspected user/hardware error. Bjørn -- 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] V4L/DVB: saa7146: IRQF_DISABLED causes only trouble
Ehh, this is very embarrassing, but please disregard all my statements about a hanging system related to IRQF_DISABLED. It turns out that I've had a faulty SATA hard drive which probably have caused all these problems. I do not understand the inner workings of the SATA hardware and software, but it appears that this drive has been able to block interrupts for a considerable time without SMART detecting any error at all. I wrongly suspected saa7146 to be the cause because these problems appeared after adding the saa7146 hardware. But that was probably just a coincidence (or maybe not really, only unrelated: I suspect that the problem was triggered by the powercycle when adding this card) The drive has now been replaced, and I will start verifying that use of saa7146 with IRQF_DISABLED does not in fact pose any real problems at all. I still find the discussion about it's usefulness interesting though... Andy Walls writes: > Given your /proc/interrupts output, the first handler registered would > be the pata_jmicron module's irq handler. So interrupts will be enabled > when the saa7146 module's irq handler runs. > > So this is puzzling to me as to why IRQF_DISABLED for the saa7146 module > matters at all for your situation. It should be ignored. Yes, it probably was ignored. Sorry for not being able to sort that out earlier. >> The discussion about which is correct, always disabled or always >> enabled, is way out of my league. But I believe that current drivers >> have to adapt to the current kernel default, and that is always enabled. > > Why do you believe that? Because any other driver sharing the interrupt otherwise will cause unpredictable results. But your suggestions that one should be able to detect the current state and make system level policy decision would make that argument void, and are generally much better solutions. > For hardware devices which, after a short period of time, overwrite > their information about what caused the interrupt (i.e. CX23418), > yielding to another IRQ handler increases the potential for losing > information (i.e. losing tack of video buffers). Sure, I can see that problem. But you can't avoid it unless you find some way to ensure that IRQF_DISABLED is enforced. And today, that would mean not sharing at all, would it not? > Really the kernel needs to be smarter about identifying these cases: > > 1. an IRQ line where all the drivers request IRQF_DISABLED > 2. an IRQ line where all the drivers request IRQs remain enabled > 3. an IRQ line where the drivers have mixed requests > > Case 3 is the only case that requires resolution. It's a system level > decision that the user should be able to set as to whether he wants one > type of behavior or the other on that interrupt line. The kernel can > never know absolutely what's right for the user in case 3. Sounds like a solution to me. And the current warning should be disabled in case 1, as the behaviour is predictable. But this means that the kernel also need to be smart enough to notice both when the case changes from 1 to 3 and from 2 to 3. >> No, maybe it's not. But doesn't the fact that you can't predict the >> actual effect of the IRQF_DISABLED flag tell you that using it is wrong? > > No. Not being able to reliably predict an outcome, doesn't really speak > to the correctness of settings that appear to affect the outcome > (correlation is not causation). OK. > I do know that on any particular machine, one should be able to know > whether IRQF_DISABLED will be ignored or enforced on all IRQ handlers on > an interrupt line. Yes, that would be useful. Like it is now, you have to inspect the source code and the current driver load order to know the actual state. Bjørn -- 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] V4L/DVB: saa7146: Making IRQF_DISABLED or IRQF_SHARED optional
Oliver Endriss writes: > Bjørn Mork wrote: >> As discussed many times, e.g. in http://lkml.org/lkml/2007/7/26/401 >> mixing IRQF_DISABLED with IRQF_SHARED may cause unpredictable and >> unexpected results. >> >> Add a module parameter to allow fine tuning the request_irq >> flags based on local system requirements. Some may need to turn >> off IRQF_DISABLED to be able to share interrupt with drivers >> needing interrupts enabled, while others may want to turn off >> IRQF_SHARED to ensure that IRQF_DISABLED has an effect. > > NAK. We should not add module parameters for this kind of crap. OK. You are perfectly right. This is something that Should Just Work(tm) without any user intervention. Sorry for adding confusion. > Let's check whether IRQF_DISABLED is really required. > Afaics it can be removed. Thanks for reviewing. > @all: > Please check whether the first patch causes any problems. Anyone? FWIW, I do have real stabilitity problems with IRQF_DISABLED. Removing it seem to have resolved these, and I have not noticed any regressions. If it matters, this is tested on a quad core system with two DVB-C cards (one budget-av and one mantis): bj...@canardo:~$ lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0] (rev 02) 00:01.0 PCI bridge [0604]: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root Port [8086:29c1] (rev 02) 00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 02) 00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 02) 00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 02) 00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 02) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 02) 00:1c.4 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 [8086:2948] (rev 02) 00:1c.5 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 [8086:294a] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 02) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 02) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 02) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 02) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 92) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801IB (ICH9) LPC Interface Controller [8086:2918] (rev 02) 00:1f.2 SATA controller [0106]: Intel Corporation 82801IB (ICH9) 4 port SATA AHCI Controller [8086:2923] (rev 02) 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 02) 01:00.0 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit Ethernet Controller [8086:105e] (rev 06) 01:00.1 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit Ethernet Controller [8086:105e] (rev 06) 02:00.0 Ethernet controller [0200]: Atheros Communications L1 Gigabit Ethernet Adapter [1969:1048] (rev b0) 03:00.0 SATA controller [0106]: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller [197b:2363] (rev 03) 03:00.1 IDE interface [0101]: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller [197b:2363] (rev 03) 04:00.0 RAID bus controller [0104]: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller [1095:3132] (rev 01) 05:00.0 Multimedia controller [0480]: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] [1822:4e35] (rev 01) 05:01.0 Multimedia controller [0480]: Philips Semiconductors SAA7146 [1131:7146] (rev 01) 05:02.0 PCI bridge [0604]: Intel Corporation 80960RP (i960RP) Microprocessor/Bridge [8086:0960] (rev 05) 05:02.1 Memory controller [0580]: Intel Corporation 80960RP (i960RP) Microprocessor [8086:1960] (rev 05) 05:03.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] (rev c0) 06:00.0 VGA compatible controller [0300]: ATI Technologies Inc 3D Rage IIC 215IIC [Mach64 GT IIC] [1002:4756] (rev 7a) canardo:/tmp# lspci -vvnns 5:0 05:00.0 Multimedia controller [0480]: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] [1822:4e35] (rev 01) Subsystem: TERRATEC Electronic GmbH Device [153b:1178] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- http://vger.kernel.org/majordomo-info.html
[PATCH v2 for v4l-dvb master] V4L/DVB: budget: Oops: "BUG: unable to handle kernel NULL pointer dereference"
Never call dvb_frontend_detach if we failed to attach a frontend. This fixes
the following oops:
[8.172997] DVB: registering new adapter (TT-Budget S2-1600 PCI)
[8.209018] adapter has MAC addr = 00:d0:5c:cc:a7:29
[8.328665] Intel ICH :00:1f.5: PCI INT B -> GSI 17 (level, low) -> IRQ
17
[8.328753] Intel ICH :00:1f.5: setting latency timer to 64
[8.562047] DVB: Unable to find symbol stv090x_attach()
[8.562117] BUG: unable to handle kernel NULL pointer dereference at 00ac
[8.562239] IP: [] dvb_frontend_detach+0x4/0x67 [dvb_core]
Ref http://bugs.debian.org/575207
Also clean up if we are unable to register the tuner and LNB drivers
Signed-off-by: Bjørn Mork
Reported-by: Fladischer Michael
---
This version should apply to to git://linuxtv.org/v4l-dvb.git master on
top of commit 30b8f0787e51a3ab0c447e0e3bf4aadc7caf9ffd.
It is otherwise identical to the v2 patch for the upstream and stable
kernel repositories.
drivers/media/dvb/ttpci/budget.c | 56 -
1 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/drivers/media/dvb/ttpci/budget.c b/drivers/media/dvb/ttpci/budget.c
index fccb6ad..918679e 100644
--- a/drivers/media/dvb/ttpci/budget.c
+++ b/drivers/media/dvb/ttpci/budget.c
@@ -628,32 +628,36 @@ static void frontend_init(struct budget *budget)
&tt1600_stv6110x_config,
&budget->i2c_adap);
- tt1600_stv090x_config.tuner_init =
ctl->tuner_init;
- tt1600_stv090x_config.tuner_sleep =
ctl->tuner_sleep;
- tt1600_stv090x_config.tuner_set_mode =
ctl->tuner_set_mode;
- tt1600_stv090x_config.tuner_set_frequency =
ctl->tuner_set_frequency;
- tt1600_stv090x_config.tuner_get_frequency =
ctl->tuner_get_frequency;
- tt1600_stv090x_config.tuner_set_bandwidth =
ctl->tuner_set_bandwidth;
- tt1600_stv090x_config.tuner_get_bandwidth =
ctl->tuner_get_bandwidth;
- tt1600_stv090x_config.tuner_set_bbgain=
ctl->tuner_set_bbgain;
- tt1600_stv090x_config.tuner_get_bbgain=
ctl->tuner_get_bbgain;
- tt1600_stv090x_config.tuner_set_refclk=
ctl->tuner_set_refclk;
- tt1600_stv090x_config.tuner_get_status=
ctl->tuner_get_status;
-
- /* call the init function once to initialize
- tuner's clock output divider and demod's
- master clock */
- if (budget->dvb_frontend->ops.init)
-
budget->dvb_frontend->ops.init(budget->dvb_frontend);
-
- dvb_attach(isl6423_attach,
- budget->dvb_frontend,
- &budget->i2c_adap,
- &tt1600_isl6423_config);
-
- } else {
- dvb_frontend_detach(budget->dvb_frontend);
- budget->dvb_frontend = NULL;
+ if (ctl) {
+ tt1600_stv090x_config.tuner_init
= ctl->tuner_init;
+ tt1600_stv090x_config.tuner_sleep
= ctl->tuner_sleep;
+ tt1600_stv090x_config.tuner_set_mode
= ctl->tuner_set_mode;
+
tt1600_stv090x_config.tuner_set_frequency = ctl->tuner_set_frequency;
+
tt1600_stv090x_config.tuner_get_frequency = ctl->tuner_get_frequency;
+
tt1600_stv090x_config.tuner_set_bandwidth = ctl->tuner_set_bandwidth;
+
tt1600_stv090x_config.tuner_get_bandwidth = ctl->tuner_get_bandwidth;
+ tt1600_stv090x_config.tuner_set_bbgain
= ctl->tuner_set_bbgain;
+ tt1600_stv090x_config.tuner_get_bbgain
= ctl->tuner_get_bbgain;
+ tt1600_stv090x_config.tuner_set_refclk
= ctl->tuner_set_refclk;
+ tt1600_stv090x_config.tuner_get_status
= ctl->tuner_get_status;
+
+ /* call the init function once to
initialize
+ tuner's clock output divider and
demod's
+ master clock */
+
[PATCH v2] V4L/DVB: budget: Oops: "BUG: unable to handle kernel NULL pointer dereference"
Never call dvb_frontend_detach if we failed to attach a frontend. This fixes
the following oops:
[8.172997] DVB: registering new adapter (TT-Budget S2-1600 PCI)
[8.209018] adapter has MAC addr = 00:d0:5c:cc:a7:29
[8.328665] Intel ICH :00:1f.5: PCI INT B -> GSI 17 (level, low) -> IRQ
17
[8.328753] Intel ICH :00:1f.5: setting latency timer to 64
[8.562047] DVB: Unable to find symbol stv090x_attach()
[8.562117] BUG: unable to handle kernel NULL pointer dereference at 00ac
[8.562239] IP: [] dvb_frontend_detach+0x4/0x67 [dvb_core]
Ref http://bugs.debian.org/575207
Also clean up if we are unable to register the tuner and LNB drivers
Signed-off-by: Bjørn Mork
Cc: sta...@kernel.org
Reported-by: Fladischer Michael
---
Oliver Endriss writes:
> Could you please extend your patch in a way
> that it will also catch, if
> - dvb_attach(stv6110x_attach,...)
> - dvb_attach(isl6423_attach,...)
> fail?
OK. Attempting, although I have no clue whether such failures are really
fatal or not...
This is version 2 of this patch, adding cleanup in case we fail to register
the two submodules used by this card/frontend. I'm not certain that this
additional cleanup is appropriate for stable as any failure to register
these will be handled cleanly AFAICS. But I have no way to test this.
This patch should apply cleanly to 2.6.32, 2.6.33, 2.6.34-rc2
This does not apply cleanly to git://linuxtv.org/v4l-dvb.git master. I will
followup with a similar patch for that branch
Please apply to stable if appropriate. If not, please apply version 1
of the patch, which fixes only the oops condition.
drivers/media/dvb/ttpci/budget.c | 42 -
1 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/drivers/media/dvb/ttpci/budget.c b/drivers/media/dvb/ttpci/budget.c
index e48380c..4666c1e 100644
--- a/drivers/media/dvb/ttpci/budget.c
+++ b/drivers/media/dvb/ttpci/budget.c
@@ -627,25 +627,29 @@ static void frontend_init(struct budget *budget)
&tt1600_stv6110x_config,
&budget->i2c_adap);
- tt1600_stv090x_config.tuner_init =
ctl->tuner_init;
- tt1600_stv090x_config.tuner_set_mode =
ctl->tuner_set_mode;
- tt1600_stv090x_config.tuner_set_frequency =
ctl->tuner_set_frequency;
- tt1600_stv090x_config.tuner_get_frequency =
ctl->tuner_get_frequency;
- tt1600_stv090x_config.tuner_set_bandwidth =
ctl->tuner_set_bandwidth;
- tt1600_stv090x_config.tuner_get_bandwidth =
ctl->tuner_get_bandwidth;
- tt1600_stv090x_config.tuner_set_bbgain=
ctl->tuner_set_bbgain;
- tt1600_stv090x_config.tuner_get_bbgain=
ctl->tuner_get_bbgain;
- tt1600_stv090x_config.tuner_set_refclk=
ctl->tuner_set_refclk;
- tt1600_stv090x_config.tuner_get_status=
ctl->tuner_get_status;
-
- dvb_attach(isl6423_attach,
- budget->dvb_frontend,
- &budget->i2c_adap,
- &tt1600_isl6423_config);
-
- } else {
- dvb_frontend_detach(budget->dvb_frontend);
- budget->dvb_frontend = NULL;
+ if (ctl) {
+ tt1600_stv090x_config.tuner_init
= ctl->tuner_init;
+ tt1600_stv090x_config.tuner_set_mode
= ctl->tuner_set_mode;
+
tt1600_stv090x_config.tuner_set_frequency = ctl->tuner_set_frequency;
+
tt1600_stv090x_config.tuner_get_frequency = ctl->tuner_get_frequency;
+
tt1600_stv090x_config.tuner_set_bandwidth = ctl->tuner_set_bandwidth;
+
tt1600_stv090x_config.tuner_get_bandwidth = ctl->tuner_get_bandwidth;
+ tt1600_stv090x_config.tuner_set_bbgain
= ctl->tuner_set_bbgain;
+ tt1600_stv090x_config.tuner_get_bbgain
= ctl->tuner_get_bbgain;
+ tt1600_stv090x_config.tuner_set_refclk
= ctl->tuner_set_refclk;
+ tt1600_stv090x_config.tuner_get_status
= ctl->tuner_get_status;
+
+ if (dvb_attach(isl6423_attach,
+
[PATCH] V4L/DVB: budget: Oops: "BUG: unable to handle kernel NULL pointer dereference"
Never call dvb_frontend_detach if we failed to attach a frontend. This fixes
the following oops, which will be triggered by a missing stv090x module:
[8.172997] DVB: registering new adapter (TT-Budget S2-1600 PCI)
[8.209018] adapter has MAC addr = 00:d0:5c:cc:a7:29
[8.328665] Intel ICH :00:1f.5: PCI INT B -> GSI 17 (level, low) -> IRQ
17
[8.328753] Intel ICH :00:1f.5: setting latency timer to 64
[8.562047] DVB: Unable to find symbol stv090x_attach()
[8.562117] BUG: unable to handle kernel NULL pointer dereference at 00ac
[8.562239] IP: [] dvb_frontend_detach+0x4/0x67 [dvb_core]
Ref http://bugs.debian.org/575207
Signed-off-by: Bjørn Mork
Cc: sta...@kernel.org
Cc: 575...@bugs.debian.org
---
This patch should apply cleanly to 2.6.32, 2.6.33, 2.6.34-rc2 and with an
offset to git://linuxtv.org/v4l-dvb.git
Please apply to all of them
drivers/media/dvb/ttpci/budget.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/ttpci/budget.c b/drivers/media/dvb/ttpci/budget.c
index e48380c..95a463c 100644
--- a/drivers/media/dvb/ttpci/budget.c
+++ b/drivers/media/dvb/ttpci/budget.c
@@ -643,9 +643,6 @@ static void frontend_init(struct budget *budget)
&budget->i2c_adap,
&tt1600_isl6423_config);
- } else {
- dvb_frontend_detach(budget->dvb_frontend);
- budget->dvb_frontend = NULL;
}
}
break;
--
1.5.6.5
--
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] V4L/DVB: saa7146: Making IRQF_DISABLED or IRQF_SHARED optional
As discussed many times, e.g. in http://lkml.org/lkml/2007/7/26/401
mixing IRQF_DISABLED with IRQF_SHARED may cause unpredictable and
unexpected results.
Add a module parameter to allow fine tuning the request_irq
flags based on local system requirements. Some may need to turn
off IRQF_DISABLED to be able to share interrupt with drivers
needing interrupts enabled, while others may want to turn off
IRQF_SHARED to ensure that IRQF_DISABLED has an effect.
Signed-off-by: Bjørn Mork
---
I have reiterated through the previous discussions to find the real reason
why IRQF_DISABLED is kept in assorted V4L/DVB drivers, and do now understand
that my first approach was a bit too optimistically simple
The argument for IRQF_DISABLED seems to be that running with interrupts
enabled may cause multimedia capture devices to drop frames. Which sounds
plausible.
But there are two problems with this:
1) as long as you use IRQF_SHARED there is no guarantee that IRQF_DISABLED
has any effect, and you may still drop frames
2) drivers sharing the interrupt may assume that interrupts are enabled
The actual effect is highly system dependant and may change with every
little change to the PCI system, including adding or removing cards,
moving cards around, or even upgrading the kernel without doing any
hardware or driver change at all.
So I propose adding a module parameter allowing a system administrator to
configure a more predictable behaviour by turning off either IRQF_DISABLED or
IRQF_SHARED. Those with enough interrupt lines and a wish to enforce
IRQF_DISABLED to avoid dropping frames may disable IRQF_SHARED, and those
experiencing problems with sharing drivers may try to disable one or the
other.
The default is kept as IRQF_SHARED | IRQF_DISABLED
drivers/media/common/saa7146_core.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/media/common/saa7146_core.c
b/drivers/media/common/saa7146_core.c
index 982f000..21127f6 100644
--- a/drivers/media/common/saa7146_core.c
+++ b/drivers/media/common/saa7146_core.c
@@ -26,9 +26,13 @@ DEFINE_MUTEX(saa7146_devices_lock);
static int saa7146_num;
unsigned int saa7146_debug;
+static int irqflags = IRQF_SHARED | IRQF_DISABLED;
module_param(saa7146_debug, uint, 0644);
MODULE_PARM_DESC(saa7146_debug, "debug level (default: 0)");
+module_param(irqflags, int, 0444);
+MODULE_PARM_DESC(irqflags, "request_irq flags - default: 0xA0 = 0x20
(IRQF_DISABLED) | 0x80 (IRQF_SHARED)");
+
#if 0
static void dump_registers(struct saa7146_dev* dev)
@@ -416,7 +420,7 @@ static int saa7146_init_one(struct pci_dev *pci, const
struct pci_device_id *ent
saa7146_write(dev, MC2, 0xf800);
/* request an interrupt for the saa7146 */
- err = request_irq(pci->irq, interrupt_hw, IRQF_SHARED | IRQF_DISABLED,
+ err = request_irq(pci->irq, interrupt_hw, irqflags,
dev->name, dev);
if (err < 0) {
ERR(("request_irq() failed.\n"));
--
1.5.6.5
--
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] V4L/DVB: saa7146: IRQF_DISABLED causes only trouble
Andy Walls writes: > On Sun, 2010-03-21 at 21:08 +0100, Bjørn Mork wrote: >> As discussed many times, e.g. in http://lkml.org/lkml/2007/7/26/401 >> mixing IRQF_DISABLED with IRQF_SHARED just doesn't make sense. >> >> Remove IRQF_DISABLED to avoid random unexpected behaviour. >> >> Ever since I started using the saa7146 driver, I've had occasional >> soft lockups. I do not have any real evidence that the saa7146 >> driver is the cause, but the lockups are gone after removing the >> IRQF_DISABLED flag from this driver. >> >> On my system, this driver shares an irq17 with the pata_jmicron >> driver: >> >> 17: 2115 1060594228448193902 IO-APIC-fasteoi >> pata_jmicron, saa7146 (0) >> >> This may be a mitigating factor. >> >> Signed-off-by: Bjørn Mork >> Cc: sta...@kernel.org > > And here are some more recent discussions: > > http://lkml.org/lkml/2009/11/30/215 > http://lkml.org/lkml/2009/3/2/33 > http://lkml.org/lkml/2009/3/2/225 > http://www.mail-archive.com/ivtv-de...@ivtvdriver.org/msg06319.html > http://www.mail-archive.com/ivtv-de...@ivtvdriver.org/msg06362.html > > And the ones on the LKML seem prettry inconclusive to me. OK, I don't really feel up to arguing against any of those. But the argument seems to be more along the lines of whether the requirement should be always disabled or always enabled. Most people seem to agree that it should be one or the other, and *not* a mix, and hence that the IRQF_DISABLED should go away (but possibly be replaced by disabled as default behaviour). The discussion about which is correct, always disabled or always enabled, is way out of my league. But I believe that current drivers have to adapt to the current kernel default, and that is always enabled. The patch in http://lkml.org/lkml/2009/3/2/33 might be the correct solution eventually, but attempting to implement this in a handful drivers is not going to work. By using IRQF_DISABLED you are only triggering the bugs which makes Linus hesitate to take that patch, in a very random and rather undebuggable way. That's not good. To quote one of Linus' followups to http://lkml.org/lkml/2009/3/2/33 (in http://lkml.org/lkml/2009/3/2/186): "The whole - and only - point is that there are drivers that are _known_ to require non-IRQF_DISABLED semantics. IDE is one such one." *This* is what makes using IRQF_SHARED || IRQF_DISABLED risky, IMHO. You can't currently guarantee that you don't share the line with one of those drivers. > If the saa7146 driver was registered second, then this change should > have no effect on your system. > > If the saa7146 driver was registered first, then this can cause the > saa7146 driver's interrupt handler to be interrupted. I doubt the > saa7146 driver is prepared for this contingency. > > I doubt that this is the "proper" fix for your problem. No, maybe it's not. But doesn't the fact that you can't predict the actual effect of the IRQF_DISABLED flag tell you that using it is wrong? Removing it will at least provide a predictable outcome. The problem you miss above is how the other drivers sharing this interrupt will deal with the, to them, unexpected occasional disabled interrupts. How the heck do you ensure that they can handle it? I assume the real fix would be to ensure that the saa7146 interrupt handler can be interrupted. I have no idea how to to that. Do you know why it can't be interrupted? It doesn't look particularily uninterruptable to me. And as you say: It will be interrupted even with the IRQF_DISABLED flag. The alternative to making ensure that the saa7146 interrupt handler can be interrupted is really not keeping IRQF_DISABLED, but - making sure that *every* interrupt handler in the kernel can run with interrupts disabled, and - change the default to running with interrupts disabled I believe it's easier to modify the saa7146 driver... > Does the "soft lockup" put an Oops or BUG message in dmesg > or /var/log/messages? > > What precisely do you mean by "soft lockup"? I mean CPU cores getting stuck, like: Mar 20 01:02:56 canardo kernel: [96555.15] BUG: soft lockup - CPU#0 stuck for 61s! [lmcoretemp:7424] Mar 20 01:02:56 canardo kernel: [96603.480497] BUG: soft lockup - CPU#1 stuck for 61s! [kswapd0:47] Mar 20 01:02:56 canardo kernel: [96603.480999] BUG: soft lockup - CPU#2 stuck for 61s! [rndc:9119] Mar 20 01:02:56 canardo kernel: [96620.659996] BUG: soft lockup - CPU#0 stuck for 61s! [lmcoretemp:7424] Mar 20 01:02:56 canardo kernel: [96668.976496] BUG: soft lockup - CPU#1 stuck for 61s! [kswapd0:47] Mar 20 01:02:56 canardo kernel: [96668.976995] BUG: soft lockup - CPU#2 stuck for 61s! [rndc:9119] Mar 2
[PATCH] V4L/DVB: saa7146: IRQF_DISABLED causes only trouble
As discussed many times, e.g. in http://lkml.org/lkml/2007/7/26/401
mixing IRQF_DISABLED with IRQF_SHARED just doesn't make sense.
Remove IRQF_DISABLED to avoid random unexpected behaviour.
Ever since I started using the saa7146 driver, I've had occasional
soft lockups. I do not have any real evidence that the saa7146
driver is the cause, but the lockups are gone after removing the
IRQF_DISABLED flag from this driver.
On my system, this driver shares an irq17 with the pata_jmicron
driver:
17: 2115 1060594228448193902 IO-APIC-fasteoi
pata_jmicron, saa7146 (0)
This may be a mitigating factor.
Signed-off-by: Bjørn Mork
Cc: sta...@kernel.org
---
drivers/media/common/saa7146_core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/common/saa7146_core.c
b/drivers/media/common/saa7146_core.c
index 982f000..038dcc8 100644
--- a/drivers/media/common/saa7146_core.c
+++ b/drivers/media/common/saa7146_core.c
@@ -416,7 +416,7 @@ static int saa7146_init_one(struct pci_dev *pci, const
struct pci_device_id *ent
saa7146_write(dev, MC2, 0xf800);
/* request an interrupt for the saa7146 */
- err = request_irq(pci->irq, interrupt_hw, IRQF_SHARED | IRQF_DISABLED,
+ err = request_irq(pci->irq, interrupt_hw, IRQF_SHARED,
dev->name, dev);
if (err < 0) {
ERR(("request_irq() failed.\n"));
--
1.5.6.5
--
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] V4L/DVB: budget-av: wait longer for frontend to power on
Some devices need much more time than 100ms to power on, leading to a
failure to enable the frontend on the first attempt. Instead we get
[ 38.194200] saa7146: register extension 'budget_av'.
[ 38.253828] budget_av :05:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ
17
[ 38.601572] saa7146: found saa7146 @ mem c9c6ac00 (revision 1, irq
17) (0x1894,0x0022).
[ 39.251324] saa7146 (0): dma buffer size 1347584
[ 39.306757] DVB: registering new adapter (KNC1 DVB-C MK3)
[ 39.462785] adapter failed MAC signature check
[ 39.516159] encoded MAC from EEPROM was
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
[ 39.892397] KNC1-0: MAC addr = 00:09:d6:6d:94:5c
[ 40.552028] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.580044] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.608026] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.636027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.652026] DVB: TDA10023(-1): tda10023_writereg, writereg error (reg ==
0x00, val == 0x33, ret == -5)
[ 40.664027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.692027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.720027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.748027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.764025] DVB: TDA10023(-1): tda10023_readreg: readreg error (reg == 0x1a,
ret == -5)
[ 40.764067] budget-av: A frontend driver was not found for device
[1131:7146] subsystem [1894:0022]
Unloading and the reloading the driver will work around this problem. But
it can also be easily fixed by increasing the wait period after powering
on. The optimum value is unclear to me. But I've found the 500 ms is not
enough. 5 s is enough for my card, but might be more than actually needed.
However, as long as we don't handle this failure more gracefully, then the
timeout need to be long enough.
Signed-off-by: Bjørn Mork
Cc: sta...@kernel.org
---
Hello,
I have recently bought a KNC1 clone, called Mystique CaBiX-C2. This card
would just not work on reboot in my system, giving the errors shown above.
Unloading the module and then loading it again always fixed the problem,
indicating that it was just a startup timing problem.
As you can see, the i2c timeouts are from the frontend attach function,
tda10023_attach():
/* wakeup if in standby */
tda10023_writereg (state, 0x00, 0x33);
/* check if the demod is there */
if ((tda10023_readreg(state, 0x1a) & 0xf0) != 0x70) goto error;
cleary showing that it just isn't responding yet at that point.
I first tried increasing the msleep() to 500 ms, but still got the same
error. Increasing it to 5000 ms helped, however, and made my card work
from boot. I have not tried any values inbetween, as each attempt AFAIK
requires a reboot to get the card into the "cold state" where it will
fail.
dmesg with the patch installed:
[ 37.786955] saa7146: register extension 'budget_av'.
[ 37.846592] budget_av :05:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ
17
[ 37.933318] saa7146: found saa7146 @ mem c9c70c00 (revision 1, irq
17) (0x1894,0x0022).
[ 38.037851] saa7146 (0): dma buffer size 1347584
[ 38.093224] DVB: registering new adapter (KNC1 DVB-C MK3)
[ 38.194254] adapter failed MAC signature check
[ 38.247527] encoded MAC from EEPROM was
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
[ 38.622678] KNC1-0: MAC addr = 00:09:d6:6d:94:5c
[ 43.765897] DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)...
[ 43.851587] budget-av: ci interface initialised.
Please consider this patch. Or maybe it is possible to wait smarter,
testing actual frontend power status instead of just a blind sleep?
I've also included a CC stable as I've had the same problem with the 2.6.32
and 2.6.33 stable drivers.
Bjørn
drivers/media/dvb/ttpci/budget-av.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/ttpci/budget-av.c
b/drivers/media/dvb/ttpci/budget-av.c
index 983672a..b53bd80 100644
--- a/drivers/media/dvb/ttpci/budget-av.c
+++ b/drivers/media/dvb/ttpci/budget-av.c
@@ -1215,7 +1215,7 @@ static void frontend_init(struct budget_av *budget_av)
saa7146_setgpio(saa, 0, SAA7146_GPIO_OUTLO);
/* Wait for PowerON */
- msleep(100);
+ msleep(5000);
/* additional setup necessary for the PLUS cards */
switch (saa->pci->subsystem_device) {
--
1.5.6.5
--
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
