Re: [PATCH] uvcvideo: Don't call vb2 mmap and get_unmapped_area with queue lock held

2015-03-09 Thread Bjørn Mork
Bjørn Mork bj...@mork.no writes:
 Laurent Pinchart laurent.pinch...@ideasonboard.com 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

2015-02-23 Thread Bjørn Mork
Laurent Pinchart laurent.pinch...@ideasonboard.com 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

2015-02-05 Thread Bjørn Mork
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: [811a1b48] 
kernfs_remove_by_name_ns+0x6b/0x87

but task is already holding lock:
 (queue-mutex){+.+.+.}, at: [a06b3aea] 
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){+.+.+.}:
   [81079571] lock_acquire+0x149/0x191
   [813d9f26] mutex_lock_nested+0x6b/0x39e
   [a06b3b32] uvc_queue_mmap+0x24/0x48 [uvcvideo]
   [a06b3f87] uvc_v4l2_mmap+0x42/0x49 [uvcvideo]
   [a05f710c] v4l2_mmap+0x43/0x83 [videodev]
   [81116cd9] mmap_region+0x26f/0x44b
   [81117177] do_mmap_pgoff+0x2c2/0x32b
   [81102115] vm_mmap_pgoff+0x7a/0xad
   [8111584c] SyS_mmap_pgoff+0x162/0x195
   [81007265] SyS_mmap+0x16/0x22
   [813dc152] system_call_fastpath+0x12/0x17

- #1 (mm-mmap_sem){++}:
   [81079571] lock_acquire+0x149/0x191
   [8110e9c5] might_fault+0x81/0xa4
   [811a23b3] kernfs_fop_write+0xb7/0x149
   [81143b28] vfs_write+0xa2/0x122
   [81143d82] SyS_write+0x50/0x85
   [813dc152] system_call_fastpath+0x12/0x17

- #0 (s_active#37){.+}:
   [81078c1d] __lock_acquire+0xaf0/0xe67
   [81079571] lock_acquire+0x149/0x191
   [811a1010] __kernfs_remove+0x14d/0x2da
   [811a1b48] kernfs_remove_by_name_ns+0x6b/0x87
   [811a3bd7] kernfs_remove_by_name+0xb/0xd
   [811a4056] sysfs_unmerge_group+0x36/0x4c
   [812bf608] rpm_sysfs_remove+0x14/0x16
   [812bf637] dpm_sysfs_remove+0x2d/0x52
   [812b63b9] device_del+0x42/0x1f8
   [812b65b3] device_unregister+0x44/0x50
   [a0085d57] usb_remove_ep_devs+0x1c/0x29 [usbcore]
   [a007f342] remove_intf_ep_devs+0x2f/0x45 [usbcore]
   [a0081428] usb_set_interface+0x22f/0x2f3 [usbcore]
   [a06b7709] uvc_video_enable+0x31/0x14c [uvcvideo]
   [a06b37f7] uvc_stop_streaming+0x24/0x50 [uvcvideo]
   [a061c680] __vb2_queue_cancel+0x25/0x143 [videobuf2_core]
   [a061cb3d] vb2_internal_streamoff+0x30/0x8f [videobuf2_core]
   [a061ccfe] vb2_streamoff+0x3b/0x43 [videobuf2_core]
   [a06b3af5] uvc_queue_streamoff+0x2f/0x48 [uvcvideo]
   [a06b462e] uvc_ioctl_streamoff+0x44/0x57 [uvcvideo]
   [a05f84a5] v4l_streamoff+0x15/0x17 [videodev]
   [a05fbd22] __video_do_ioctl+0x170/0x246 [videodev]
   [a05fc0ac] video_usercopy+0x2b4/0x589 [videodev]
   [a05fc391] video_ioctl2+0x10/0x12 [videodev]
   [a05f7451] v4l2_ioctl+0x78/0xf8 [videodev]
   [81152655] do_vfs_ioctl+0x47f/0x4c7
   [811526eb] SyS_ioctl+0x4e/0x7f
   [813dc152] 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: [a06b461e] 
uvc_ioctl_streamoff+0x34/0x57 [uvcvideo]
 #1:  (queue-mutex){+.+.+.}, at: [a06b3aea] 
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:
 [813d6111] dump_stack+0x4c/0x65
 [813d3e26] print_circular_bug+0x1f8/0x209
 [81078c1d] __lock_acquire+0xaf0/0xe67
 [81077f48] ? mark_lock+0x2d/0x212
 [81079571] lock_acquire+0x149/0x191
 [811a1b48] ? kernfs_remove_by_name_ns+0x6b/0x87
 [811a1010] __kernfs_remove+0x14d/0x2da
 [811a1b48] ? kernfs_remove_by_name_ns+0x6b/0x87
 [811a08cc] ? kernfs_find_ns+0xbe/0x100
 [811a1b48] kernfs_remove_by_name_ns+0x6b/0x87
 [811a3bd7] kernfs_remove_by_name+0xb/0xd
 [811a4056] sysfs_unmerge_group+0x36/0x4c
 [812bf608] rpm_sysfs_remove+0x14/0x16
 [812bf637] dpm_sysfs_remove+0x2d/0x52
 [812b63b9] device_del+0x42/0x1f8
 [81079885] ? 

Re: [PATCH 11/11] libdvbv5: fix PMT parser

2014-03-26 Thread Bjørn Mork
André Roth neol...@gmail.com writes:

 On Tue, 25 Mar 2014 21:51:49 +0100
 Bjørn Mork bj...@mork.no wrote:

  - * Copyright (c) 2011-2012 - Mauro Carvalho Chehab
  - * Copyright (c) 2012 - Andre Roth neol...@gmail.com
  + * Copyright (c) 2013 - Andre Roth neol...@gmail.com
*
* 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

2014-03-25 Thread Bjørn Mork
André Roth neol...@gmail.com 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 neol...@gmail.com
 + * Copyright (c) 2013 - Andre Roth neol...@gmail.com
   *
   * 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

2013-08-14 Thread Bjørn Mork
] ? do_IRQ+0x40/0x95
[  846.863906]  [813883ed] ? common_interrupt+0x6d/0x6d
[  846.863906]  EOI
[  846.863906]
[  846.863906]  [812a011c] ? arch_local_irq_enable+0x4/0x8
[  846.863906]  [812a04f3] ? cpuidle_enter_state+0x52/0xc1
[  846.863906]  [812a0636] ? cpuidle_idle_call+0xd4/0x143
[  846.863906]  [8101398c] ? arch_cpu_idle+0x5/0x17
[  846.863906]  [81072571] ? cpu_startup_entry+0x10d/0x187
[  846.863906]  [816b3d3d] ? start_kernel+0x3e8/0x3f3
[  846.863906]  [816b3777] ? repair_env_string+0x54/0x54
[  846.863906]  [816b3598] ? 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  [a092be0c] smsdvb_onresponse+0x264/0xa86 [smsdvb]
[  846.863906]  RSP 88013bc03cf0

Reported-by: Johannes Rohr jor...@gmail.com
Reference: http://bugs.debian.org/719623
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Signed-off-by: Bjørn Mork bj...@mork.no
---
 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

2013-07-05 Thread Bjørn Mork
Mauro Carvalho Chehab mche...@infradead.org 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

2013-06-19 Thread Bjørn Mork
James Board jpboa...@yahoo.com 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

2013-05-21 Thread Bjørn Mork
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: [a02e7ae5] 
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:[a02e7ae5]  
[a02e7ae5] 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]  [81072f0e] ? 
__symbol_put+0x29/0x2e
May 19 06:52:54 canardo kernel: [   49.017735]  [8104be19] ? 
tasklet_kill+0x4a/0x60
May 19 06:52:54 canardo kernel: [   49.017735]  [a03ffd6f] ? 
mantis_dvb_init+0x3ac/0x402 [mantis_core]
May 19 06:52:54 canardo kernel: [   49.017735]  [a03d8707] ? 
mantis_pci_probe+0x173/0x270 [mantis]
May 19 06:52:54 canardo kernel: [   49.017735]  [811c5a5b] ? 
local_pci_probe+0x39/0x68
May 19 06:52:54 canardo kernel: [   49.017735]  [811c6504] ? 
pci_device_probe+0xcd/0xfa
May 19 06:52:54 canardo kernel: [   49.017735]  [812510c1] ? 
driver_probe_device+0xa8/0x138
May 19 06:52:54 canardo kernel: [   49.017735]  [812511a0] ? 
__driver_attach+0x4f/0x6f
May 19 06:52:54 canardo kernel: [   49.017735]  [81251151] ? 
driver_probe_device+0x138/0x138
May 19 06:52:54 canardo kernel: [   49.017735]  [8124fcf0] ? 
bus_for_each_dev+0x4f/0x7a
May 19 06:52:54 canardo kernel: [   49.017735]  [81250a5a] ? 
bus_add_driver+0xa5/0x1f5
May 19 06:52:54 canardo kernel: [   49.017735]  [a03d8804] ? 
mantis_pci_probe+0x270/0x270 [mantis]
May 19 06:52:54 canardo kernel: [   49.017735]  [812515c8] ? 
driver_register+0x8d/0xf5
May 19 06:52:54 canardo kernel: [   49.017735]  [a03d8804] ? 
mantis_pci_probe+0x270/0x270 [mantis]
May 19 06:52:54 canardo kernel: [   

Re: [PATCH 1/6] siano: get rid of CammelCase from smscoreapi.h

2013-03-21 Thread Bjørn Mork
Mauro Carvalho Chehab mche...@redhat.com 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: [PATCH 4/6] siano: remove the remaining CamelCase compliants

2013-03-21 Thread Bjørn Mork
Mauro Carvalho Chehab mche...@redhat.com 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: [RFC V1 5/8] smi2021: Add smi2021_video.c

2013-03-18 Thread Bjørn Mork
Hans Verkuil hverk...@xs4all.nl 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: [RFC V1 7/8] smi2021: Add smi2021_bl.c

2013-03-18 Thread Bjørn Mork
Jon Arne Jørgensen jona...@jonarne.no 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: [PATCH] [media] mantis: merge both vp2033 and vp2040 drivers

2012-08-16 Thread Bjørn Mork
Manu Abraham abraham.m...@gmail.com 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: [git:v4l-dvb/for_v3.7] [media] mantis: Terratec Cinergy C PCI HD (CI)

2012-08-16 Thread Bjørn Mork
Mauro Carvalho Chehab mche...@redhat.com 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: [git:v4l-dvb/for_v3.7] [media] mantis: Terratec Cinergy C PCI HD (CI)

2012-08-16 Thread Bjørn Mork
Manu Abraham abraham.m...@gmail.com 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- 
TAbort- MAbort- SERR- PERR- INTx-
Latency: 64 (2000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fdfff000 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis
Kernel modules: mantis

bjorn@canardo:~$ lspci -vvnns 05:01
05:01.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- 
TAbort- MAbort- SERR- PERR- INTx-
Latency: 64 (2000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 17
Region 0: Memory at fdffe000 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis
Kernel modules: mantis


Both of them appear to have a TDA10023 tuner:

[   35.626204] Mantis :05:00.0: PCI INT A - 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: [PATCH] Terratec Cinergy C PCI HD (CI)

2012-05-09 Thread Bjørn Mork
Igor M. Liplianin liplia...@me.by 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 liplia...@me.by
 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

2012-03-19 Thread Bjørn Mork
Steinar H. Gunderson sgunder...@bigfoot.com 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

2011-10-03 Thread Bjørn Mork
Antti Palosaari cr...@iki.fi 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:

2011-09-06 Thread Bjørn Mork
Antti Palosaari cr...@iki.fi 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

2011-09-02 Thread Bjørn Mork
Antti Palosaari cr...@iki.fi 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?

2011-08-09 Thread Bjørn Mork
Steve Kerrison st...@stevekerrison.com 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

2011-07-04 Thread Bjørn Mork
Oliver Endriss o.endr...@gmx.de 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

2011-06-21 Thread Bjørn Mork
Devin Heitmueller dheitmuel...@kernellabs.com 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

2011-06-20 Thread Bjørn Mork
Devin Heitmueller dheitmuel...@kernellabs.com 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] V4L1 API has been moved into legacy on the linuxtv.org site

2011-06-14 Thread Bjørn Mork
Signed-off-by: Bjørn Mork bj...@mork.no
---
 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 @@
   table border=0
tr
 td
- a 
href=http://www.linuxtv.org/downloads/video4linux/API/V4L1_API.html;V4L 
original API/a
+ a 
href=http://linuxtv.org/downloads/legacy/video4linux/API/V4L1_API.html;V4L 
original API/a
 /td
 td
  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


[PATCH] [media] DVB API: Mention the dvbM device

2011-06-14 Thread Bjørn Mork
Signed-off-by: Bjørn Mork bj...@mork.no
---
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:/para
 /listitem
  listitem
 
+paraemphasis role=tt/dev/dvb/adapterN/dvrM/emphasis,/para
+/listitem
+ listitem
+
 paraemphasis 
role=tt/dev/dvb/adapterN/caM/emphasis,/para/listitem/itemizedlist
 
 parawhere 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


Re: [bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency

2011-06-03 Thread Bjørn Mork
Antti Palosaari cr...@iki.fi 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 patrick.boettc...@desy.de
depends:s5h1420,dvb-core,cx24113,cx24123,i2c-core
vermagic:   2.6.32-5-amd64 SMP mod_unload modversions 
parm:   debug:set debug level (1=info,2=tuner,4=i2c,8=ts,16=sram,32=reg 
(|-able)). (debugging is not enabled) (int)
parm:   adapter_nr:DVB adapter numbers (array of short)



This probably means that a generic i2c_tuner wrapper, similar to
dvb_attach, would 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: [bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency

2011-06-03 Thread Bjørn Mork
Antti Palosaari cr...@iki.fi 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/dvb/frontends/dib9000.c:EXPORT_SYMBOL

Re: [GIT PULL FOR 2.6.40] PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C)

2011-06-03 Thread Bjørn Mork
Antti Palosaari cr...@iki.fi 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


Writing descriptive commit messages (was Re: PCTV nanoStick T2 290e support - Thank you!)

2011-06-01 Thread Bjørn Mork
Bjørn Mork bj...@mork.no writes:
 Rémi Denis-Courmont r...@remlab.net writes:
 On Fri, 27 May 2011 13:36:37 +0200, Bjørn Mork bj...@mork.no 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 mche...@redhat.com
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 dougsl...@redhat.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com


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


[bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency

2011-06-01 Thread Bjørn Mork
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 mche...@infradead.org
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


Re: [bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency

2011-06-01 Thread Bjørn Mork
Antti Palosaari cr...@iki.fi 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?= bj...@mork.no
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 bj...@mork.no
---
 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,
 			em28xx_cxd2820r_config, dev-i2c_adap, NULL);
 		if (dvb-fe[0]) {
-			struct

Re: [bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency

2011-06-01 Thread Bjørn Mork
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?= bj...@mork.no
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 bj...@mork.no
---
 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

2011-06-01 Thread Bjørn Mork
Bjørn Mork bj...@mork.no 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: [linux-dvb] Terratec Cinergy C HD - CAM support.... Need help?

2011-05-29 Thread Bjørn Mork
Willem van Asperen wil...@ereprijs.demon.nl 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?

2011-05-28 Thread Bjørn Mork
Marc Coevoet ma...@dommel.be 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!

2011-05-27 Thread Bjørn Mork
Antti Palosaari cr...@iki.fi 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: PCTV nanoStick T2 290e support - Thank you!

2011-05-27 Thread Bjørn Mork
Rémi Denis-Courmont r...@remlab.net writes:
 On Fri, 27 May 2011 13:36:37 +0200, Bjørn Mork bj...@mork.no 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!

2011-05-27 Thread Bjørn Mork
Steve Kerrison st...@stevekerrison.com 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: [PATCH] Add remote control support for mantis

2011-05-25 Thread Bjørn Mork
Christoph Pinkl christoph.pi...@gmail.com 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

2011-05-12 Thread Bjørn Mork
Andreas Oberritter o...@linuxtv.org 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


Re: dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API

2011-05-12 Thread Bjørn Mork
HoP jpetr...@gmail.com writes:
 2011/5/12 Bjørn Mork bj...@mork.no:
 Andreas Oberritter o...@linuxtv.org 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 bj...@mork.no

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


dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API

2011-05-11 Thread Bjørn Mork
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?

2011-03-31 Thread Bjørn Mork
Jos Hoekstra joshoeks...@gmx.net 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 abraham.m...@gmail.com
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 o...@pardus.org.tr for pointing it out

Signed-off-by: Manu Abraham m...@linuxtv.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

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


Re: S2-3200 switching-timeouts on 2.6.38

2011-03-22 Thread Bjørn Mork
Manu Abraham abraham.m...@gmail.com writes:
 On Tue, Mar 22, 2011 at 1:46 AM, Randy Dunlap rdun...@xenotime.net 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


Re: S2-3200 switching-timeouts on 2.6.38

2011-03-22 Thread Bjørn Mork
Rico Tzschichholz ric...@t-online.de 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


[PATCH] [media] use pci_dev-revision

2011-03-21 Thread Bjørn Mork
pci_setup_device() has saved the PCI revision in the pci_dev
struct since Linux 2.6.23.  Use it.

Cc: Auke Kok auke-jan.h@intel.com
Signed-off-by: Bjørn Mork bj...@mork.no
---
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 | PCI_COMMAND_MASTER;
pci_write_config_word(pci_dev, PCI_COMMAND, cmd);
 
-   pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, cx-card_rev);
+   cx-card_rev

Re: DVB driver for TerraTec H7 - how do I install them?

2011-01-26 Thread Bjørn Mork
Torfinn Ingolfsen tin...@gmail.com 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

2011-01-10 Thread Bjørn Mork
Oliver Endriss o.endr...@gmx.de 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

2010-12-10 Thread Bjørn Mork
Ozan Çağlayan o...@pardus.org.tr 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

2010-11-13 Thread Bjørn Mork
Mauro Carvalho Chehab mche...@redhat.com 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

2010-11-12 Thread Bjørn Mork
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 
 abraham.m...@gmail.com == 

 Apr,15 2010: [5/8] ir-core: convert mantis from ir-functions.c
   http://patchwork.kernel.org/patch/92961   David Härdeman 
 da...@hardeman.nu

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 
 marko.rist...@kolumbus.fi

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 bj...@mork.no
 Jun,20 2010: mantis: use dvb_attach to avoid double dereferencing on module 
 removal http://patchwork.kernel.org/patch/107063  Bjørn Mork bj...@mork.no
 Jun,21 2010: Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make 
 modules  http://patchwork.kernel.org/patch/107147  Manu Abraham 
 abraham.m...@gmail.com
 Jul, 3 2010: mantis: Rename gpio_set_bits to mantis_gpio_set_bits 
   http://patchwork.kernel.org/patch/109972  Ben Hutchings 
 b...@decadent.org.uk
 Jul, 8 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, 
 improve http://patchwork.kernel.org/patch/110909  Marko Ristola 
 marko.rist...@kolumbus.fi

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 
 marko.rist...@kolumbus.fi
 Jul,10 2010: Mantis driver patch: use interrupt for I2C traffic instead of 
 busy reg http://patchwork.kernel.org/patch/111245  Marko Ristola 
 marko.rist...@kolumbus.fi
 Jul,19 2010: Twinhan DTV Ter-CI (3030 mantis) 
   http://patchwork.kernel.org/patch/112708  Niklas Claesson 
 nicke.claes...@gmail.com

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 
 marko.rist...@kolumbus.fi
 Oct,10 2010: [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 
 demod   http://patchwork.kernel.org/patch/244201  Tuxoholic 
 tuxoho...@hotmail.de



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

Re: V4L/DVB/IR patches pending merge

2010-11-01 Thread Bjørn Mork
Mauro Carvalho Chehab mche...@redhat.com writes:

   == mantis patches - Waiting for Manu Abraham 
 abraham.m...@gmail.com == 

 Apr,15 2010: [5/8] ir-core: convert mantis from ir-functions.c
   http://patchwork.kernel.org/patch/92961   David Härdeman 
 da...@hardeman.nu
 Jun,20 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, 
 improve http://patchwork.kernel.org/patch/107036  Marko Ristola 
 marko.rist...@kolumbus.fi
 Jun,20 2010: [2/2] DVB/V4L: mantis: remove unused files   
   http://patchwork.kernel.org/patch/107062  Bjørn Mork bj...@mork.no
 Jun,20 2010: mantis: use dvb_attach to avoid double dereferencing on module 
 removal http://patchwork.kernel.org/patch/107063  Bjørn Mork bj...@mork.no
 Jun,21 2010: Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make 
 modules  http://patchwork.kernel.org/patch/107147  Manu Abraham 
 abraham.m...@gmail.com
 Jul, 3 2010: mantis: Rename gpio_set_bits to mantis_gpio_set_bits 
   http://patchwork.kernel.org/patch/109972  Ben Hutchings 
 b...@decadent.org.uk
 Jul, 8 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, 
 improve http://patchwork.kernel.org/patch/110909  Marko Ristola 
 marko.rist...@kolumbus.fi
 Jul, 9 2010: Mantis: append tasklet maintenance for DVB stream delivery   
   http://patchwork.kernel.org/patch/111090  Marko Ristola 
 marko.rist...@kolumbus.fi
 Jul,10 2010: Mantis driver patch: use interrupt for I2C traffic instead of 
 busy reg http://patchwork.kernel.org/patch/111245  Marko Ristola 
 marko.rist...@kolumbus.fi
 Jul,19 2010: Twinhan DTV Ter-CI (3030 mantis) 
   http://patchwork.kernel.org/patch/112708  Niklas Claesson 
 nicke.claes...@gmail.com
 Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per 
 interrupt http://patchwork.kernel.org/patch/118173  Marko Ristola 
 marko.rist...@kolumbus.fi
 Oct,10 2010: [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 
 demod   http://patchwork.kernel.org/patch/244201  Tuxoholic 
 tuxoho...@hotmail.de
 Jun,11 2010: stb0899: Removed an extra byte sent at init on DiSEqC bus
   http://patchwork.kernel.org/patch/105621  Florent AUDEBERT 
 florent.audeb...@anevia.com

 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

2010-10-24 Thread Bjørn Mork
Mauro Carvalho Chehab mche...@redhat.com 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)

2010-10-23 Thread Bjørn Mork
Steven Toth st...@kernellabs.com 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

2010-10-01 Thread Bjørn Mork
David Ellingsworth da...@identd.dyndns.org 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)

2010-08-24 Thread Bjørn Mork
Matthias Larisch m...@matthias-larisch.de 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

2010-08-16 Thread Bjørn Mork
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: [PATCH] Mantis DMA transfer cleanup, fixes data corruption and a race, improves performance. (signed-off this time)

2010-07-09 Thread Bjørn Mork
Marko Ristola marko.rist...@kolumbus.fi 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 marko.rist...@kolumbus.fi

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 bj...@mork.no

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


Re: [PATCH] Mantis: append tasklet maintenance for DVB stream delivery

2010-07-09 Thread Bjørn Mork
Marko Ristola marko.rist...@kolumbus.fi 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 marko.rist...@kolumbus.fi


Tested-by: Bjørn Mork bj...@mork.no

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: Status of the patches under review (85 patches) and some misc notes about the devel procedures

2010-07-07 Thread Bjørn Mork
Mauro Carvalho Chehab mche...@redhat.com 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

2010-07-05 Thread Bjørn Mork
Hans Verkuil hverk...@xs4all.nl 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 mche...@infradead.org
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?

2010-07-02 Thread Bjørn Mork
Dirk Langner dirko...@gmx.de 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

2010-07-01 Thread Bjørn Mork
Mauro Carvalho Chehab mche...@redhat.com 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

2010-06-25 Thread Bjørn Mork
Pascal Hahn derpa...@gmail.com 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

2010-06-24 Thread Bjørn Mork
Pascal Hahn derpa...@gmail.com 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


[PATCH] Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable

2010-06-21 Thread Bjørn Mork
Thanks to Ozan ?a?layan o...@pardus.org.tr for pointing it out

From: Manu Abraham abraham.m...@gmail.com

Signed-off-by: Manu Abraham m...@linuxtv.org
[bj...@mork.no: imported from 
http://jusst.de/hg/mantis-v4l-dvb/raw-rev/3731f71ed6bf]
Signed-off-by: Bjørn Mork bj...@mork.no
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


Re: [PATCH] Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable

2010-06-21 Thread Bjørn Mork
VDR User user@gmail.com writes:

 Instead of copypaste 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


Re: [PATCH] Mantis: append tasklet maintenance for DVB stream delivery

2010-06-20 Thread Bjørn Mork
Marko Ristola marko.rist...@kolumbus.fi 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

2010-06-20 Thread Bjørn Mork
Bjørn Mork bj...@mork.no writes:
 Marko Ristola marko.rist...@kolumbus.fi 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


[PATCH 2/2] DVB/V4L: mantis: remove unused files

2010-06-20 Thread Bjørn Mork
The files mantis_core.c and mantis_core.h are not used anywhere, so
delete them

Signed-off-by: Bjørn Mork bj...@mork.no
---
 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-2040 */
-   case TERRATEC_CINERGY_C_PCI:/* VP-2040 clone */
-   case TECHNISAT_CABLESTAR_HD2:
-   mantis-hwconfig = vp2040_mantis_config;
-   break;
-   case MANTIS_VP_3030_DVB_T:  /* VP-3030 */
-   mantis-hwconfig = vp3030_mantis_config

[PATCH] V4L/DVB: mantis: use dvb_attach to avoid double dereferencing on module removal

2010-06-20 Thread Bjørn Mork
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 bj...@mork.no
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,
 adapter,
 read_pwm(mantis));
 
@@ -141,7 +141,7 @@ static int vp2033_frontend_init(struct mantis_pci

Re: Cinergy C PCI HD with current v4l-dvb - PATCH for review/pull included

2010-06-19 Thread Bjørn Mork
[ I think this should have been posted to linux-media@vger.kernel.org instead ]

Marko Ristola marko.rist...@kolumbus.fi 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 marko.rist...@kolumbus.fi

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. Usually PCI device 

Re: Is anybody working on TechniSat CableStar Combo HD CI USB device?

2010-06-08 Thread Bjørn Mork
Markus Rechberger mrechber...@gmail.com 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

2010-06-05 Thread Bjørn Mork
Rune Evjen rune.ev...@gmail.com 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: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34

2010-06-03 Thread Bjørn Mork
Mauro Carvalho Chehab mche...@infradead.org 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: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34

2010-06-03 Thread Bjørn Mork
Hans de Goede hdego...@redhat.com 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: Terratec Cinergy C DVB-C card problems

2010-06-03 Thread Bjørn Mork
Billy Brumley bbrum...@gmail.com 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: ideal DVB-C PCI/e card?

2010-05-03 Thread Bjørn Mork
Jed jedi.the...@gmail.com 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: ideal DVB-C PCI/e card?

2010-05-03 Thread Bjørn Mork
Markus Rechberger mrechber...@gmail.com 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: [stable] [PATCH v2] V4L/DVB: budget: Oops: BUG: unable to handle kernel NULL pointer dereference

2010-04-22 Thread Bjørn Mork
Greg KH g...@kroah.com 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

2010-04-13 Thread Bjørn Mork
Vidar Tyldum Hansen vi...@tyldum.com 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

2010-04-09 Thread Bjørn Mork
Mauro Carvalho Chehab mche...@redhat.com 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: Making IRQF_DISABLED or IRQF_SHARED optional

2010-04-06 Thread Bjørn Mork
Oliver Endriss o.endr...@gmx.de 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- 
TAbort+ MAbort- SERR- PERR- INTx-
Latency: 64 (2000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fcfff000

[PATCH] V4L/DVB: budget: Oops: BUG: unable to handle kernel NULL pointer dereference

2010-03-24 Thread Bjørn Mork
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: [e08b04a3] dvb_frontend_detach+0x4/0x67 [dvb_core]


Ref http://bugs.debian.org/575207


Signed-off-by: Bjørn Mork bj...@mork.no
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 v2] V4L/DVB: budget: Oops: BUG: unable to handle kernel NULL pointer dereference

2010-03-24 Thread Bjørn Mork
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: [e08b04a3] 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 bj...@mork.no
Cc: sta...@kernel.org
Reported-by: Fladischer Michael fladischermich...@fladi.at
---
Oliver Endriss o.endr...@gmx.de 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,
+  budget-dvb_frontend,
+  budget-i2c_adap

[PATCH v2 for v4l-dvb master] V4L/DVB: budget: Oops: BUG: unable to handle kernel NULL pointer dereference

2010-03-24 Thread Bjørn Mork
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: [e08b04a3] 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 bj...@mork.no
Reported-by: Fladischer Michael fladischermich...@fladi.at
---
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 */
+   if (budget-dvb_frontend-ops.init)
+   
budget

[PATCH] V4L/DVB: saa7146: Making IRQF_DISABLED or IRQF_SHARED optional

2010-03-23 Thread Bjørn Mork
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 bj...@mork.no
---

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

2010-03-22 Thread Bjørn Mork
Andy Walls awa...@radix.net 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 bj...@mork.no
 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 20 01:02:56 canardo kernel: [96686.159997] BUG: soft lockup - CPU#0 stuck 
for 61s! [lmcoretemp:7424]


As the syslogging is local, you can't really trust syslog's timestamp.
But the kernel timestamps should be accurate.

The incident above started with

Mar 20 01:02:56 canardo kernel: [96513.561007] saa7146 (0) saa7146_i2c_writeout 
[irq]: timed

[PATCH] V4L/DVB: budget-av: wait longer for frontend to power on

2010-03-21 Thread Bjørn Mork
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 bj...@mork.no
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


[PATCH] V4L/DVB: saa7146: IRQF_DISABLED causes only trouble

2010-03-21 Thread Bjørn Mork
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 bj...@mork.no
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