Re: [PATCH 1/2] V4L/DVB: dib7770: enable the current mirror
Hi Mauro, On Tuesday 07 September 2010 17:50:45 pboettc...@kernellabs.com wrote: From: Olivier Grenie olivier.gre...@dibcom.fr To improve performance on DiB7770-devices enabling the current mirror is needed. This patch adds an option to the dib7000p-driver to do that and it creates a separate device-entry in dib0700-device to use those changes on hardware which is using the DiB7770. Cc: sta...@kernel.org Signed-off-by: Olivier Grenie olivier.gre...@dibcom.fr Signed-off-by: Patrick Boettcher patrick.boettc...@dibcom.fr --- drivers/media/dvb/dvb-usb/dib0700_devices.c | 53 ++- drivers/media/dvb/frontends/dib7000p.c | 2 + drivers/media/dvb/frontends/dib7000p.h |3 ++ 3 files changed, 57 insertions(+), 1 deletions(-) This is the patch I was talking to you about in my last Email. This one needs to be quickly applied to 2.6.35. Well ... quickly ... as soon as possible in sense of when you have a free time slot. This patch help to optimize the performance of the DiB7770-chip which can be found in several devices out there right now. It was tested and applied on 2.6.36-rc3, It should apply cleanly on 2.6.35. Thanks in advance for your help, Patrick. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] V4L/DVB: dib7770: enable the current mirror
On Thursday 09 September 2010 01:16:09 Mauro Carvalho Chehab wrote: Em 07-09-2010 12:58, Patrick Boettcher escreveu: Hi Mauro, On Tuesday 07 September 2010 17:50:45 pboettc...@kernellabs.com wrote: From: Olivier Grenie olivier.gre...@dibcom.fr To improve performance on DiB7770-devices enabling the current mirror is needed. This patch adds an option to the dib7000p-driver to do that and it creates a separate device-entry in dib0700-device to use those changes on hardware which is using the DiB7770. Cc: sta...@kernel.org Signed-off-by: Olivier Grenie olivier.gre...@dibcom.fr Signed-off-by: Patrick Boettcher patrick.boettc...@dibcom.fr --- drivers/media/dvb/dvb-usb/dib0700_devices.c | 53 ++- drivers/media/dvb/frontends/dib7000p.c | 2 + drivers/media/dvb/frontends/dib7000p.h |3 ++ 3 files changed, 57 insertions(+), 1 deletions(-) This is the patch I was talking to you about in my last Email. This one needs to be quickly applied to 2.6.35. Well ... quickly ... as soon as possible in sense of when you have a free time slot. This patch help to optimize the performance of the DiB7770-chip which can be found in several devices out there right now. It was tested and applied on 2.6.36-rc3, It should apply cleanly on 2.6.35. Ok. Patch 2/2 is also important for -stable? No. Only 1/2 is needed. Thanks for your response. Patrick. -- 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 PULL request for 2.6.37] Add Technisat SkyStar HD USB driver
Hi Mauro, please git pull git://github.com/pboettch/linux-2.6.git for_mauro for the following changes: technisat-usb2: added driver for Technisat's USB2.0 DVB-S/S2 receiver stv090x: add tei-field to config-structure stv090x: added function to control GPIOs from the outside Those are intended for 2.6.37 and have been rebased today on linuxtv's staging/2.6.37-branch. The development of the new technisat-usb2-driver has been sponsored by Technisat UK. Thanks in advance for pulling and commenting, -- Patrick Boettcher - KernelLabs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL request for 2.6.37] Add Technisat SkyStar HD USB driver
On Sunday 17 October 2010 14:23:03 Mauro Carvalho Chehab wrote:
Em 17-10-2010 10:50, Patrick Boettcher escreveu:
Hi Mauro,
please
git pull git://github.com/pboettch/linux-2.6.git for_mauro
for the following changes:
technisat-usb2: added driver for Technisat's USB2.0 DVB-S/S2 receiver
stv090x: add tei-field to config-structure
stv090x: added function to control GPIOs from the outside
Both stv090x patches seem ok to me.
Thanks in advance for pulling and commenting,
I have a few comments for the technisat-usb2:
Thanks for your comments, they were appreciated.
[...]
+static int technisat_usb2_debug;
+module_param_named(debug, technisat_usb2_debug, int, 0644);
As this is static, you could just name it as:
static int debug;
and use module_param() instead.
OK.
+static struct i2c_algorithm technisat_usb2_i2c_algo = {
+ .master_xfer = technisat_usb2_i2c_xfer,
+ .functionality = technisat_usb2_i2c_func,
+
+#ifdef NEED_ALGO_CONTROL
+ .algo_control = dummy_algo_control,
+#endif
You don't need it. This is always false upstream.
OK.
[...]
Don't implement your own IR RC5 decoding logic. We have it already at IR
core, and it is able to handle several protocols. Instead, just sent the
raw events to RC core.
See drivers/media/dvb/siano/smsir.c for an example on how to do it.
[...]
Also, don't put the RC tables at the driver. Move it to a separate file, at
drivers/media/IR/keymaps/. This allows importing the RC keycodes by
ir-keytable userspace tool (from v4l-utils.git).
Everythings' done. Ported to use ir-rc5-decoder. Rebased and squashed.
So, please pull now from:
git pull git://github.com/pboettch/linux-2.6.git for_mauro
thanks in advance and best regards,
--
Patrick Boettcher - KernelLabs
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tuner demodulator: Montage versus STMicroelectronics
On Saturday 27 November 2010 03:12:32 Zbigniew Luszpinski wrote: Hello, I'm going to buy my first DVB-S2 USB tuner. I see that there are two best demod/tuner solutions: 1. Montage Technology M88TS2020/2 tuner and M88DS3000/2 demodulator 2. STMicroelectronics STB6100 tuner and STV0903BAC demodulator Can you please tell me which is better for Linux user like me (STM or Montage)? I haven't seen a driver for Montage in v4l-dvb.git, so your best choise is to go with the STV0903. But then it also depends whether the USB part of your device is supported already or not. What device are you think about? regards, -- Patrick -- 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
[FIX for 2.6.37]
Hi Mauro, please pull from git://github.com/pboettch/linux-2.6.git v2.6.37-fixes for flexcop-pci: sanitize driver name to avoid warning on load It fixes https://bugzilla.kernel.org/show_bug.cgi?id=15826 . thanks and best regards, -- Patrick Boettcher - KernelLabs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#639161: linux-image-3.0.0-1-686-pae: Upgrade 2.6.39 - 3.0.0 breaks playback on DiBcom 7000PC
Hi, Afaik, this is fixed with those commits: [media] dib0700: correct error message for_v3.0 [media] dib0700: protect the dib0700 buffer access [media] DiBcom: protect the I2C bufer access from http://git.linuxtv.org/pb/media_tree.git/shortlog/refs/heads/for_v3.0 A pull request has been sent to the media-maintainer, but it seems he is busy. -- Patrick. On Thursday 25 August 2011 00:50:37 Ben Hutchings wrote: Patrick, Please could you take a look at the following bug report on Linux 3.0 as packaged in Debian. Ben. On Wed, 2011-08-24 at 18:59 +0200, Soeren D. Schulze wrote: Package: linux-2.6 Version: 3.0.0-1 Severity: normal I usually use tzap/mplayer for TV playback. After the upgrade to Linux 3.0.0, tzap command line output still looks fine, but mplayer does not seem to receive any data (its cache does not fill up). syslog/dmesg output looks the same as in 2.6.39. On the first try to tune, dmesg receives: dib0700: tx buffer length is larger than 4. Not supported. (for which I find various non-Debian bug reports) But that does not seem to be the issue, because the same message appears in 2.6.39, where everything is fine. So I do not really have an idea what the problem is, but I certainly know that it's a regression, because simply booting Linux 2.6.39 rather than 3.0.0 on the same system avoids the problem. -- Package-specific info: ** Version: Linux version 3.0.0-1-686-pae (Debian 3.0.0-1) (b...@decadent.org.uk) (gcc version 4.5.3 (Debian 4.5.3-3) ) #1 SMP Sun Jul 24 14:27:32 UTC 2011 ** Command line: BOOT_IMAGE=/vmlinuz-3.0.0-1-686-pae root=UUID=3aa0a731-df46-486e-9c1e-258723e14f8f ro ** Not tainted ** Kernel log: [ 11.031446] saa7134: card=172 - RoverMedia TV Link Pro FM 19d1:0138 [ 11.031580] saa7134: card=173 - Zolid Hybrid TV Tuner PCI 1131:2004 [ 11.031713] saa7134: card=174 - Asus Europa Hybrid OEM 1043:4847 [ 11.031847] saa7134: card=175 - Leadtek Winfast DTV1000S 107d:6655 [ 11.031982] saa7134: card=176 - Beholder BeholdTV 505 RDS :5051 [ 11.032126] saa7134: card=177 - Hawell HW-404M7 [ 11.032217] saa7134: card=178 - Beholder BeholdTV H7 5ace:7190 [ 11.032351] saa7134: card=179 - Beholder BeholdTV A7 5ace:7090 [ 11.032485] saa7134: card=180 - Avermedia PCI M733A 1461:4155 1461:4255 [ 11.032656] saa7134: card=181 - TechoTrend TT-budget T-3000 13c2:2804 [ 11.032789] saa7134: card=182 - Kworld PCI SBTVD/ISDB-T Full-Seg Hybrid 17de:b136 [ 11.032923] saa7134: card=183 - Compro VideoMate Vista M1F 185b:c900 [ 11.033057] saa7134: card=184 - Encore ENLTV-FM 3 1a7f:2108 [ 11.033192] saa7134: card=185 - MagicPro ProHDTV Pro2 DMB-TH/Hybrid 17de:d136 [ 11.033326] saa7134: card=186 - Beholder BeholdTV 501 5ace:5010 [ 11.033460] saa7134: card=187 - Beholder BeholdTV 503 FM 5ace:5030 [ 11.033596] saa7134[0]: subsystem: 1131:, board: UNKNOWN/GENERIC [card=0,autodetected] [ 11.075242] IR NEC protocol handler initialized [ 11.265597] saa7134[0]: board init: gpio is 10020 [ 11.368582] saa7134[0]: Huh, no eeprom present (err=-5)? [ 11.381924] saa7134[0]: registered device video0 [v4l2] [ 11.382055] saa7134[0]: registered device vbi0 [ 11.417515] IR RC5(x) protocol handler initialized [ 11.607051] cfg80211: Calling CRDA to update world regulatory domain [ 11.995773] IR RC6 protocol handler initialized [ 12.191500] IR JVC protocol handler initialized [ 12.263839] dib0700: loaded with support for 20 different device-types [ 12.264209] dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state. [ 12.265499] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 12.266158] DVB: registering new adapter (Hauppauge Nova-T Stick) [ 12.517093] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... [ 12.609760] IR Sony protocol handler initialized [ 12.790869] DiB0070: successfully identified [ 12.907896] ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22 [ 12.907988] VIA 82xx Audio :00:11.5: PCI INT C - Link[ALKC] - GSI 22 (level, low) - IRQ 22 [ 12.908316] VIA 82xx Audio :00:11.5: setting latency timer to 64 [ 12.932675] saa7134 ALSA driver for DMA sound loaded [ 12.932807] saa7134[0]/alsa: saa7134[0] at 0xfdffc000 irq 16 registered as card -1 [ 12.948789] lirc_dev: IR Remote Control driver registered, major 249 [ 12.952109] IR LIRC bridge handler initialized [ 13.380033] Registered IR keymap rc-dib0700-rc5 [ 13.380514] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:10.4/usb1/1-1/1-1.3/rc/rc0/input6 [ 13.380749] rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:10.4/usb1/1-1/1-1.3/rc/rc0 [ 13.382312] dvb-usb: schedule remote query interval to 50 msecs. [ 13.382385] dvb-usb: Hauppauge Nova-T Stick
Re: DiBxxxx: fixes for 3.1/3.0
On Mon, 5 Sep 2011, Mauro Carvalho Chehab wrote:
Em 05-09-2011 05:11, Olivier Grenie escreveu:
Hello Mauro,
I agree with you but when I wrote this patch, my concern was that the read
register function (dib0070_read_reg)
returns a u16 and so I could not propagate the error. That's why I decided to
return 0 and not change the API.
But if you have a better idea, I will have no problem to implement it.
Ok, I'll pull from it for 3.0/3.1. For 3.2, the better is to fix it.
What other drivers do when they need to read a 16 bit register is to declare
the function as
returning an 'int'. As you know, on Linux, int has 32 bits, so it returns an
u16 properly.
It will also return properly the errors.
So, all you need to do is to convert it to something like:
static int dib0070_read_reg(struct dib0070_state *state, u8 reg)
{
int ret;
ret = mutex_lock_interruptible(...);
if (ret 0)
return ret;
...
ret = i2c_transfer(state-i2c, state-msg, 2);
if (ret 0)
goto error;
if (ret != 2) {
ret = -EIO;
goto error;
}
ret = (state-i2c_read_buffer[0] 8)
| state-i2c_read_buffer[1];
error:
mutex_unlock(...);
return ret;
}
You'll need to add a check on all places that calls dib0070_read_reg() (and
dib070_write_reg) to do
the right thing when a negative number is returned, like:
static int dib0070_set_bandwidth(struct dvb_frontend *fe, struct
dvb_frontend_parameters *ch)
{
struct dib0070_state *state = fe-tuner_priv;
int tmp = dib0070_read_reg(state, 0x02);
if (tmp 0)
return tmp;
tmp | = 0x3fff;
...
}
For the write register function (dib0070_write_reg), in case of problem with
the mutex lock, an error code is returned.
Userspace applications in general handle EAGAIN on a different way, especially
if the application
is opening the device on non-blocking mode, as POSIX require that applications
should re-try
the ioctl, if EAGAIN is returned, on non-blocking mode. They might also handle
EINTR case as well.
So, using it instead of EINVAL is better.
While I agree with you in principle I think the time we would need and the
risk we would take to do what you're asking here is too high.
I agree the drivers are quite huge and ugly but now adding hundreds of
if's and returns won't make them better.
Right now if a read fails it returns 0 which in some cases might be even
correct.
Fixing the error-handling in the drivers will most likely break things
unless it is not done automagically - IOW not by a human being.
I quickly checked some other sources in dvb/frontends/ and the Dibbies are
not the only ones where the error-path would need to be fixed.
I'd appreciate if we could restrict this requirement to new drivers which
certainly will arrive. Of course, if there is a volunteer I'm ready to
have a look.
What do you think?
regards,
--
Patrick
--
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
PULL request for 3.2 (fixes 'n' features)
Hi Mauro, if it's not too late for 3.2 could you please pull from git://linuxtv.org/pb/media_tree.git staging/for_v3.2 for [media] dib9090: limit the I2C speed [media] dib8096P: add the reference board [media] add the support for DiBcom [media] dib7090: add the reference board [media] DiB8000: improve the tuning and the SNR monitoring [media] DiBcom: correct warnings [media] dib7090: add the reference board TFE7090E [media] dib7000p/dib0090: update the driver Thanks a lot in advance, -- Patrick -- 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] dib7000m/p: struct alignment fix
Hi, On Wed, 12 Jan 2011, Robin Humble wrote: Ubuntu has a bug open for the issue: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/654791 but the disable pid filtering workaround one person uses there doesn't work for me. Sorry for the delay, but I only realized today that this bug exists. We are currently creating a proper fix for it. best regards, -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dib7000m/p: struct alignment fix
Hi again, On Wed, 12 Jan 2011, Mauro Carvalho Chehab wrote: Em 12-01-2011 11:17, Robin Humble escreveu: Hi, this is basically a re-post of http://www.linuxtv.org/pipermail/linux-dvb/2010-September/032744.html which fixes an Oops when tuning eg. AVerMedia DVB-T Volar, Hauppauge Nova-T, Winfast DTV. it seems to be quite commonly reported on this list. [ 809.128579] BUG: unable to handle kernel NULL pointer dereference at 0012 [ 809.128586] IP: [a0013702] i2c_transfer+0x16/0x124 [i2c_core] [ 809.128598] PGD 669a7067 PUD 79e5f067 PMD 0 [ 809.128604] Oops: [#1] SMP [ 809.128608] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq [ 809.128612] CPU 0 [ 809.128614] Modules linked in: tcp_lp fuse coretemp hwmon_vid cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 xfs exportfs uinput mt2060 mxl5005s af9013 dvb_usb_dib0700 ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder dib7000p dib0090 dib7000m dvb_usb_af9015 dib0070 dvb_usb dib8000 dvb_core dib3000mc ir_rc6_decoder dibx000_common snd_hda_codec_intelhdmi ir_rc5_decoder snd_hda_codec_realtek snd_hda_intel ir_nec_decoder snd_hda_codec ldusb i2c_i801 snd_hwdep snd_seq snd_seq_device rc_core atl1 asus_atk0110 snd_pcm snd_timer mii snd soundcore snd_page_alloc iTCO_wdt iTCO_vendor_support microcode raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t pata_jmicron i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] [ 809.128692] [ 809.128696] Pid: 2525, comm: tzap Not tainted 2.6.35.10-72.fc14.x86_64 #1 P5E-VM HDMI/P5E-VM HDMI [ 809.128700] RIP: 0010:[a0013702] [a0013702] i2c_transfer+0x16/0x124 [i2c_core] [ 809.128708] RSP: 0018:880064a83ae8 EFLAGS: 00010296 [ 809.128712] RAX: 880064a83b58 RBX: 00eb RCX: [ 809.128715] RDX: 0002 RSI: 880064a83b38 RDI: 0002 [ 809.128718] RBP: 880064a83b28 R08: 880079bcf7c0 R09: 5d80 [ 809.128721] R10: 0005 R11: 4a38 R12: 0001 [ 809.128725] R13: R14: c900237e8000 R15: c90023907000 [ 809.128729] FS: 7f2ff2dd3720() GS:88000200() knlGS: [ 809.128732] CS: 0010 DS: ES: CR0: 80050033 [ 809.128736] CR2: 0012 CR3: 7830d000 CR4: 06f0 [ 809.128739] DR0: DR1: DR2: [ 809.128743] DR3: DR6: 0ff0 DR7: 0400 [ 809.128746] Process tzap (pid: 2525, threadinfo 880064a82000, task 8800379745c0) [ 809.128749] Stack: [ 809.128751] 880064a83af8 8103c142 880079c41a90 00eb [ 809.128757] 0 0001 c900237e8000 c90023907000 [ 809.128762] 0 880064a83b88 a0407124 00020030 880064a83b68 [ 809.128768] Call Trace: [ 809.128776] [8103c142] ? need_resched+0x23/0x2d [ 809.128783] [a0407124] dib7000p_read_word+0x6d/0xbc [dib7000p] [ 809.128789] [813360eb] ? usb_submit_urb+0x2f8/0x33a [ 809.128795] [a0407ae5] dib7000p_pid_filter_ctrl+0x2d/0x90 [dib7000p] [ 809.128802] [a044f35f] stk70x0p_pid_filter_ctrl+0x19/0x1e [dvb_usb_dib0700] [ 809.128809] [a03b4ef9] dvb_usb_ctrl_feed+0xd7/0x123 [dvb_usb] [ 809.128815] [a03b4f6a] dvb_usb_start_feed+0x13/0x15 [dvb_usb] [ 809.128825] [a035585c] dmx_ts_feed_start_filtering+0x7d/0xd1 [dvb_core] [ 809.128833] [a03539fc] dvb_dmxdev_start_feed.clone.1+0xbd/0xeb [dvb_core] [ 809.128841] [a0353cf9] dvb_dmxdev_filter_start+0x2cf/0x31b [dvb_core] [ 809.128847] [81469b66] ? _raw_spin_lock_irq+0x1f/0x21 [ 809.128854] [a035444b] dvb_demux_do_ioctl+0x27b/0x4c0 [dvb_core] [ 809.128859] [8103c15a] ? should_resched+0xe/0x2e [ 809.128867] [a03528f3] dvb_usercopy+0xe4/0x16b [dvb_core] [ 809.128874] [a03541d0] ? dvb_demux_do_ioctl+0x0/0x4c0 [dvb_core] [ 809.128881] [811e3718] ? inode_has_perm.clone.20+0x79/0x8f [ 809.128886] [810668ec] ? remove_wait_queue+0x35/0x41 [ 809.128891] [81469b7f] ? _raw_spin_unlock_irqrestore+0x17/0x19 [ 809.128898] [a0352fd1] dvb_demux_ioctl+0x15/0x19 [dvb_core] [ 809.128903] [8112419b] vfs_ioctl+0x36/0xa7 [ 809.128908] [81124afc] do_vfs_ioctl+0x468/0x49b [ 809.128912] [81124b85] sys_ioctl+0x56/0x79 [ 809.128917] [81009cf2] system_call_fastpath+0x16/0x1b [ 809.128920] Code: 89 55 f8 48 83 c7 58 48 c7 c2 47 32 01 a0 e8 92 09 2c e1 c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 48 8b 47 10 48 89
Re: [PULL] request for 2.6.38-rc1
Hi Mauro,
On Sun, 16 Jan 2011, Mauro Carvalho Chehab wrote:
Em 14-01-2011 12:51, Patrick Boettcher escreveu:
Hi Mauro,
if it is not too late, here is a pull request for some new devices from DiBcom.
It would be nice to have it in 2.6.38-rc1.
Pull from
git://linuxtv.org/pb/media_tree.git staging/for_2.6.38-rc1.dibcom
for
DiB: Codingstype updates
Not sure if this is by purpose, but you're changing all
msleep(10) into msleep(20). This sounds very weird for a
CodingStyle fix:
- msleep(10);
+ msleep(20);
I was as surprised as you when I saw that changed, but in fact it is a
checkpatch-fix: it seems that checkpatch is warning about msleep or less
than 20ms.
Maybe it is not the right fix to put them to msleep(20), but I think this
is better than to do udelay(1).
What do you think?
+ if (request_firmware(state-frontend_firmware, dib9090.fw,
adap-dev-udev-dev)) {
Where's dib9090.fw firmware is available? The better is to submit a patch to
linux-firmware
with the firmware binary, with some license that allows end-users to use it
with your device
and distros/distro partners to re-distribute it. While here, please add also
the other
dibcom firmwares.
The dib0700-firmware is already available through a license. The
dib9090-firmware will come later. It'll take a moment before everything is
ready.
Vendors are free to use their own legal text for it. There are several examples
for it
at:
http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob_plain;f=WHENCE;hb=HEAD
Btw, there are two alignment errors (one at dib7000p, for some cases, aligned
with 4 chars),
and another at dib8000, where all statements after an if are aligned with 3
tabs plus one space.
I'm fixing those issues, c/c you at the fix patches.
Nice, thank you.
best regards,
--
Patrick
--
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: Dib7000/mt2266 help
Hi Peter, (adding back the list to CC) On Saturday 12 March 2011 11:48:38 Peter Tilley wrote: Hi Patrick, My sincerest apologies for coming to you directly but I have tried the Linux mailing list and received no response and noticed you seem to have been heavily involved with much of the Dibcom driver development. I have an issue with a dual tuner which is sold under the brand of Kaiser Baas KBA01004 but identifies itself as 1164:1e8c which is a Yaun device and this device seems to have already been included in the driver files. It loads ok and reports not problems. It tunes ok and reports FE lock on all channels however on all but one channel upon receiving FE lock the BER stays at 1 instead of dropping to a low number which would indicate I am not getting viterbi. The device is fitted with pairs of MT2266 and DIB7000 which I have positive identified by opening the USB stick. am more than happy to try and work this out myself however the amount of detail around in support of the Linux drivers is extremely low and a search for manufacturers data sheets finds next to nothing.There seems to be lots of what I would call magic numbers in the drivers and little to determine what they are doing. Are you sure it is a driver problem? If the BER stays at this value it could also mean that the channel- configuration is wrong. Are you using a channels.conf which has all parameters set, or are you doing a channel-scan-like tune (all values are set to AUTO). My question to you is are you able to offer either any pointers to solve the problem or help me find detailed information about the devices so I can help myself. I should point out that the device works perfectly under windows on the same antenna and indeed I have even successfully extracted the firmware from the supplied windows driver, renamed it so it loads and the problem still remains. There are usually some adaptations board-designing companies do to improve reception quality (adding external LNAs and things like that) that are of course handled by the Window-driver, because it is created by the manufacturer and not by the Linux-driver, because (in this case) the driver was released by the chip-manufacturer. Is the device toggling between FE_HAS_LOCK and no FE_HAS_LOCK or does it stay constantly at Please try whether you can achieve the BER lowering by moving the antenna or using a better one. If this helps, it really means that the windows-driver does something more the board. I doubt that the chip-driver needs to be changed, more likely the GPIOs of the dib0700 (in dib0700_core.c) or of the dib7000 are used to turn on or off a frequency switch or a LNA. Good point, what are the frequencies you're tuning ? regards, -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dibusb device with lock problems
Hi Mr Tux, On Saturday 02 April 2011 15:45:22 Mr Tux wrote: Hi list, hello Patrick, A locking problem with specific dib3000mb devices is still present in kernel 2.6.38. Now people upgrading from lenny to squeeze are also affected - see: [1] Please have a look at my previous post in [2] for a detailed description and links to this bug's history. I'm sending a cc of this to the people who once where affected by this bug or involved with the code change that introduced it. Anyone can confirm this is fixed/pending for his device and what dib3000mb device he is using out of the linuxtv wiki list of 14 dib3000mb devices [3]? I have 3 devices of the hama usb 1.1 series: [4], that's number 66 in the wiki listing - they all are affected by this bug with kernels 2.6.31 Thanks for some feedback. Can we fix this for good for the pending devices? [1] http://www.vdr-portal.de/index.php?page=ThreadpostID=991041 In the post on vdr-portal you're showing the kernel-output of 2.6.32 I guess, do you still have the kernel output of 2.6.26 (or any before 2.6.32)? I think this line is not normal in your case: dibusb: This device has the Thomson Cable onboard. Which is default. But to be sure I need you to test. TUning the device is not needed with the old kernel, just plugging it and checking that line should be enough. -- Patrick. -- 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: Skystar 2 2.6 broken in kernel 2.6.38
Hi, On Saturday 02 April 2011 21:30:53 Steffen Barszus wrote: Hi I just installed natty and found that one of the drivers i use is broken. Is this a known issue ? [6.115925] [ cut here ] [6.115931] WARNING: at /build/buildd/linux-2.6.38/fs/proc/generic.c:323 __xlate_proc_name+0xbb/0xd0() [6.115933] Hardware name: EP45T-UD3LR Actually the driver is not broken as it still works. This is a warning issued by the core because the driver is using a bad string. There have been a lot of attempts to fix it in the past, but they have been lost somewhere on the road. I hope this time it will make it. best regards, -- Patrick Boettcher - KernelLabs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] dib0700: fix possible NULL pointer dereference
On Saturday 26 March 2011 19:23:56 Mariusz Kozlowski wrote: Seems like 'adap-fe' test for NULL was meant to be before we dereference that pointer. Signed-off-by: Mariusz Kozlowski m...@lab.zgora.pl Thanks, applied. -- Patrick Boettcher - KernelLabs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6.39] fixes - pull request
Hi Mauro, I cleaned my mailbox and collected some small fixes for 2.6.39 and for other version (stable is Cc'd in that case). Please pull from (sorry for the wrong branch name) http://git.linuxtv.org/pb/media_tree.git staging/for_v2.6.39 for [PATCH] Fix dependencies for Technisat USB2.0 DVB-S/S2 [PATCH] [media] dib0700: fix possible NULL pointer... FLEXCOP-PCI: fix __xlate_proc_name-warning for flexcop-pci DIB0700: fix typo in dib0700_devices.c Thanks, -- Patrick Boettcher - KernelLabs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media] dib0700: get rid of on-stack dma buffers
Hi Florian, On Sun, 3 Apr 2011, Florian Mickler wrote: Hi, since I got no reaction[1] on the vp702x driver, I proceed with the dib0700. There are multiple drivers in drivers/media/dvb/dvb-usb/ which use usb_control_msg to perform dma to stack-allocated buffers. This is a bad idea because of cache-coherency issues and on some platforms the stack is mapped virtually and also lib/dma-debug.c warn's about it at runtime. Patches to ec168, ce6230, au6610 and lmedm04 were already tested and reviewed and submitted for inclusion [2]. Patches to a800, vp7045, friio, dw2102, m920x and opera1 are still waiting for for review and testing [3]. This patch to dib0700 is a fix for a warning seen and reported by Zdenek Kabalec in Bug #15977 [4]. Florian Mickler (2): [media] dib0700: get rid of on-stack dma buffers For this one we implemented an alternative. See here: http://git.linuxtv.org/pb/media_tree.git?a=commit;h=16b54de2d8b46e48c5c8bdf9b350eac04e8f6b46 which I pushed, but obviously forgot to send the pull-request. This is done now. For the second patch I will incorperate it as soon as I find the time. best regards, -- Patrick -- 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 2/3] dvb-usb: multi-frontend support (MFE)
On Thursday 28 July 2011 00:23:06 Antti Palosaari wrote: On 07/28/2011 01:07 AM, Malcolm Priestley wrote: On Wed, 2011-07-27 at 16:06 -0300, Mauro Carvalho Chehab wrote: Em 25-07-2011 21:17, Antti Palosaari escreveu: Signed-off-by: Antti Palosaaricr...@iki.fi +adap-fe[i] = NULL; +/* In error case, do not try register more FEs, + * still leaving already registered FEs alive. */ I think that the proper thing to do is to detach everything, if one of the attach fails. There isn't much sense on keeping the device partially initialized. From memory, I recall the existing code doesn't detach the frontend even if the device driver forces an error. So, the device driver must detach the frontend first. Yes, if you return for example error (or fe == NULL) for .tuner_attach() it does not detach or deregister it - just silently discard all. I thought very many times those when implementing this and keep very careful not to change old functionality. The trouble is that dvb-usb is becoming dated as new drivers tend to work around it. No one likes to touch it, out of fear of breaking existing drivers. Yes, so true. I have thought that too. There is a lot of things I want to change but those are very hard without massive work. * We should have priv at the very first. No priv for FW DL example. * Remote keytable should be property of certain device model not adapter * There should be way to set count of adapter (and fe) in runtime (this is why I allowed to fail 2nd FE attach silently) * no probe (read eeprom etc) callback (I think read MAC could be renamed for probe) * no FE power control (GPIOs etc) that MFE patch adds this too * maybe probe1 and probe2 callbacks needed. sequence something like plug device = probe1 = download FW = probe2 = attach demod If I had more time I'd add * handle suspend/resume calls properly for buggy USB firmwares (iow: all devices I saw) -- Patrick Boettcher - KernelLabs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vp702x
Hi Florian, On Tue, 2 Aug 2011, Florian Mickler wrote: Hi Mauro! Hi Patrick! I realized this morning, that I broke vp702x (if it was working before) with my last patchseries. Sorry. :( I'm gonna follow up on this mail with a patch to hopefully fix it, but if nobody can test it, I'd say to rather revert my patchseries for v3.1 . It will then still use on-stack dma buffers and will produce a WARN() in the dmesg if it does so, but hopefully nothing bad happens. Patrick, do you still have the hardware to test this? I'm semi confident that I did not make any silly mistakes. :| (it compiles) I'm not sure whether I still have exactly this box. There were two versions and I got rid of at least one of them. I moved recently into a new house and right now a lot of things are hidden in some boxes somewhere... I'll try to find some time to check it. Don't ask me when that will be :). regards, -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DiBxxxx: fixes for 3.1/3.0
Hi Mauro, Would you please pull from git://linuxtv.org/pb/media_tree.git for_v3.0 for the following to changesets: [media] dib0700: protect the dib0700 buffer access [media] DiBcom: protect the I2C bufer access ? Those two changesets are fixing the remaining problems regarding the dma-on-stack-buffer-fix applied for the first time in 2.6.39, IIRC. They should go to stable 3.0 (as they are in my tree) and they can be cherry-picked to 3.1. We are preparing the same thing for 2.6.39 as the patches don't apply cleanly. Thanks to Javier Marcet for his help during the debug-phase. thanks and best regards, -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DiBxxxx: fixes for 3.1/3.0
Hi Mauro, On Wed, 3 Aug 2011, Patrick Boettcher wrote: Would you please pull from git://linuxtv.org/pb/media_tree.git for_v3.0 for the following to changesets: [media] dib0700: protect the dib0700 buffer access [media] DiBcom: protect the I2C bufer access I added a patch from Olivier which fixes wrongly used dprintks and replaces them by err()-calls. [media] dib0700: correct error message I herewith renew my PULL-request. The request now contains 3 changesets. best regards, -- Patrick -- 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] Does skystar dvb usb2 card work in linux ?
Hi Dominik, On Tue, 31 Mar 2009, Dominik Sito wrote: Tuesday 31 March 2009 19:39:28 a dehqan napisa?(a): In The Name Of God I'll be thankfull if you guide ; Does skystar dvb usb2 card work in linux ?Does it have linux driver ? has anyone tested it ? regards dehqan I think it's still undone. I have not clear information, but there would be any information about that. I'm not sure, but flexcop-usb isn't supported by USB 2.0. If i'm wrong please enlight me. Regards As of today there is no support for the USB2 version of Technisat's device. Technisat is not planning to add support, maybe they can't due to NDA(s) with their USB-2-PCI-bridge provider. I don't know for sure whether support can be added to the flexcop-usb.c-driver or not, but I assume not, because it is using a different USB-2-PCI-bridge and I have doubt that the USB high level interface is similar to the one used in flexcop-usb. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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] Drivers for Pinnacle pctv200e and pctv60e
Hi all, On Wed, 1 Apr 2009, Gabriele Dini Ciacci wrote: While there are indeed drivers based on the same FX2 chip in your device, it may be possible to reuse an existing driver, or you may need a whole new driver, depending on how much the firmware varies between your product versus the others. You may want to look at the pvrusb2 and cxusb drivers, which also use the FX2 chip, and see what similarities exist in terms of the API and command set. If it is not similar to any of the others, then writing a new driver is probably the correct approach. Regards, Devin Fine perfect, thanks, I will have a look asap and report for judge. I think you can save the time... When I started on a driver for those two devices 4 years ago, I had almost everything finished, but at that time we hadn't had a mt2060 driver available. I think I still have that driver somewhere, I'll check that and will send it to the list if I can find it. (at least the I2C-part was a little bit cleaner, IIRC). Gabriele, btw. there is nothing wrong with the I2C-address in your driver. setting 0x3e to the demod-address-field in the config-struct is totally fine. OTOH, your problem of unterstanding is most likely the notation used for i2c-addresses in linux: In Linux's drivers you'll find the 7-bit notation of the chip's i2c-address where as outside Linux, IMO, usually the 8-bit (wrong) notation is used: In the i2c-protocol the first byte of communication is the address plus a bit (the LSB) which is indicating wheter it is a read or write access. ie: AAAD, where A is address-bits and D is direction. In Linux what you'll see is e.g 0x1f which is the 7 bit address of 0x3e. The same for the tuner 0xc0 or 0xc2 is in Linux 0x60 and 0x61. Or the eeprom 0xa0 - 0x50 On the various USB-2-I2C interfaces most of the time the 8 bit notation is used, that why you'll have to shift the address 1 before filling the buffer in the i2c_transfer function. HTH, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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] Remove support for Genpix-CW3K (damages hardware)
Hi Alan, On Tue, 31 Mar 2009, Alan Nisota wrote: I have been informed by the manufacturer that the patch currently in the v4l tree to support the Genpix-CW3K version of the hardware will actually damage the firmware on recent units. As he seems to not want this hardware supported in Linux, and I do not know how to detect the difference between affected and not-affected units, I am requesting the immediate removal of support for this device. This patch removes a portion of the changeset dce7e08ed2b1 applied 2007-08-18 relating to this specific device. Signed off by: Alan Nisota anis...@gmail.com Don't you think it is enough to put a Kconfig option to activate the USB-IDs (by default: off) rather than throwing everything away? Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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] Drivers for Pinnacle pctv200e and pctv60e
Hi,
On Wed, 1 Apr 2009, Gabriele Dini Ciacci wrote:
On Tue, 31 Mar 2009 17:51:23 -0400
Devin Heitmueller devin.heitmuel...@gmail.com wrote:
On Tue, Mar 31, 2009 at 5:35 PM, Gabriele Dini Ciacci
dark.schnei...@iol.it wrote:
I it's so, say me how to make or where to look to create a profile
for the existing driver.
I am willing to do the work.
(when I first wrote the driver to me it seemed that this was the
simplet way.
Meanwhile I will try to look at the Cypress FX2
As Michael Krufky pointed out to me off-list, I was not exactly
correct here.
While there are indeed drivers based on the same FX2 chip in your
device, it may be possible to reuse an existing driver, or you may
need a whole new driver, depending on how much the firmware varies
between your product versus the others. You may want to look at the
pvrusb2 and cxusb drivers, which also use the FX2 chip, and see what
similarities exist in terms of the API and command set. If it is not
similar to any of the others, then writing a new driver is probably
the correct approach.
Regards,
Devin
Fine perfect, thanks,
Attached you can find my attempts from 2005. I2C should work, please
re-use this implementation as it nicely splits i2c_transfer from the rest
of the required functionality.
I think I still have the pctv 200e somewhere in a box... I may get it
back, undust it and try.
Patrick.
--
Mail: patrick.boettc...@desy.de
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch//* DVB USB compliant linux driver for the Pinnacle PCTV 200e DVB-T USB2.0
receiver.
*
* Copyright (C) 2005 Patrick Boettcher (patrick.boettc...@desy.de)
*
* 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, version 2.
*
* see Documentation/dvb/README.dvb-usb for more information
*/
#ifndef _DVB_USB_PCTV_H_
#define _DVB_USB_PCTV_H_
#define DVB_USB_LOG_PREFIX pctv
#include dvb-usb.h
extern int dvb_usb_pctv_debug;
#define deb_info(args...) dprintk(dvb_usb_pctv_debug,0x01,args)
#define CMD_I2C_WRITE 0x01
/* out: addr 1 olen buf[olen]
* in: 0x00 */
#define CMD_I2C_READ 0x02
/* out: addr 1 olen ilen buf[olen]
* in: 0x00 buf[ilen] */
#define CMD_GPIO_TUNER 0x16
/* out: onoff
* in: 0x00 */
//#define CMD_STREAMING 0x18
/* out: onoff
* in: 0x00 */
#endif
/* DVB USB compliant linux driver for the Pinnacle PCTV 200e DVB-T USB2.0
receiver.
*
* Copyright (C) 2005 Patrick Boettcher (patrick.boettc...@desy.de)
*
* 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, version 2.
*
* see Documentation/dvb/README.dvb-usb for more information
*/
#include pctv.h
#include mt352.h
/* debug */
int dvb_usb_pctv_debug;
module_param_named(debug,dvb_usb_pctv_debug, int, 0644);
MODULE_PARM_DESC(debug, set debugging level (1=debug (or-able)).
DVB_USB_DEBUG_STATUS);
static int pctv_msg(struct dvb_usb_device *d, u8 cmd,
u8 *wbuf, int wlen, u8 *rbuf, int rlen)
{
int ret;
u8 sndbuf[wlen+1],
rcvbuf[rlen+2];
memset(sndbuf,0,wlen+1);
sndbuf[0] = cmd;
memcpy(sndbuf[1],wbuf,wlen);
if ((ret = dvb_usb_generic_rw(d,sndbuf,wlen+1,rcvbuf,rlen+2,0)) 0)
return ret;
if (rcvbuf[0] != sndbuf[0] ||
rcvbuf[1] != 0x00)
err(probably a xfer error);
memcpy(rbuf,rcvbuf[2],rlen);
if (rlen 0)
deb_info(rbuf[0]: %x, rlen: %d\n,rbuf[0],rlen);
return 0;
}
static int pctv_i2c_xfer(struct i2c_adapter *adap,struct i2c_msg msg[],int num)
{
struct dvb_usb_device *d = i2c_get_adapdata(adap);
static u8 obuf[255];
int i,read;;
if (down_interruptible(d-i2c_sem) 0)
return -EAGAIN;
if (num 2)
warn(more than 2 i2c messages at a time is not handled yet.
TODO.);
for (i = 0; i num; i++) {
read = i+1 num (msg[i+1].flags I2C_M_RD);
obuf[0] = msg[i].addr 1;
obuf[1] = msg[i].len;
/* read request */
if (read)
obuf[2] = msg[i+1].len;
memcpy(obuf[2+read],msg[i].buf,msg[i].len);
if (read)
pctv_msg(d,CMD_I2C_READ,obuf,msg[i].len+3,msg[i+1].buf,msg[i+1].len);
else
pctv_msg(d,CMD_I2C_WRITE,obuf,msg[i].len+2,NULL,0);
i += read;
}
up(d-i2c_sem);
return i;
}
static u32 pctv_i2c_func(struct i2c_adapter *adapter)
{
return I2C_FUNC_I2C;
}
static struct i2c_algorithm pctv_i2c_algo = {
.name = Pinnacle PCTV USB I2C algorithm,
.id= I2C_ALGO_BIT,
.master_xfer = pctv_i2c_xfer
Re: Add Elgato EyeTV DTT deluxe to dibcom driver
On Sun, 19 Apr 2009, Antti Palosaari wrote: Armin Schenker kirjoitti: -.num_device_descs = 11, +.num_device_descs = 12, -struct dvb_usb_device_description devices[11]; +struct dvb_usb_device_description devices[12]; I don't comment about this patch but general. I didn't realized this value is allowed to increase when adding new devices. Due to that there is now three dvb_usb_device_properties in af9015 which makes driver a little bit complex. What we should do? Can I remove code from af9015 and increase dvb_usb_device_description count to about 30? What is biggest suitable value we want use, how much memory one entry will take. One dvb_usb_device_description is (2*15+1) * pointer-size. For PC-architecture it seems not big for me, but for other architectures it can be a problem. After 4 years in place I think we could evaluate whether another method for the module_device_id-table in all those dvb-usb-modules cannot be made differently, best case, without any fixed array-sizes. One very convenient option would be the driver_info-field in the usb_device_id-table, but it will be hard to convert all drivers and to keep some information we have today (like the device name) at the same time . Beside the size-problem there is still the issue of having the fixed indexes referenced by the dvb_usb_device_descriptor. No matter how I think about it, I still have such a link between the mod_id_table and the dvb_usb_device_description. If someone comes up with a good idea how to replace the current way of doing things, it'll be more than welcome. :) Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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
PULL request http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Mauro, please pull from my repo for the following change: Add Elgato EyeTV DTT deluxe to dibcom driver thanks, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: Add Elgato EyeTV DTT deluxe to dibcom driver
Hi Armin, On Sun, 19 Apr 2009, Armin Schenker wrote: This patch introduces support for DVB-T for the following dibcom based card: Elgato EyeTV DTT deluxe (USB-ID: 0fd9:0020) Thanks for the patch - I just applied it. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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] Remove support for Genpix-CW3K (damages hardware)
Hi Alan, On Tue, 31 Mar 2009, Alan Nisota wrote: I have been informed by the manufacturer that the patch currently in the v4l tree to support the Genpix-CW3K version of the hardware will actually damage the firmware on recent units. As he seems to not want this hardware supported in Linux, and I do not know how to detect the difference between affected and not-affected units, I am requesting the immediate removal of support for this device. This patch removes a portion of the changeset dce7e08ed2b1 applied 2007-08-18 relating to this specific device. Signed off by: Alan Nisota anis...@gmail.com Finally I found the time to work on your patch. I adapted it to not remove the code, but to put it under comments and #if 0's . Like that we protect normal users and advanced users need to do some efforts before getting in danger. I hope it is OK with you. regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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
PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Mauro, please pull from my repository for hte following changesets: - Remove support for Genpix-CW3K (damages hardware) - DIBUSB_MC : fix i2c to not corrupt eeprom in case of strange read pattern - Added USB IDs for Terratec T3 and T5 - [PATCH] Leadtek WinFast DTV Dongle H - Rewrote frontend-attach mechanism to gain noise-less deactivation of submodules - Reducing print-level of I2C error prints thanks, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: RE : Hauppauge Nova-TD-500 vs. T-500
On Wed, 20 May 2009, Thierry Lelegard wrote: 2) Since the TD-500 contains two aerial inputs instead of one for the T-500, I plugged in two antenna cables. Then, after some tests, I realized that this was a source of trouble: - Two antenna cables = lots of errors (mostly garbage sometimes, depending on the frequency). - Top input only = still many errors but much better on both tuners. - Bottom input only = got nothing on both tuners. Normally there is a RF switch + loop through to be controlled when switching between diversity (not supported in Linux) and dual-input - so that you can connect only one antenna but still doing the dual reception. If this switch is not handled correctly, I could imagine that the second input connected is receiving spurious signals and disturbing the first input, but there can be a lot of other reason as well. If I understand the code correctly, this switch (if it is really there :) ) is not handled correctly. I don't know the TD 500 card, so maybe the Hauppauge guys can help on that. (Basically the question is, which GPIO is to be toggled) 3) There are still many uncorrectable errors (TS packets with transport error indicator set) in the input. The amount of uncorrectable errors is approximately 0.1% (depending on the frequency), while I do not have any with the T-500 using the same antenna. When you tune both frontends at the same time, please try to not tune the same frequency. These errors occurs in groups of +/- 50 consecutive packets with TEI set. Sometimes, in the middle of packets with errors, one packet has TEI clear but it is still erroneous (invalid PID in this context for instance). Note: I forgot to mention in the initial post that I set the following option: options dvb_usb_dib0700 force_lna_activation=1 This option has no effect on the TD 500. Though, if there is an LNA, it could be handled usefully. regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: Making a DVB-S Transmitter
Hi Stefano, On Fri, 8 May 2009, Stefano Danzi wrote: Hi!! I and some others Ham radio operators are working on a pc-based dvb-s transmitter. Reference website are: http://www.m0dts.co.uk/datv.htm I read very quickly the website, interesting project :) Interfare between pc and transmitter is based on FTDI FT245 (usb fifo). Goal will be create a device like /dev/dvbs-tx, write into a mpeg-ts stream so kernel module convert it to a dvb-s signal and send it to the usb fifo. When you say, the kernel module converts it to a dvb-s signal? Do you mean you want to do a MPEG2-TS to DVB-S I/Q generator? Please describe closer what is the input format expected by the FTDI FT245. In general I would suggest that all the busy/important parts are done in userspace. Kernel modules should generally do nothing more that to copy data AS IS from host memory to device memory. Saying that any conversion, modulation or whatever should be done in user-space. If you're lucky you don't even need a kernel module to write to your USB device. There is a slight chance that using libusb to write the data to your hardware is sufficient. I think I read somewhere that there is a faster way to write data to a USB device with recent kernels than libusb from userspace, but maybe it was a dream. Check linux/Documentation to see whether you can find something. Good luck ;) Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Mauro, On Mon, 25 May 2009, Mauro Carvalho Chehab wrote: Em Wed, 20 May 2009 11:27:18 +0200 (CEST) Patrick Boettcher patrick.boettc...@desy.de escreveu: Hi Mauro, please pull from my repository for hte following changesets: Committed, thanks. Yet, I saw a few minor issues on one of your patch. Please fix and submit me later a cleanup. - Rewrote frontend-attach mechanism to gain noise-less deactivation of submodules This patch do also a good CodingStyle fixes. That's good (although it is generally better to have the codingsyle specific changes on a separate patch). It wasn't me to do the codingstyle changes. I didn't see the \'s in diff and I actually don't know why I didn't see them. Thanks for the other comments, I'll take them into consideration. regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Trent, On Mon, 25 May 2009, Trent Piepho wrote: On Mon, 25 May 2009, Mauro Carvalho Chehab wrote: + if (params-frequency = 4800 params-frequency = 15400) \ + bs = 0x09; + if (params-frequency = 16100 params-frequency = 43900) \ + bs = 0x0a; + if (params-frequency = 44700 params-frequency = 86300) \ + bs = 0x08; Just remove the backslash. You don't need they. The original code has this, but bs will be zero for a frequency between 154 MHz to 161 Mhz as welll as 439-447 MHz. Probably wrong. My guess is the data sheet says, low band 48 to 154 MHz, mid band 161 MHz to 439 MHz, etc., where 154 is the frequency of the last channel in the low band and 161 is the first channel in the mid band. Then someone translated this to code without really understanding what's going on. It should probably be: if (params-frequency 44300) bs = 0x08; else if (params-frequency 15750) bs = 0x0a; elsebs = 0x09; The tuner's limits should already be enforced elsewhere. Or just convert this to use dvb_pll. Thanks for pointing this out, can you please provide a patch for that? Preferably for the dvb_pll-solution? There seems only to be a handful of users which are really knowing that they are using this card and this driver to receive DVB-C in Linux, so testing it will be hard, but most likely it's not needed. regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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 DT USB XS Diversity/DiB0070+vdr: URB status: Value too large for defined data type+USB reset
Hi Marco,
On Mon, 1 Jun 2009, Marco Borm wrote:
I played a little bit with my problem and tried the latest source from the
repository, but EOVERFLOW still occurs seconds after starting vdr.
I activated the debug options of all, I hope, relevant modules now and got a
more detailed kern.log.
Maybe some expert can help me and take look at it.
Interesting section:
Jun 1 23:16:14 vdr kernel: function : dvb_dvr_poll
Jun 1 23:16:14 vdr kernel: function : dvb_dvr_poll
Jun 1 23:16:14 vdr kernel: function : dvb_dvr_poll
Jun 1 23:16:14 vdr kernel: dmxdev: section callback 4e f2 6c 40 0a e7
Jun 1 23:16:14 vdr kernel: dmxdev: section callback 50 f2 55 40 13 e1
Jun 1 23:16:14 vdr kernel: dmxdev: section callback 00 b0 1d 03 01 d1
Jun 1 23:16:14 vdr kernel: stop pid: 0x00a0, feedtype: 1
Jun 1 23:16:14 vdr kernel: setting pid (no): 160 00a0 at index 7 'off'
Jun 1 23:16:14 vdr kernel: function : dvb_dmxdev_filter_set
Jun 1 23:16:14 vdr kernel: start pid: 0x00e0, feedtype: 1
Jun 1 23:16:14 vdr kernel: setting pid (no): 224 00e0 at index 7 'on'
Jun 1 23:16:14 vdr kernel: function : dvb_dvr_poll
Jun 1 23:16:14 vdr kernel: function : dvb_dvr_poll
BOOM - Jun 1 23:16:14 vdr kernel: urb completition error -75.
Hmm?!
This logs aren't very helpful, but I find something interesting with
Wireshark and usbmon:
device - host
URB type: URB_COMPLETE ('C')
URB transfer type: URB_BULK (3)
Endpoint: 0x83
Device: 13
Data: present (0)
URB status: Value too large for defined data type (-EOVERFLOW) (-75)
URB length [bytes]: 39424
Data length [bytes]: 39424
after this URB I get a URB transfer type: URB_INTERRUPT (1) and all goes
to hell.
Its also interesting that the URB+data length in the failure package is
39424 but URB length [bytes]: 39480 in every package before that.
Definitely interesting. This is a known issue for the dib0700 device,
which happens on some USB host controllers. Actually which one do you use?
As I know this device works without problems under linux for other people,
so I'm wondering why. I searched but found nothing about such a problem.
Yeah, but are they using 2.6.29?
In fact, since 2 days I'm having the T5 Terratec device, which seems to be
similar to your device, I'm going to try it soon. To experience whether
there are similar problems.
Do you connect the device directly to the PC or is there an extension
cable or another USB hub in between?
Patrick.
--
Mail: patrick.boettc...@desy.de
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/
--
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: dib0700 Nova-TD-Stick problem
Hi Soeren, On Wed, 3 Jun 2009, soeren.m...@stud.uni-hannover.de wrote: Soeren.Moch wrote: For a few weeks I use a Nova-TD-Stick and was annoyed with dvb stream errors, although the demod bit-error-rate (BER/UNC) was zero. I could track down this problem to dib0700_streaming_ctrl: When one channel is streaming and the other channel is switched on, the stream of the already running channel gets broken. I think this is a firmware bug and should be fixed there, but I attach a driver patch, which solved the problem for me. (Kernel 2.6.29.1, FW 1.20, Nova-T-Stick + Nova-TD-Stick used together). Since I had to reduce the urb count to 1, I consider this patch as quick hack, not a real solution. Probably the same problem exists with other dib0700 diversity/dual devices, without a firmware fix a similar driver patch may be helpful. Regards, Soeren Hi Patrick, do you see any chance that somebody will fix the firmware? No. :( If not, can you take into consideration to remove the dib0700_streaming_ctrl callback as in the (again) attached patch so solve the switch-on problem? The patch runs flawlessly on my vdr system for weeks now. There are no negative side effects from reducing the urb count to 1. There might be a real problem in the dib0700 for the streaming_ctrl function. I have to check that. If you prefer a patch that removes the callback for all dib0700 devices or only for all dual devices, I can prepare that. But I can test it only with Nova-T-Stick and Nova-TD-Stick. I have some new devices here to test as well, I will try to do it during the week(end). Sorry for not reacting in the first place. But I really couldn't do anything at that time. regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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 DT USB XS Diversity/DiB0070+vdr: URB status: Value too large for defined data type+USB reset
Hi Marco, On Tue, 2 Jun 2009, Marco Borm wrote: Definitely interesting. This is a known issue for the dib0700 device, which happens on some USB host controllers. Actually which one do you use? USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller Hmm, looks bad: http://www.google.com/search?q=dib0700+sb700 But I am wondering if this could really be some bigger linux USB-stack problem, because it runs with Linux/totem for hours (mplayer was wrong). For me it looks like vdr uses some feature the driver doesn't handle correctly. Isn't the EOVERFLOW some local error value from the usb stack generates if some given buffer was to small? :(. It is a long story for the SB700 ATI HC ... It turned out for DiBcom that ATI fixed the HC-driver for Windows to make things work correctly. At some point in time they provided a patch for Linux and it was actually included in 2.6.21 or 22 . There is some work going on on 2.6.30 for almost similar problems for another device, maybe it is worth to either: 1) try out latest 2.6.30 releases 2) do a (manual) bisect with older kernel to find out which change has made things worse (this is extremely long) Do you connect the device directly to the PC or is there an extension cable or another USB hub in between? I tried it with a longer and the short cable which was in the package, never directly and never with a hub. Knowing that you have the SB700, I can surely say, it's not the cable, but the controller. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: AVerTV Volar Black HD: i2c oops in warm state on mips
Hi Jan, On Fri, 5 Jun 2009, Jan Nikitenko wrote: The used dvb-t sources work ok on intel x86 platform (used kernel 2.6.24), but on mips, there seems to be some problem with i2c after switch of the tuner into the warm state via firmware load (tested with 2.6.25.17 and 2.6.29-rc7 mips kernels, with the same result) - it seems to me, that adap pointer (or the structure) is not valid (adap-algo is NULL): [..] Tried two mips32 little endian platforms: Broadcom BCM3302 /asus wl500gp router/ and alchemy au1550 with the same result. Any ideas why this happens? At some point in time, someone said, that using stack-allocated buffers for USB transfers is not cross-platform-save. IIRC, it was on MIPS-platforms where this became obvious. I haven't looked into the af-driver, but I guess that's the problem here. regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: Can't find firmware when resuming
Hi Gonsolo, I'm adding the LMML. On Fri, 5 Jun 2009, Gonsolo wrote: Hello! Is the following problem known? The Hauppauge Nova-T stick hangs the resume for 60 seconds. The firmware is there and I can watch TV before suspending. From my dmesg: [34258.180072] usb 1-1: reset high speed USB device using ehci_hcd and address 4 [34258.312799] dvb-usb: found a 'Hauppauge Nova-T Stick' in cold state, will try to load a firmware [34258.312805] usb 1-1: firmware: requesting dvb-usb-dib0700-1.20.fw [34318.312097] dvb-usb: did not find the firmware file. (dvb-usb-dib0700-1.20.fw) Please see linux/Documentation/dvb/ for mor e details on firmware-problems. (-2) You are resuming from suspend2disk, right? The driver is using a standard method to retrieve the firmware buffer from user-space, if it does not work, it is a problem of you installation, namely udev. OTOH, the dvb-usb-framework is not ready to handle a suspend2disk correctly. E.g. being able to suspend2disk while watching TV will work, but when resuming it will be seen as a device disconnect and the application will stop to work. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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] flexcop-pci: add suspend/resume support
Hi Matthias, On Tue, 26 May 2009, Matthias Schwarzott wrote: This patch adds suspend/resume support to flexcop-pci driver. I could only test this patch with the bare card, but without having a DVB-S signal. I checked it with and without running szap (obviously getting no lock). It works fine here with suspend-to-disk on a tuxonice kernel. As I'm notoriously out of time I haven't yet checked the functionality with suspend though I'm looking forward to do so, because it would extremely nice to use suspend2disk for shutting down rather than shutdown. Setting of hw-filter in resume is done the same way as the watchdog does it: Just looping over fc-demux.feed_list and running flexcop_pid_feed_control. Where I am unsure is the order at resume. For now hw filters get started first, then dma is re-started. Do I need to give special care to irq handling? Good question. I think starting the streaming the same way as it is done in normal operation would do the trick, but I'm not sure whether this is possible for suspend/resume. I need to try. Thanks a lot for the patch, I will try to adapt it also for dvb-usb. Like that all dvb-usb-based device will become resumable in one shot :). But time will tell when. :/ Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: dib0700 Nova-TD-Stick problem
Hi Soeren, On Wed, 3 Jun 2009, soeren.m...@stud.uni-hannover.de wrote: Soeren.Moch wrote: For a few weeks I use a Nova-TD-Stick and was annoyed with dvb stream errors, although the demod bit-error-rate (BER/UNC) was zero. I could track down this problem to dib0700_streaming_ctrl: When one channel is streaming and the other channel is switched on, the stream of the already running channel gets broken. I think this is a firmware bug and should be fixed there, but I attach a driver patch, which solved the problem for me. (Kernel 2.6.29.1, FW 1.20, Nova-T-Stick + Nova-TD-Stick used together). Since I had to reduce the urb count to 1, I consider this patch as quick hack, not a real solution. Probably the same problem exists with other dib0700 diversity/dual devices, without a firmware fix a similar driver patch may be helpful. Regards, Soeren Hi Patrick, do you see any chance that somebody will fix the firmware? :/ . If not, can you take into consideration to remove the dib0700_streaming_ctrl callback as in the (again) attached patch so solve the switch-on problem? I'd rather fix the streaming-enable command, which might be not correctly implemented. Need to check. :( The patch runs flawlessly on my vdr system for weeks now. There are no negative side effects from reducing the urb count to 1. Hmm, on fast systems certainly not, but once the system is loaded or old there might be data losses. It would be nice to have other people trying this workaround on other cards so that we know that it really helps and not just solves the problem for you. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Trent, On Wed, 27 May 2009, Trent Piepho wrote: On Tue, 26 May 2009, Patrick Boettcher wrote: MHz to 161 Mhz as welll as 439-447 MHz. Probably wrong. My guess is the data sheet says, low band 48 to 154 MHz, mid band 161 MHz to 439 MHz, etc., where 154 is the frequency of the last channel in the low band and 161 is the first channel in the mid band. Then someone translated this to code without really understanding what's going on. It should probably be: if (params-frequency 44300) bs = 0x08; else if (params-frequency 15750) bs = 0x0a; elsebs = 0x09; The tuner's limits should already be enforced elsewhere. Or just convert this to use dvb_pll. Thanks for pointing this out, can you please provide a patch for that? Preferably for the dvb_pll-solution? I've done this, but found some more mistakes in the flexcop code wrt frontend attachment. In patch 7469 you changed a failure path dvb_frontend_detach(fc-fe) into a fc-fe-ops-release(fc-fe), which isn't correct. There is more stuff dvb_frontend_detach() does besides call the main release method. The various attach functions in flexcop-fe-tuner don't return success/fail, which is a problem when frontend attachment partially fails. For instance if mt352 attachment works but dvb-pll attachment then fails the driver will think everything is ok because fc-fe is non-NULL, but the tuner will not work. It makes more sense to consider this an error and clean up. There are a couple other places where frontend attachment can partially fail where I wasn't entirely sure what's right. In skystar2_rev27_attach(), after the s5h1420 demod is attached, attachment of a ISL6421 LNB and ITD1000 tuner is attempted. If these fail an error message is printed but the rest of the code will consider the frontend to be successfully attached. Can the frontend work if the ISL6421 or ITD1000 didn't attach (which can happen if the driver isn't present even if the hardware is fine)? I'm guessing not and called these cases an error. If it's not an error, then the err() printout should probably be warning or info level. Does this patch to fix these problems look ok? In fact, everything looks correct in my eyes. I'll ask Mauro to pull any minute from now. I even have an explaination why the failing attach of the itd1000 was not errored out: when I did the development I was using a userspace proprietary driver to validate, for that I needed the demod to be attached... Thanks for cleaning up this mess. best regards, Patrick. -- 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: dib3000mc.c and dib7000p.c compiler warnings
Hi Hans, On Sun, 14 Jun 2009, Hans Verkuil wrote: Hi Patrick, The daily build reports these warnings for dib3000mc.c and dib7000p.c: /marune/build/v4l-dvb-master/v4l/dib3000mc.c: In function 'dib3000mc_i2c_enumeration': /marune/build/v4l-dvb-master/v4l/dib3000mc.c:863: warning: the frame size of 1508 bytes is larger than 1024 bytes /marune/build/v4l-dvb-master/v4l/dib7000p.c: In function 'dib7000p_i2c_enumeration': /marune/build/v4l-dvb-master/v4l/dib7000p.c:1341: warning: the frame size of 1568 bytes is larger than 1024 bytes In both cases a big state struct is allocated on the stack. Would it be possible to optimize that? I agree that this is ugly and in fact I already have a solution for that. But it's not ready as a patch nor can it published :(. I won't be able to work on it before mid-July. But then I will provide a solution. thanks for raising this important problem, Patrick. -- 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: dib3000mb dvb-t with kernel 2.6.32-rc3 do not work
Hi Mario, On Mon, 5 Oct 2009, Mario Bachmann wrote: with kernel 2.6.30.8 my TwinhanDTV USB-Ter USB1.1 / Magic Box I worked. Now with kernel 2.6.32-rc3 (and 2.6.31.1) the modules seems to be loaded fine, but tzap/kaffeine/mplayer can not tune to a channel: dmesg says: dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device' in warm state. dvb-usb: will use the device's hardware PID filter (table count: 16). DVB: registering new adapter (TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device) DVB: registering adapter 0 frontend 0 (DiBcom 3000M-B DVB-T)... dibusb: This device has the Thomson Cable onboard. Which is default. input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:04.0/usb4/4-2/input/input5 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device successfully initialized and connected. usbcore: registered new interface driver dvb_usb_dibusb_mb [..] and so on. The signal-values are zero or near zero, but when i boot the old kernel 2.6.30.8, t can tune without problems. In a personal email to me you are saying that the differences between dibusb-common.c in 2.6.30.8 and 2.6.32-rc3 are the main cause for the problem. Is it possible for you find out which exact change is causing the trouble? With the v4l-dvb-hg-repository it is possible to get each intemediate version of this file. Afaics, there is only 3 modifications for the timeframe we are talking about. best regards, -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pctv nanoStick Solo not recognized
Hi Matteo, Sorry for being quite in the first place. On Tue, 20 Oct 2009, Matteo Miraz wrote: Devin, it worked. I added the new vendor, and changed the other entry. I'm wondering if exists a pinnacle pctv 73e se usb device... attached to this mail there is the (easy) patch. This patch is in fact the right way to do things. Acked-by: Patrick Boettcher pboettc...@kernellabs.com While you are at it, can you please also changed the vendor ID for the PCTV282E-device to PCTVSYSTEMS and file a new patch? thanks for the help, -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ISDB-T tuner
Hi all, On Tue, 20 Oct 2009, Akihiro TSUKADA wrote: And just for you information, in addition to EarthSoft PT1, there is a driver for 'Friio' ISDB-T USB receiver (which I wrote;) , and it is already included in the main repository. Dibcom is maybe for Brazil and may or may not work in Japan. I'm just stepping in here to clarify Dibcom's ISDB-T support: it's purely limited to demodulation with the dib8000-driver. Meaning, using a Dibcom reference-design in Japan will give you the BCAS encrypted transport stream, not more. This way is primarily used in set-top-boxes and car-receivers and things like that. -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New DibCom based ISDB-T device
Hi Mauro, On Tue, 17 Nov 2009, Mauro Carvalho Chehab wrote: Hi Patrick, A friend of mine got a Geniatech S870 ISDB-T card. According to him, this device is based on stk8090 chipset and wants to use it in Brazil. The board has the following USB ID: Bus 002 Device 002: ID 10b8:1fa0 DiBcom I was wandering if the existing dib8000 driver will work with such device. If so, would the following patch be enough? No. I have a preliminary patch ready to support this board, but it requires some review. If I'm informed correctly, the client (Geniatech or a subcontractor) has this patch available for testing. I'm working on having it available for the 2.6.33 merge-window. best regards, -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-usb-friio: accept center-shifted frequency
Hi Akihiro, On Thu, 12 Nov 2009, Akihiro TSUKADA wrote: From: Akihiro Tsukada ts...@yahoo.co.jp This patch adds a fix to accept frequency with its center shifted. The driver used to accept center frequencies of the normal UHF band channels, but in ISDB-T, center frequency is shifted with 1/7MHz. It was shifted internally in the driver, but this patch enables to accept both types of frequency. Priority: normal Signed-off-by: Akihiro Tsukada ts...@yahoo.co.jp --- friio-fe.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/linux/drivers/media/dvb/dvb-usb/friio-fe.c b/linux/drivers/media/dvb/dvb-usb/friio-fe.c --- a/linux/drivers/media/dvb/dvb-usb/friio-fe.c +++ b/linux/drivers/media/dvb/dvb-usb/friio-fe.c @@ -134,11 +134,13 @@ static int jdvbt90502_pll_set_freq(struc deb_fe(%s: freq=%d, step=%d\n, __func__, freq, state-frontend.ops.info.frequency_stepsize); /* freq - oscilator frequency conversion. */ - /* freq: 473,000,000 + n*6,000,000 (no 1/7MHz shift to center freq) */ - /* add 400[1/7 MHZ] = 57.142857MHz. 57MHz for the IF, */ - /* 1/7MHz for center freq shift */ + /* freq: 473,000,000 + n*6,000,000 [+ 142857 (center freq. shift)] */ f = freq / state-frontend.ops.info.frequency_stepsize; - f += 400; + /* add 399[1/7 MHZ] = 57MHz for the IF */ + f += 399; + /* add center frequency shift if necessary */ + if (f % 7 == 0) + f++; pll_freq_cmd[DEMOD_REDIRECT_REG] = JDVBT90502_2ND_I2C_REG; /* 0xFE */ pll_freq_cmd[ADDRESS_BYTE] = state-config.pll_address 1; pll_freq_cmd[DIVIDER_BYTE1] = (f 8) 0x7F; I applied your patch, I will later asked Mauro to pull it into main. thanks, -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dibusb-common.c FE_HAS_LOCK problem
On Sat, 7 Nov 2009, Mario Bachmann wrote:
Hi there,
I tried linux-2.6.31.5 and tuning still does not work:
tuning to 73800 Hz
video pid 0x0131, audio pid 0x0132
status 00 | signal | snr | ber 001f | unc |
status 00 | signal | snr | ber 001f | unc |
status 00 | signal | snr | ber 001f | unc |
status 04 | signal | snr | ber 001f | unc |
With some changes for the following file it works again:
/usr/src/linux/drivers/media/dvb/dvb-usb/dibusb-common.c
diff -Naur dibusb-common.c-ORIGINAL dibusb-common.c
--- dibusb-common.c-ORIGINAL2009-11-07 10:30:43.705344308 +0100
+++ dibusb-common.c 2009-11-07 10:33:49.969345253 +0100
@@ -133,17 +133,14 @@
for (i = 0; i num; i++) {
/* write/read request */
- if (i+1 num (msg[i].flags I2C_M_RD) == 0
- (msg[i+1].flags I2C_M_RD)) {
+ if (i+1 num (msg[i+1].flags I2C_M_RD)) {
if (dibusb_i2c_msg(d, msg[i].addr,
msg[i].buf,msg[i].len,
msg[i+1].buf,msg[i+1].len) 0)
break;
i++;
- } else if ((msg[i].flags I2C_M_RD) == 0) {
+ } else
if (dibusb_i2c_msg(d, msg[i].addr,
msg[i].buf,msg[i].len,NULL,0) 0)
break;
- } else
- break;
}
Doing it is reverting a fix which avoids that uncontrolled i2c-access from
userspace is destroying the USB-eeprom.
I understand that this is breaking the tuning for your board. I'm just not
understanding why.
If you have some time to debug this issue, could you please try the
following:
One of the devices for your board is trying to do an I2c access which is
falling into the last 'else'-branch - can you add a printk to find out
which one it is? The access must be wrongly constructed and must be fixed
in that driver.
thanks,
PS: if you don't have time to do it, please tell so.
--
Patrick
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy T-Express
Hi Aurelio, On Thu, 5 Nov 2009, Aurelio Grego wrote: Hi Patrick, I'm writing you about a problem with Terratec Cinergy T-Express DVB-T USB card. The card is recognized by kernel, after compiling v4l-dvb sources (v4l-dvb-fd679bbd8bb3.tar.gz). Despite all, kaffeine and w_scan utility are not able to receive any channels. I've downloaded the required firmware from here: http://www.wi-bw.tfh-wildau.de/~pboettch/home/files/dvb-usb-dib0700-1.20.fw What can I do? I used recent Linux distributions with kernel 2.6.31, but with no luck. Thanks for your help and support. dy...@linux-t9fm:~ dmesg | grep dvb dvb-usb: found a 'Terratec Cinergy T Express' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' dvb-usb: found a 'Terratec Cinergy T Express' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. dvb-usb: schedule remote query interval to 50 msecs. dvb-usb: Terratec Cinergy T Express successfully initialized and connected. usbcore: registered new interface driver dvb_usb_dib0700 dy...@linux-t9fm:~ lsusb Bus 007 Device 005: ID 0ccd:0062 TerraTec Electronic GmbH dy...@linux-t9fm:~/Desktop/w_scan-20090504 ./w_scan -ft -c IT -X /home/dylan /channels.conf w_scan version 20090502 (compiled for DVB API 5.0) using settings for ITALY DVB aerial DVB-T Europe frontend_type DVB-T, channellist 4 output format czap/tzap/szap/xine Info: using DVB adapter auto detection. /dev/dvb/adapter0/frontend0 - DVB-T DiBcom 7000PC: good :-) Using DVB-T frontend (adapter /dev/dvb/adapter0/frontend0) -_-_-_-_ Getting frontend capabilities-_-_-_-_ Using DVB API 5.0 frontend DiBcom 7000PC supports INVERSION_AUTO QAM_AUTO TRANSMISSION_MODE_AUTO GUARD_INTERVAL_AUTO HIERARCHY_AUTO FEC_AUTO -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Scanning 7MHz frequencies... 177500: (time: 00:00) 184500: (time: 00:03) 191500: (time: 00:06) 198500: (time: 00:09) 205500: (time: 00:12) 212500: (time: 00:16) 219500: (time: 00:19) 226500: (time: 00:22) Scanning 8MHz frequencies... 474000: (time: 00:25) (time: 00:27) signal ok: QAM_AUTO f = 474000 kHz I999B8C999D999T999G999Y999 It seems that your reception quality is not good enough. Which means, that either the antenna or the hardware or the driver are not correctly set-up/written for your board. Can you try the windows driver which with the same antenna position? best regards, -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH: better support for INTUIX DVB stick boot
Hi, On Wed, 30 Sep 2009, Pedro Andres Aranda Gutierrez wrote: I have a INTUIX/LITEON DVB USB adapter. It boots correctly, but no frontend is attached. The following patch corrects this behaviour: [..] Since a couple of years ago, when I bought the stick, I have been using this alternative patch, which has not made it to the kernel, apparently because it introduced this 1 second delay Applied, thanks. -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/
Hi Mauro, can you please pull from http://kernellabs.com/hg/~pboettcher/v4l-dvb/ for 1) PATCH: better support for INTUIX DVB stick boot 2) [PATCH] fix genpix driver (no 8psk lock) 3) Add support for PCTV 74e (Pinnacle) + fix USB vendor IDs 4) [PATCH] dvb-usb-friio: accept center-shifted frequency 2 - is fixing a regression in 2.6.32 and should go there if possible. (I forgot to set priority: high) thanks for pulling, -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/
Hi Devin, On Thu, 19 Nov 2009, Devin Heitmueller wrote: On Thu, Nov 19, 2009 at 12:43 PM, Patrick Boettcher pboettc...@kernellabs.com wrote: Hi Mauro, can you please pull from http://kernellabs.com/hg/~pboettcher/v4l-dvb/ for 1) PATCH: better support for INTUIX DVB stick boot 2) [PATCH] fix genpix driver (no 8psk lock) 3) Add support for PCTV 74e (Pinnacle) + fix USB vendor IDs 4) [PATCH] dvb-usb-friio: accept center-shifted frequency 2 - is fixing a regression in 2.6.32 and should go there if possible. (I forgot to set priority: high) thanks for pulling, Patrick, According to my contact at PCTV, the three devices in question (the 73e/73eSE, 282e/282eNano, and PCTV 74e/74ePico) can have either the old *or* the new USB ID. Your patch changes them to the new ID exclusively (effectively removing entries with the old ID), which will cause breakage for people who had versions of the board with the old ID. Your patch needs to add new entries for the versions of the board with the new ID. It cannot replace the old versions. According to DiBcom's contact at Pinnacle, it was a mistake to add the Product IDs with Pinnacle's USB vendor ID and it needed to be replaced. I'd be not surprised if that is not correct and that you're right. I will fix it and will try to clarify the situation internally. thanks for the attention, PS: how do I do a 'git rebase -i' + 'git reset HEAD~1' with HG (without installing additional stuff by hand)? - Nevermind, I will redo all the commits by hand. -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dibusb-common.c FE_HAS_LOCK problem
Hi Mario,
On Sat, 21 Nov 2009, grafgrim...@gmx.de wrote:
Am Thu, 19 Nov 2009 16:37:18 +0100 (CET)
schrieb Patrick Boettcher pboettc...@kernellabs.com:
On Sat, 7 Nov 2009, Mario Bachmann wrote:
Hi there,
I tried linux-2.6.31.5 and tuning still does not work:
tuning to 73800 Hz
video pid 0x0131, audio pid 0x0132
status 00 | signal | snr | ber 001f | unc |
status 00 | signal | snr | ber 001f | unc |
status 00 | signal | snr | ber 001f | unc |
status 04 | signal | snr | ber 001f | unc |
With some changes for the following file it works again:
/usr/src/linux/drivers/media/dvb/dvb-usb/dibusb-common.c
diff -Naur dibusb-common.c-ORIGINAL dibusb-common.c
--- dibusb-common.c-ORIGINAL2009-11-07 10:30:43.705344308 +0100
+++ dibusb-common.c 2009-11-07 10:33:49.969345253 +0100
@@ -133,17 +133,14 @@
for (i = 0; i num; i++) {
/* write/read request */
- if (i+1 num (msg[i].flags I2C_M_RD) == 0
- (msg[i+1].flags I2C_M_RD)) {
+ if (i+1 num (msg[i+1].flags I2C_M_RD)) {
if (dibusb_i2c_msg(d, msg[i].addr,
msg[i].buf,msg[i].len,
msg[i+1].buf,msg[i+1].len) 0)
break;
i++;
- } else if ((msg[i].flags I2C_M_RD) == 0) {
+ } else
if (dibusb_i2c_msg(d, msg[i].addr,
msg[i].buf,msg[i].len,NULL,0) 0)
break;
- } else
- break;
}
Doing it is reverting a fix which avoids that uncontrolled i2c-access from
userspace is destroying the USB-eeprom.
I understand that this is breaking the tuning for your board. I'm just not
understanding why.
If you have some time to debug this issue, could you please try the
following:
One of the devices for your board is trying to do an I2c access which is
falling into the last 'else'-branch - can you add a printk to find out
which one it is? The access must be wrongly constructed and must be fixed
in that driver.
thanks,
PS: if you don't have time to do it, please tell so.
--
Patrick
http://www.kernellabs.com/
I do not understand exactly. printk what? Could you please give me a
complete piece of code with the printk command? Would be great!
My printk-tries ends up in an Oops.
There is a
} else
break;
sequence in dibusb_i2c_xfer
instead of break, please add something like
printk(KERN_ERR - hello stupid I2C access \n);
recompile and load the new module, then check whether the line is
appearing in /var/log/messages or /var/log/syslog when you tune the board.
If this is the case, try to identify which device is issuing the access by
printing the i2c-address of struct i2c_msg.
HTH,
--
Patrick
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dibusb-common.c FE_HAS_LOCK problem
On Mon, 23 Nov 2009, Mario Bachmann wrote:
sequence in dibusb_i2c_xfer
instead of break, please add something like
printk(KERN_ERR - hello stupid I2C access \n);
recompile and load the new module, then check whether the line is
appearing in /var/log/messages or /var/log/syslog when you tune the board.
If this is the case, try to identify which device is issuing the access by
printing the i2c-address of struct i2c_msg.
HTH,
--
Patrick
http://www.kernellabs.com/
Hello Patrick,
I tried it with Kernel 2.6.31.6 (same as before).
I made the printk-change, recompiled and reloaded the modules and pluged in my
Twinhan Magic Box...
It definately jumps in the last else-branch and shows hello stupid I2C
access, but no KERN_ERR ?!
KERN_ERR is a prefix for printk to define the message priority to high.
(to have it in syslog or messages)
dibusb: This device has the Thomson Cable onboard. Which is default.
- hello stupid I2C access
Hmm... where is this coming from:
can you write it like that:
else {
printk(...);
dump_stack();
}
Hey, without the break-command, tuning seems to work:
$ tzap pro7 -r
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/home/grafrotz/.tzap/channels.conf'
tuning to 73800 Hz
video pid 0x0131, audio pid 0x0132
status 00 | signal | snr | ber 001f | unc |
status 1f | signal 0b20 | snr 008d | ber 001f | unc | FE_HAS_LOCK
status 1f | signal f4dd | snr 0077 | ber 0770 | unc | FE_HAS_LOCK
status 1f | signal | snr 008c | ber 0770 | unc | FE_HAS_LOCK
We are close to identify the drivers in charge for the stupid I2c access.
--
Patrick Boettcher - Kernel Labs
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dibusb-common.c FE_HAS_LOCK problem
On Mon, 23 Nov 2009, grafgrim...@gmx.de wrote: [..] - hello stupid I2C access Pid: 255, comm: khubd Tainted: P A 2.6.31.6 #1 Call Trace: [a0042292] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common] [81341dc1] ? i2c_transfer+0x91/0xe0 [a0059081] ? dib3000_write_reg+0x51/0x70 [dib3000mb] [a00855c9] ? dvb_pll_attach+0xa9/0x238 [dvb_pll] [..] Voila. This is the access with makes the dvb-pll-driver not create the tuner driver. This is (I forgot the correct name) read-without-write-i2caccess. It is bad handled by the dibusb-driver and it can destroy the eeprom on the USB side. Please try whether the attached patch fixes the whole situation for you. If so, please send back a line like this: Tested-by: Your name email thanks, -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dibusb-common.c FE_HAS_LOCK problem
On Mon, 23 Nov 2009, Patrick Boettcher wrote:
On Mon, 23 Nov 2009, grafgrim...@gmx.de wrote:
[..]
- hello stupid I2C access
Pid: 255, comm: khubd Tainted: P A 2.6.31.6 #1
Call Trace:
[a0042292] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common]
[81341dc1] ? i2c_transfer+0x91/0xe0
[a0059081] ? dib3000_write_reg+0x51/0x70 [dib3000mb]
[a00855c9] ? dvb_pll_attach+0xa9/0x238 [dvb_pll]
[..]
Voila.
This is the access with makes the dvb-pll-driver not create the tuner driver.
This is (I forgot the correct name) read-without-write-i2caccess. It is bad
handled by the dibusb-driver and it can destroy the eeprom on the USB side.
Please try whether the attached patch fixes the whole situation for you.
If so, please send back a line like this:
Tested-by: Your name email
The patch attached.
--
Patrick Boettcher - Kernel Labs
http://www.kernellabs.com/diff -r 52da57b5e800 linux/drivers/media/dvb/dvb-usb/dibusb-common.c
--- a/linux/drivers/media/dvb/dvb-usb/dibusb-common.c Thu Nov 19 17:15:37
2009 +0100
+++ b/linux/drivers/media/dvb/dvb-usb/dibusb-common.c Mon Nov 23 13:20:10
2009 +0100
@@ -142,8 +142,13 @@
} else if ((msg[i].flags I2C_M_RD) == 0) {
if (dibusb_i2c_msg(d, msg[i].addr,
msg[i].buf,msg[i].len,NULL,0) 0)
break;
- } else
- break;
+ } else if (msg[i].addr != 0x50) {
+ /* 0x50 is the address of the eeprom - we need to
protect it
+* from dibusb's bad i2c implementation: reads without
+* writing the offset before are forbidden */
+ if (dibusb_i2c_msg(d, msg[i].addr, NULL, 0, msg[i].buf,
msg[i].len) 0)
+ break;
+ }
}
mutex_unlock(d-i2c_mutex);
Re: PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/
On Mon, 30 Nov 2009, Devin Heitmueller wrote: On Mon, Nov 30, 2009 at 12:28 PM, Patrick Boettcher - Add support for PCTV 74e (Pinnacle) + fix USB vendor IDs Patrick, You added the USB ID for the 74e? Is that the result of actually trying it with the hardware? As far as I know, the 74e is not a Dibcom design. At that time I believed that the design should be a dib7770-design based on the list you gave in this email, which looked like a copy-paste of a the .inf-file of their windows driver: http://osdir.com/ml/linux-media/2009-10/msg00598.html No re-reading the mail, I see that you're not sure. So another misunderstanding. I will fix again the hg. thanks for the feedback. -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/
Hi again, On Mon, 30 Nov 2009, Devin Heitmueller wrote: On Mon, Nov 30, 2009 at 12:28 PM, Patrick Boettcher - Add support for PCTV 74e (Pinnacle) + fix USB vendor IDs Patrick, You added the USB ID for the 74e? Is that the result of actually trying it with the hardware? As far as I know, the 74e is not a Dibcom design. You are right, the device is an Abilis design, where, as far as I know, no Linux or GPL driver is yet written or available. Mauro: I added a patch which removes the USB IDs to my repository. The repo is now ready to be pulled. thanks, -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
Hi, On Tue, 1 Dec 2009, Devin Heitmueller wrote: On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Just taking an example from the dibcom0700 driver (as the same driver supports several different RC5 and NEC codes at the same time), the kernel table has several keycodes added there, all working at the same time. Providing that the scancodes won't overlap, you can map two different scancodes (from different IR's) to return the same keycode (table is not complete - I just got a few common keycodes): Mauro, Just to be clear, the dib0700 does not actually support receiving RC5 or NEC codes at the same time. You have to tell the chip which mode to operate in, via a REQUEST_SET_RC to the firmware (see dib0700_core.c:405). The em28xx works the same way (you have to tell it what type of IR format to receive). The fact that the driver currently uses the same lookup table for both types of remote controls however, was perhaps not the best design choice. It really should be separated out, and merged with the regular ir-functions.c. I just never got around to it. I did not follow all the discussion, still I have a comment: I will soon work on a device where it is the driver who is doing the decoding of the IR-frames. It is (maybe, I'm still missing some pieces to be sure) possible to receive different protocols at the same time with this hardware. -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Mauro, On Sat, 5 Dec 2009, Mauro Carvalho Chehab wrote: Patrick Boettcher wrote: Hi Mauro, please pull from http://linuxtv.org/hg/~pb/v4l-dvb/ for the following changeset: DiB8090: Add the DiB0090 tuner driver and STK8096GP-board This is the adding support for the DiB809x-device you were asking 2 weeks ago. If possible, please include it into the patches which will go for 2.6.33 . This repo also includes the changesets which were in my previous pull request. Hi Patrick, In the last patch, checkpatch.pl returned: total: 134 errors, 220 warnings, 3291 lines checked Would it be possible to correct the CodingStyle errors on it? There are lots of comments that aren't following C99 specs. Also, some code is indented with 4 spaces, instead of tabs, making really hard to read the code, among several other codingstyle violations. I committed and pushed the patch from Olivier which fixes most of the Codingstyle violations (all of them except 80 char/line). I didn't see them in the first place, because it seems the 'make commit' does not use a built-in checkpatch.pl if it does not find one in /usr/src . This is a new (maybe buggy) behaviour. Still, if you take a look at dib0090.c you will find it odd. Why? Because as usual the DiBcom drivers are generated from internal source code by a script. This is done to keep in sync drivers in development and Linux easier. If someone has a problem with the dib-drivers he should contact DiBcom rather than trying to hack his solution (especially when it's about performance or other reception related problem) into the driver. I'm sorry that the drivers delivered like that are ugly from the artistic point-of-view, but that's the only way I have today to deliver drivers at all. Please pull now from http://linuxtv.org/hg/~pb/v4l-dvb/ best regards, -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New DibCom based ISDB-T device
Hi Marcelo, On Tue, 17 Nov 2009, Marcelo Blanes wrote: Dear Mauro and Patrick, This log may help you. It appears when I insert the usb tv stick tunner into one of my usb interfaces: [ 759.573180] usb 8-1: new high speed USB device using ehci_hcd and address 4 [ 759.714026] usb 8-1: configuration #1 chosen from 1 choice [ 759.717155] usb 8-1: New USB device found, idVendor=10b8, idProduct=1fa0 [ 759.717155] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 759.717155] usb 8-1: Product: STK8096GP [ 759.717155] usb 8-1: Manufacturer: DiBcom [ 759.717155] usb 8-1: SerialNumber: 1 Also a more detail information using lsusb -D Can you please test your device using the driver from here: http://linuxtv.org/hg/~pb/v4l-dvb/ ? thanks, -- Patrick http://www.kernellabs.com/
Re: New DibCom based ISDB-T device
On Monday 07 December 2009 21:25:25 Marcelo Blanes wrote: Hi Patrick, Ok I can test. Should I replace only the file dib8000.c or update the entire linuxtv project? Yes, please use the v4l-dvb repository from http://linuxtv.org/hg/~pb/v4l-dvb/ not only the dib8000.c PS: Please, don't chop off mailing lists when replying to a message received by one, You never know if someone else is following and this one may have the same questions as you. -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: High cpu load (dvb_usb_dib0700)
Hi, On Tue, 15 Dec 2009, Jan Korbel wrote: Hello. I have the same problem. Two tuners ASUS My Cinema U3000 Mini DVBT Tuner: Bus 005 Device 004: ID 0b05:171f ASUSTek Computer, Inc. Bus 005 Device 003: ID 0b05:171f ASUSTek Computer, Inc. Kernel 2.6.31 and 2.6.32 (debian packages), firmware dvb-usb-dib0700-1.20.fw. Intel Atom 330 (dualcore CPU). Have you tried to load dvb-usb with disable_rc_polling=1 ? It may or may not help. If it helps it will necessary to have a look at the ir-polling code to see whether there is some thing like 'scheduling'. regards, -- Patrick -- 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] dvb-apps ported for ISDB-T
Hi Mauro, On Fri, 25 Dec 2009, Mauro Carvalho Chehab wrote: Em 24-12-2009 00:17, Mauro Carvalho Chehab escreveu: I wrote several patches those days in order to allow dvb-apps to properly parse ISDB-T channel.conf. On ISDB-T, there are several new parameters, so the parsing is more complex than all the other currently supported video standards. I've added the changes at: http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/ I've merged there Patrick's dvb-apps-isdbt tree. While there, I fixed a few bugs I noticed on the parser and converted it to work with the DVB API v5 headers that are bundled together with dvb-apps. This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests. The ones there can now be removed. TODO: = The new ISDB-T parameters are parsed, but I haven't add yet a code to make them to be used; There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the segment parameters. Currently, the parser will fail if those parameters are found. gnutv is still reporting ISDB-T as DVB-T. I've just fixed the issues on the TODO list. The DVB v5 code is now working fine for ISDB-T. Pending stuff (patches are welcome): - Implement v5 calls for other video standards; - Remove the duplicated DVBv5 code on /util/scan/scan.c (the code for calling DVBv5 is now at /lib/libdvbapi/v5api.c); - Test/use the functions to retrieve values via DVBv5 API. The function is already there, but I haven't tested. With the DVBv5 API implementation, zap is now working properly with ISDB-T. gnutv also works (although some outputs - like decoder - may need some changes, in order to work with mpeg4/AAC video/audio codecs). Very good job! Have you had a look here on this one http://www.mail-archive.com/v...@linuxtv.org/msg11125.html ? I had this on my list because I wanted to spent some time on DVB-S2 myself and it seemed to be a good step to merge it (back) into dvb-apps. Though I haven't yet looked at it in detail. I will check your changes soon, but after the holidays. So, now you should have some quiet time for yourself! ;-) regards, -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Mauro, please pull from my repository for: [PATCH] Terratec Cinergy DT XS Diversity new USB ID (0ccd:0081) This patch can go to 2.6.29 - it is only a set of USB-IDs added. thanks, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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
Cross-posting linux-media, linux-dvb etc
Hi Mauro, Since the creation of linux-media@vger.kernel.org I'm seeing lots of cross-postings between linux-dvb, linux-media and video4linux. This is a little bit annoying if you are subscribed to all of those lists. Worse is, that some people only send requests to linux-media. Like that linux-dvb-only subscribers can't help... Why not closing linux-dvb (and video4linux) and transferring the currently subscribed users to linux-media automatically? regards, Patrick. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC - Flexcop Streaming watchdog (VDSB)
Hi lists,
For years there has been the Video Data Stream Borken-error with VDR and
Technisat cards: The error occured randomly and unfrequently. A
work-around for that problem was to restart VDR and let the driver reset
the pid-filtering and streaming interface.
In fact it turned out, that the problem is worse with setups not based on
VDR and the VDSB-error could be really easily reproduced (I'm not sure
if this applies to all generations on SkyStar2-card). I'm skipping the
description of the problem here...
Attached you'll find a patch which works around the hardware bug which is
causing VDSB-error without needing to reload the driver.
There a struct-work-watchdog looking at the number of irq-received while
having PIDs active in the PID-filter. If no IRQs are received, the
pid-filter-system is reset.
It seems to fix the problem and so far I've not seen any false positives
(like resetting the pid-filter even though streaming is working fine).
Before asking to pull the patch I'd like to discuss an issue: my
work-around is iterating over the pid-filter-list in the dvb_demux. I'm
doing this in the struct-work-callback. In dvb_demux.c I see that this
list is protected with a spinlock. When I now try to take the spinlock in
the work-function I'll get a nice message saying, that I cannot do take a
spinlock in a work-function.
What can I do? What is the proper way to protect access to this list? Is
it needed at all?
thanks for you input in advance,
Patrick.
--
Mail: patrick.boettc...@desy.de
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/diff -r 7981bdd4e25a linux/drivers/media/dvb/b2c2/flexcop-hw-filter.c
--- a/linux/drivers/media/dvb/b2c2/flexcop-hw-filter.c Mon Jan 12 00:18:04
2009 +
+++ b/linux/drivers/media/dvb/b2c2/flexcop-hw-filter.c Fri Jan 16 15:46:32
2009 +0100
@@ -179,7 +179,7 @@
/* if it was the first or last feed request change the stream-status */
if (fc-feedcount == onoff) {
- flexcop_rcv_data_ctrl(fc,onoff);
+ flexcop_rcv_data_ctrl(fc, onoff);
if (fc-stream_control) /* device specific stream control */
fc-stream_control(fc,onoff);
@@ -192,6 +192,7 @@
return 0;
}
+EXPORT_SYMBOL(flexcop_pid_feed_control);
void flexcop_hw_filter_init(struct flexcop_device *fc)
{
diff -r 7981bdd4e25a linux/drivers/media/dvb/b2c2/flexcop-pci.c
--- a/linux/drivers/media/dvb/b2c2/flexcop-pci.cMon Jan 12 00:18:04
2009 +
+++ b/linux/drivers/media/dvb/b2c2/flexcop-pci.cFri Jan 16 15:46:32
2009 +0100
@@ -13,9 +13,9 @@
module_param(enable_pid_filtering, int, 0444);
MODULE_PARM_DESC(enable_pid_filtering, enable hardware pid filtering:
supported values: 0 (fullts), 1);
-static int irq_chk_intv;
+static int irq_chk_intv = 100;
module_param(irq_chk_intv, int, 0644);
-MODULE_PARM_DESC(irq_chk_intv, set the interval for IRQ watchdog (currently
just debugging).);
+MODULE_PARM_DESC(irq_chk_intv, set the interval for IRQ streaming watchdog.);
#ifdef CONFIG_DVB_B2C2_FLEXCOP_DEBUG
#define dprintk(level,args...) \
@@ -34,7 +34,7 @@
static int debug;
module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug, set debug level (1=info,2=regs,4=TS,8=irqdma
(|-able)). DEBSTATUS);
+MODULE_PARM_DESC(debug, set debug level (1=info,2=regs,4=TS,8=irqdma,16=check
(|-able)). DEBSTATUS);
#define DRIVER_VERSION 0.1
#define DRIVER_NAME Technisat/B2C2 FlexCop II/IIb/III Digital TV PCI Driver
@@ -58,6 +58,8 @@
int active_dma1_addr; /* 0 = addr0 of dma1; 1 = addr1 of dma1 */
u32 last_dma1_cur_pos; /* position of the pointer last time the
timer/packet irq occured */
int count;
+ int count_prev;
+ int stream_problem;
spinlock_t irq_lock;
@@ -115,18 +117,47 @@
#endif
struct flexcop_device *fc = fc_pci-fc_dev;
- flexcop_ibi_value v = fc-read_ibi_reg(fc,sram_dest_reg_714);
+ if (fc-feedcount) {
+ flexcop_ibi_value v = fc-read_ibi_reg(fc,sram_dest_reg_714);
- flexcop_dump_reg(fc_pci-fc_dev,dma1_000,4);
+ // flexcop_dump_reg(fc_pci-fc_dev,dma1_000,4);
- if (v.sram_dest_reg_714.net_ovflow_error)
- deb_chk(sram net_ovflow_error\n);
- if (v.sram_dest_reg_714.media_ovflow_error)
- deb_chk(sram media_ovflow_error\n);
- if (v.sram_dest_reg_714.cai_ovflow_error)
- deb_chk(sram cai_ovflow_error\n);
- if (v.sram_dest_reg_714.cai_ovflow_error)
- deb_chk(sram cai_ovflow_error\n);
+#if 0
+ deb_chk(net_ovflow_error: %d, media_ovflow_error: %d,
cai_ovflow_error: %d, cao_ovflow_error: %d, sram_dma: %d, maximumfill: %d\n,
+ v.sram_dest_reg_714.net_ovflow_error,
+ v.sram_dest_reg_714.media_ovflow_error,
+ v.sram_dest_reg_714.cai_ovflow_error,
+
Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)
Hi Barry, Hi Walter, On Sat, 17 Jan 2009, BOUWSMA Barry wrote: For years there has been the Video Data Stream Borken-error with VDR and Technisat cards: The error occured randomly and unfrequently. A In fact it turned out, that the problem is worse with setups not based on VDR and the VDSB-error could be really easily reproduced (I'm not sure if this applies to all generations on SkyStar2-card). I'm Which generation of cards have this problem? I did not see any VDSB with my two Skystar 2.6D. Same here -- never experienced this ever in some four-ish years with one SkyStar2 of model long forgotten, with that card being the primary one used whenever possible... (in use typically several times per day, sometimes half a day uninterrupted, but on a production machine at 2.6.14-ish) Using VDR or a single application (like kaffeine), you most likely don't see the error anymore thanks to the work-around which is already in place. It is resetting the streaming interface at the end of a streaming-session, ie. when the pid-filter count is going from 1 to 0. This happens all the time with VDR (and similar) when it is retuning. Now when you launch an application which is just requesting a pid and another one which is tuning independently, you can fall easily in this problem. I have to say, that the user which showed me the problem was using the rev2.8 and due to the lack of time I couldn't check with other versions than this card yet. But I think those kind of problems also exist for older cards. Patrick. PS: how to reproduce: shell 1: $ tzap channel shell 2: $ dvbtraffic [lots of output that streaming is working] shell 1: $ C-c shell 1: $ tzap channel2_which is on a different frequency shell 2: no output of dvbtraffic any longer... (problem) -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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 - Flexcop Streaming watchdog (VDSB)
Hi Matthias, hi Andy, On Sun, 25 Jan 2009, Matthias Schwarzott wrote: What can I do? What is the proper way to protect access to this list? Is it needed at all? I thought this is a perfectly legetimate usage of spinlocks. What is the exact wording of the message. Is it a message of lockdep, or another kind of message? Does it get better using spin_lock_irqsave instead of spin_lock_irq ? I'll try yours suggestions this evening... along with dumping all error message if any. Thanks for taking the time. best regards Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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] Support faulty USB IDs on DIBUSB_MC
Hi,
sorry for not answering ealier, recently I became the master of
postponing things. :(
On Thu, 29 Jan 2009, Mauro Carvalho Chehab wrote:
+/* 14 */ { USB_DEVICE(USB_VID_CYPRESS,
USB_PID_ULTIMA_TVBOX_USB2_FX_COLD) },
+#endif
It doesn't sound a very good approach the need of recompiling the driver to
allow it to work with a broken card. The better would be to have some modprobe
option to force it to accept a certain USB ID as a valid ID for the card.
The most correct way would be to reprogram the eeprom, by simply writing
to 0xa0 (0x50 1) I2C address... There was a thread on the linux-dvb some
time ago.
The above is really ugly. IMO, we should replace this by
ARRAY_SIZE(dibusb_mc_properties.devices). Of course, for this to work,
num_device_descs should be bellow devices.
We could do that, still I'm not sure if ARRAY_SIZE will work in that
situation?! Are you
sure, Mauro?
Patrick.
--
Mail: patrick.boettc...@desy.de
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/
--
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] Support faulty USB IDs on DIBUSB_MC
On Thu, 29 Jan 2009, Mauro Carvalho Chehab wrote: We could do that, still I'm not sure if ARRAY_SIZE will work in that situation?! Are you sure, Mauro? Well, at least here, it is compiling fine. I can't really test it, since I don't have any dib0700 devices here. Hmm, your patch is shifting the counting problem to another place. Instead of counting manually the devices-array-elements, one now needs to count the number of device_properties ;) . With such a patch we would risk to break some device support and as I never saw a patch which broke the current num_device_descs-manual-count I don't see the need to change. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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] dib0700 buggy sfn workaround or equivalent
Hi, On Mon, 9 Feb 2009, Brett wrote: I have a dvb_usb_dib0700 (Nova 500 dual) card and it shows similar issues to the dvb_usb_dib3000mc card, ie: This card has an issue (which particularly manifests itself in Australia where a bandwidth of 7MHz is used) with jittery reception - artifacts and choppy sound throughout recordings despite having full signal strength. Australian users will typically see this behaviour on SBS and ABC channels It has nothing to with the channel bandwidth. In Australia, and maybe in other places too, the DVB-T radio-channels (not to mix up with a radio service) which are used in single-frequency-networks (SFNs) are transmitted buggy: different transmitters are not using the same tps-data (cellid IIRC). The dibcom-demods are using this information to improve the reception robustness. This leads to synchronization losses, when the SFN is not set up correctly... The fix for the dib3000mc is to enable the 'buggy sfn workaround' but there is no such option for the dib 0700 : The buggy sfn workaround workaround does dib7000p_write_word(state, 166, 0x4000); if it is active, or dib7000p_write_word(state, 166, 0x) if it inactive, in the dib3000mc driver. I presume this tweaks a bandwidth filter or something similar for the dib3000mc, is there such an equivalent feature for the dib0700 chipset ? Your report here is mixing up several things: dib3000mc and dib7000p have this work-around implemented. To activate it you need to load the dib3000p resp. the dib7000p-module with buggy_sfn_workaround=1. The dib0700-driver is only the USB driver here - nothing is missing there to avoid the SFN problem. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: DAB SFN (was: Re: [linux-dvb] dib0700 buggy sfn workaround or equivalent)
Hi Barry, On Tue, 10 Feb 2009, BOUWSMA Barry wrote: Is it in theory possible that this may be the source of some problems I experience receiving DAB radio, using a multi- element directional antenna, regardless of orientation, in a location with reception from at least two and possibly more than four senders within eyesight, or close to that? It's a completely different manufacturer (Siano) and the problem disappears when I simply use a short indoor whip antenna with adequate S/N ratio. I'm not sure how Siano's demodulator is working (not to say, I don't know it at all) for SFNs. Your scenario could also be explained with a too strong signal. When the ADC is saturated the reception is bad. Especially when not using in-can tuners (but silicon ones) you can face the issue easily. But your problem could also be explained by a 100 of different things I don't know. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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
PULL request
Hi Mauro, I pushed several changesets to my tree and would like to ask you to pull them. - [PATCH] Add support for Winfast Dongle Hybrid - [PATCH] Emtec S810 (1164:2edc) support - [PATCH] Add Elgato EyeTV Diversity to dibcom driver - Wipe out an obsolete documentation about Flexcop refactoring - documentation fix for /Documentation/dvb/technisat.txt The most important one is - [PATCH] software IRQ watchdog for Flexcop B2C2 DVB PCI cards which fixes a problem with the recently added 2.8 revsion of the Technisat SkyStar2. If possible we should get that into 2.6.29 in order to have a proper support for this card. thanks, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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
PULL request (once more)
Hi Mauro, can you please pull this very important bugfix patch from my repository (http://linuxtv.org/hg/~pb/v4l-dvb/) . - [PATCH] software IRQ watchdog for Flexcop B2C2 DVB PCI cards This one is high-priority and has to go to 2.6.29 for its release. In the meantime I rebuilt and cleaned up my repository so that only this patch is new. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: Support for SkyStar USB 2 ?
Hi Ronny, On Tue, 3 Mar 2009, ronny.ban...@nexgo.de wrote: the current flexcop-usb driver supports only USB 1.1 devices. Is there any plan to support USB 2.0 devices ? The device id is 13d0:2282. For testing I have simply changed the flexcop_usb_table structur to this ids. But of course is does not work. The hardware components are the same of the SkyStar2 PCI (CX24113 tuner...). Are you sure about that? Can you please send hires-pictures of the innards of the USB box? Patrick. -- 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] ERROR: Module dvb_usb_aaa_dvbusb_demo is in use
Hi,
On Thu, 5 Mar 2009, wdy9927 wrote:
I had make install a module for a dvb usb box which writen by my self. But this
one didn't have real frontend ops and tuner ops.These functions did
nothing but return 0.
Like this
static int demo_fe_init(struct dvb_frontend *fe)
{
return 0;
}
After the usb box removed from linux, the DVB system called demo_fe_release and
demo_tu_release, sofar that seems very good? But, I can't rmmod this
module normally. It showed ERROR: Module dvb_usb_dvbusb_demo is in use.This error
is diffrent with ERROR: Module dvb_usb is in use by
dvb_usb_dvbusb_demo
How can i rmmod this module with out reboot Linux.
This is a known problem with every dvb-device-driver (especially the ones
using dvb-usb) which are implementing the frontend-part not as an
independent kernel module. When the frontend-driver is released the
dvb-core is doing something like use-count-decrement on the module. As the
use-count was never incremented (dvb_attach cannot be used on function
which are not exported with EXPORT_SYMBOL) the count is now -1, which is
same as 0x.
rmmod is refusing to unload a module which has a use_count != 0. This is
the problem you're facing.
You could still try to use rmmod -f to force to unload. Or you make your
frontend-driver a seperate kernel module.
Patrick.
Re: Technisat Skystar 2 on Suse Linux 11.1, kernel 2.6.27.19-3.2-default
Hi Elmar, On Sat, 7 Mar 2009, Elmar Stellnberger wrote: dvbscan -adapter 0 -frontend 0 -demux 0 /usr/share/dvb/dvb-s/Astra-19.2E Failed to set frontend I have the same problem with that scan, please use the older one called scan. Are you running the szap below as root, but kaffeine as a normal user ? If so, make sure that you are in the group video. downloading channel.conf from Astra1 has not brought me force. szap 3sat reading channels from file '/home/elm/.szap/channels.conf' zapping to 20 '3sat': sat 0, frequency = 11954 MHz V, symbolrate 2750, vpid = 0x00d2, apid = 0x00dc sid = 0x using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 00 | signal | snr 6b2b | ber | unc fffe | status 00 | signal | snr 7f02 | ber 7e00 | unc fffe | status 01 | signal aa7e | snr 3d47 | ber ffe8 | unc fffe | status 00 | signal | snr 7fc5 | ber fff0 | unc fffe | status 00 | signal | snr 2232 | ber 6ef0 | unc fffe | status 00 | signal | snr 1fdd | ber 0058 | unc fffe | status 00 | signal | snr 19b3 | ber | unc fffe | status 02 | signal | snr 192f | ber | unc fffe | status 00 | signal 0035 | snr 8469 | ber | unc fffe | This is the first proof that your device is present and the driver is correctly loaded. Please check the output of the dmesg-program to check for lines starting with b2c2-flexcop. what should that output mean? it means, it can't synchronize the channel on that frequency. This can have a whole bunch of explaination - not necessarily only the driver. why does szap not terminate? It stays in the monitoring loop. Normal. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] siano: add high level SDIO interface driver for SMS based cards
Hi Mauro, (sorry for hijacking) (since when do we like top-posts ? ;) ) On Sat, 14 Mar 2009, Mauro Carvalho Chehab wrote: Hi Uri, The patch looks sane, but I'd like to have a better picture of the Siano device, to better understand this interface. The basic question is: why do we need an SDIO interface for a DVB device? For what reason this interface is needed? The answer is relatively easy: Some hosts only have a SDIO interface, so no USB, no PCI, no I2C, no MPEG2-streaming interface. So, the device has to provide a SDIO interface in order to read and write register and to make DMAs to get the data to the host. Think of your cell-phone, or your PDA. There are some/a lot of vendors who use Linux in their commercial mobile-TV product and there are some component-makers like Siano, who are supporting those vendors through GPL drivers. regards, Patrick. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] siano: add high level SDIO interface driver for SMS based cards
On Sat, 14 Mar 2009, Mauro Carvalho Chehab wrote: The answer is relatively easy: Some hosts only have a SDIO interface, so no USB, no PCI, no I2C, no MPEG2-streaming interface. So, the device has to provide a SDIO interface in order to read and write register and to make DMAs to get the data to the host. Think of your cell-phone, or your PDA. Ok, so, if I understand well, the SDIO interface will be used just like we currently use the I2C or USB bus, right? So, we should create some glue between DVB and SDIO bus just like we have with PCI, USB, I2C, etc. Ideally something like (using the design we currently have with dvb-usb): [...] Actually, when I created dvb-usb with the help of a lot of contributors, it served the purpose (and still serves) that there is a lot of different USB-based DVB devices which are delivering data. Bascially every DVB-USB-box/card-vendor is using a generic or specific USB-device-controller which implements some kind of high-level interface to do e.g. I2C and streaming. Those implementations, the USB protocol and its Linux-HAL requires some overhead to implement a driver. It was useful to create some common module and interface. With SDIO I can't really see the same right now. First of all, SDIO should be much simpler as USB from the HAL point of view. Correct me if I'm wrong, but the SDIO-host controller should give simple DMA access to the device?. Another thing for me is, there isn't many SDIO DVB devices out there right now, where Linux support is required (the latter is a pity ;) ). Also, the major part of supported DVB devices in Linux is PC-based and for PC (as of today) there is PCI(e) and USB working quite well, no one needs a SDIO device. Having an SDIO device filling in to the DVB-API is rather straight forward, which makes me think that right now there is no need for a dvb-sdio.ko . Patrick. PS: please check the date of this email, when reading it in an archive in 2 years ;) -- 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 RFCv2] add DTMB support for DVB API
On Saturday 14 January 2012 16:31:16 Antti Palosaari wrote:
Version 2. I have made some changes from feedback got and
what I myself found better. I will add documentation later
after API issues are resolved.
Thanks to Andreas, Patrick and Mauro.
Cc: Patrick Boettcher pboettc...@kernellabs.com
Cc: Andreas Oberritter o...@linuxtv.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 14 +++---
drivers/media/dvb/dvb-core/dvb_frontend.h |2 ++
drivers/media/dvb/frontends/atbm8830.c|2 +-
drivers/media/dvb/frontends/lgs8gl5.c |2 +-
drivers/media/dvb/frontends/lgs8gxx.c |2 +-
include/linux/dvb/frontend.h | 22
+++--- include/linux/dvb/version.h |
2 +-
7 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index b15db4f..abdc203 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -177,7 +177,7 @@ static enum dvbv3_emulation_type dvbv3_type(u32
delivery_system)
case SYS_DVBT:
case SYS_DVBT2:
case SYS_ISDBT:
- case SYS_DMBTH:
+ case SYS_DTMB:
return DVBV3_OFDM;
case SYS_ATSC:
case SYS_DVBC_ANNEX_B:
@@ -989,6 +989,7 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND
+ 1] = {
_DTV_CMD(DTV_CODE_RATE_LP, 1, 0),
_DTV_CMD(DTV_GUARD_INTERVAL, 1, 0),
_DTV_CMD(DTV_TRANSMISSION_MODE, 1, 0),
+ _DTV_CMD(DTV_INTERLEAVING, 1, 0),
_DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 1, 0),
_DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 1, 0),
@@ -1039,6 +1040,7 @@ static struct dtv_cmds_h
dtv_cmds[DTV_MAX_COMMAND + 1] = {
_DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
_DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
_DTV_CMD(DTV_HIERARCHY, 0, 0),
+ _DTV_CMD(DTV_INTERLEAVING, 0, 0),
_DTV_CMD(DTV_ENUM_DELSYS, 0, 0),
};
@@ -1316,6 +1318,9 @@ static int dtv_property_process_get(struct
dvb_frontend *fe,
case DTV_HIERARCHY:
tvp-u.data = c-hierarchy;
break;
+ case DTV_INTERLEAVING:
+ tvp-u.data = c-interleaving;
+ break;
/* ISDB-T Support here */
case DTV_ISDBT_PARTIAL_RECEPTION:
@@ -1503,7 +1508,7 @@ static int set_delivery_system(struct
dvb_frontend *fe, u32 desired_system)
* The DVBv3 or DVBv5 call is requesting a different system. So,
* emulation is needed.
*
- * Emulate newer delivery systems like ISDBT, DVBT and DMBTH
+ * Emulate newer delivery systems like ISDBT, DVBT and DTMB
* for older DVBv5 applications. The emulation will try to use
* the auto mode for most things, and will assume that the desired
* delivery system is the last one at the ops.delsys[] array
@@ -1625,6 +1630,9 @@ static int dtv_property_process_set(struct
dvb_frontend *fe,
case DTV_HIERARCHY:
c-hierarchy = tvp-u.data;
break;
+ case DTV_INTERLEAVING:
+ c-interleaving = tvp-u.data;
+ break;
/* ISDB-T Support here */
case DTV_ISDBT_PARTIAL_RECEPTION:
@@ -1896,7 +1904,7 @@ static int dtv_set_frontend(struct dvb_frontend
*fe) case SYS_DVBT:
case SYS_DVBT2:
case SYS_ISDBT:
- case SYS_DMBTH:
+ case SYS_DTMB:
fepriv-min_delay = HZ / 20;
fepriv-step_size = fe-ops.info.frequency_stepsize * 2;
fepriv-max_drift = (fe-ops.info.frequency_stepsize *
2) +
1;
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index d63a821..fb2d57c 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -353,6 +353,8 @@ struct dtv_frontend_properties {
fe_delivery_system_tdelivery_system;
+ fe_interleaving_t interleaving;
+
/* ISDB-T specifics */
u8 isdbt_partial_reception;
u8 isdbt_sb_mode;
diff --git a/drivers/media/dvb/frontends/atbm8830.c
b/drivers/media/dvb/frontends/atbm8830.c
index a2261ea..4e11dc4 100644
--- a/drivers/media/dvb/frontends/atbm8830.c
+++ b/drivers/media/dvb/frontends/atbm8830.c
@@ -428,7 +428,7 @@ static int atbm8830_i2c_gate_ctrl(struct
dvb_frontend *fe, int enable)
}
static struct dvb_frontend_ops atbm8830_ops = {
- .delsys = { SYS_DMBTH },
+ .delsys = { SYS_DTMB },
.info = {
.name = AltoBeam ATBM8830/8831 DMB-TH,
.frequency_min = 47400,
diff --git a/drivers/media/dvb/frontends/lgs8gl5.c
b/drivers/media/dvb/frontends/lgs8gl5.c
index 2cec804..416cce3 100644
--- a/drivers/media/dvb/frontends/lgs8gl5
Re: V4L/DVB (12892): DVB-API: add support for ISDB-T and ISDB-Tsb (version 5.1)
On Friday 13 January 2012 13:37:57 Dan Carpenter wrote: Hello Patrick Boettcher, I know this patch is really old but I was hoping you still might be able to take a look at it. The patch b6e760f30975: V4L/DVB (12892): DVB-API: add support for ISDB-T and ISDB-Tsb (version 5.1) from Aug 3, 2009, leads to the following warning: drivers/media/dvb/dvb-core/dvb_frontend.c:993:9: warning: Initializer entry defined twice drivers/media/dvb/dvb-core/dvb_frontend.c:1012:9: also defined here How does this thing has lived such a long time without being noticed by anyone? Very strange. Of course this is wrong and it should be fixed by removing the second section. IOW, we should keep the section with the 1s. drivers/media/dvb/dvb-core/dvb_frontend.c + _DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 1, 0), + _DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 1, 0), + _DTV_CMD(DTV_ISDBT_SB_SUBCHANNEL_ID, 1, 0), + _DTV_CMD(DTV_ISDBT_SB_SEGMENT_IDX, 1, 0), + _DTV_CMD(DTV_ISDBT_SB_SEGMENT_COUNT, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERA_FEC, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERA_MODULATION, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERA_SEGMENT_COUNT, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERA_TIME_INTERLEAVING, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERB_FEC, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERB_MODULATION, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERB_SEGMENT_COUNT, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERB_TIME_INTERLEAVING, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERC_FEC, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERC_MODULATION, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 1, 0), I prepared a patch for this in my repo. I will send a pull-request right away. Thanks for pointing this out. regards, -- Patrick. -- 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
PULL request: remove superfluous DTV_CMDs
Hi Mauro I fixed a warning caused by a commit made a long time ago in dvb_frontend.c . Thanks to Dan Carpenter for pointing this one out. - The following changes since commit 1e73fa5d56333230854ae9460579eb2fcee8af02: Mauro Carvalho Chehab (1): [media] stb6100: Properly retrieve symbol rate are available in the git repository at: http://linuxtv.org/git/pb/media_tree.git staging/for_v3.3 Patrick Boettcher (1): [media] DVB-CORE: remove superfluous DTV_CMDs drivers/media/dvb/dvb-core/dvb_frontend.c | 19 --- 1 files changed, 0 insertions(+), 19 deletions(-) best regards, -- Patrick Boettcher Kernel Labs Inc. http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] DVB: dib0700, move Nova-TD Stick to a separate set
H Jiri, On Tuesday 10 January 2012 18:11:22 Jiri Slaby wrote: To properly support the three LEDs which are on the stick, we need a special handling in the -frontend_attach function. Thus let's have a separate -frontend_attach instead of ifs in the common one. The hadnling itself will be added in further patches. Signed-off-by: Jiri Slaby jsl...@suse.cz --- [..] Thanks. I reviewed and added those commits to my tree (apparently Mike did the same and asked Mauro to pull as well). We will see how it turns out. :) best regards, -- Patrick Boettcher Kernel Labs Inc. http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l-utils migrated to autotools
On Wednesday 18 January 2012 13:31:01 Rémi Denis-Courmont wrote: On Wed, 18 Jan 2012 10:19:24 -0200, Mauro Carvalho Chehab mche...@redhat.com wrote: Not sure if it is possible, but it would be great if the build output would be less verbose. libtool adds a lot of additional (generally useless) messages, with makes harder to see the compilation warnings in the middle of all those garbage. These days, automake has a silent mode that looks much like a kernel compilation. I missed the first message of this thread, that's why I hijacked it here and it is short: I love cmake and can't understand why people are not preferring it over autotools for user-space applications and conditional+configurable builds. I hope my mail is not too off-topic. regards, -- Patrick Boettcher Kernel Labs Inc. http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] dib8000: return an error if the TMCC is not locked
On Tuesday 17 January 2012 19:45:28 you wrote: On ISDB-T, a few carriers are reserved for TMCC decoding (1 to 20 carriers, depending on the mode). Those carriers use the DBPSK modulation, and contain the information about each of the three layers of carriers (modulation, partial reception, inner code, interleaving, and number of segments). If the TMCC carrier was not locked and decoded, no information would be provided by get_frontend(). So, instead of returning false values, return -EAGAIN. Another alternative for this patch would be to add a flag to fe_status (FE_HAS_GET_FRONTEND?), to indicate that the ISDB-T TMCC carriers (and DVB-T TPS?), required for get_frontend to work, are locked. Comments? I think it changes the behaviour of get_frontend too much and in fact transmission parameter signaling (TPS for DVB-T, TMCC for ISDB-T) locks are already or should be if not integrated to the status locks. Also those parameters can change over time and signal a reconfiguration of the transmission. So, for me I would vote against this kind of implementation in favor a better one. Unfortunately I don't have a much better idea at hand right now. -- Patrick Boettcher Kernel Labs Inc. http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] dib8000: return an error if the TMCC is not locked
On Wednesday 18 January 2012 14:40:09 Mauro Carvalho Chehab wrote:
Em 18-01-2012 10:49, Patrick Boettcher escreveu:
On Tuesday 17 January 2012 19:45:28 you wrote:
On ISDB-T, a few carriers are reserved for TMCC decoding
(1 to 20 carriers, depending on the mode). Those carriers
use the DBPSK modulation, and contain the information about
each of the three layers of carriers (modulation, partial
reception, inner code, interleaving, and number of segments).
If the TMCC carrier was not locked and decoded, no information
would be provided by get_frontend(). So, instead of returning
false values, return -EAGAIN.
Another alternative for this patch would be to add a flag to
fe_status (FE_HAS_GET_FRONTEND?), to indicate that the ISDB-T
TMCC carriers (and DVB-T TPS?), required for get_frontend
to work, are locked.
Comments?
I think it changes the behaviour of get_frontend too much and in
fact transmission parameter signaling (TPS for DVB-T, TMCC for
ISDB-T) locks are already or should be if not integrated to the
status locks.
Also those parameters can change over time and signal a
reconfiguration of the transmission.
So, for me I would vote against this kind of implementation in
favor a better one. Unfortunately I don't have a much better idea
at hand right now.
The current status are:
typedef enum fe_status {
FE_HAS_SIGNAL = 0x01, /* found something above the noise
level */ FE_HAS_CARRIER = 0x02, /* found a DVB signal */
FE_HAS_VITERBI = 0x04, /* FEC is stable */
FE_HAS_SYNC = 0x08, /* found sync bytes */
FE_HAS_LOCK = 0x10, /* everything's working... */
FE_TIMEDOUT = 0x20, /* no lock within the last ~2
seconds */ FE_REINIT = 0x40/* frontend was reinitialized, */ }
fe_status_t;/* application is recommended to
reset */
There are a few options that can be done:
1) only rise FE_HAS_LOCK if TPS/TMCC demod were locked. The
description for FE_HAS_LOCK (everything's working) seems to
indicate that TMCC lock/TPS lock is also part of everything.
HAS_LOCK includes TPS-lock, right. But TPS-lock can raise much before
HAS_LOCK and at worse signal conditions. In DVB-T and ISDB-T we can have
the parameters at -1 dB SNR (or below) whereas data reception at least
needs ~3 dB ( QPSK 1/2 in DVB-T) and much more for the modulations
used currently on earth.
2) create a new status for it.
Maybe that's the way to go then. FE_HAS_PARAMETERS.
With regards to dvb-core get_frontend() call, it only makes sense if
the TPS/TMCC is locked. So, I think that such call needs to be
limited to happen only when the lock were archived, like the
enclosed patch.
OK.
--
Patrick Boettcher
Kernel Labs Inc.
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [media] dvb_frontend: Require FE_HAS_PARAMETERS for get_frontend()
Hi Mauro, On Wednesday 18 January 2012 18:51:25 Mauro Carvalho Chehab wrote: Calling get_frontend() before having either the frontend locked or the network signaling carriers locked won't work. So, block it at the DVB core. I like the idea and also the implementation. But before merging this needs more comments from other on the list. Even though it does not break anything for any current frontend-driver it is important to have a wider base agreeing on that. Especially from some other frontend-driver-writers. For example I could imagine that a frontend HAS_LOCK, but is still not able to report the parameters (USB-firmware-based frontends might be poorly implemented). And so on... regards, -- Patrick Boettcher Kernel Labs Inc. http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SDR FM demodulation
On Thursday 09 February 2012 16:01:12 Antti Palosaari wrote: I have taken radio sniffs from FM capable Realtek DVB-T device. Looks like demodulator ADC samples IF frequency and pass all the sampled data to the application. Application is then responsible for decoding that. Device supports DVB-T, FM and DAB. I can guess both FM and DAB are demodulated by software. Here is 17 second, 83 MB, FM radio sniff: http://palosaari.fi/linux/v4l-dvb/rtl2832u_fm/ Decode it and listen some Finnish speak ;) Could someone help to decode it? I tried GNU Radio, but I failed likely because I didn't have enough knowledge... GNU Radio and Octave or Matlab are way to go. For someone to decode it, you would need to give more information about the format of the stream. Like the sampling frequency, the sample-format and then the IF-frequency. I never did something like myself, but from what I saw in gnuradio there should be everything to make a FM-demod based on the data. regards, -- Patrick Boettcher Kernel Labs Inc. http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: update to file fr-Paris for DVB-T
Hi Eric, On Tuesday 27 March 2012 19:19:41 EricJCh.Aubert wrote: Hello, I have updated the file fr-Paris with the frequencies valid from march 8th 2011 source http://www.tvnt.net/forum/tous-au-numerique-ile-de-france-le-8- mars-2011-mise-a-jour-le-26-02-2011-t24658.html file fr-Paris joined Are you sure that the frequency you give for R8 is 700MHz? 700 MHz is not a fitting into the 8MHz structured sprectrum. To make it fix it should be either 698 or 706. best regards, -- Patrick Boettcher Kernel Labs Inc. http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Module dvb-usb
Hi Matias, On Friday 30 March 2012 09:42:14 Matias Aguirre wrote: My name is Matias and im a programmer. I need to ask some things to you about the creation of new modules into the kernel for TV adapters. I have a new TV adapter with the chipset DM1305. I have the firmware of this chipset.. can i start with that or i need more info? First of all you should ask on the linux-media mailing list whether there is already someone working on a driver for this device. (CC'd) If not having the firmware-binary is not enough, you also need to know how to communicate with it and what kind of messages have to be sent to the firmware to make it do something. If you do not have any documentation about it (and you cannot get hold of it from the vendor), you need to reverse-engineer the communication. This is where the vp7045-example comes into the game: the vp7045 has a relatively simple firmware interface which can help you to quickly make a driver for you device. But, there is two different dvb usb device types: 1) the USB-firmware contains the demod/tuner-drivers and the firmware interface is high-level. (this is the case for the vp7045) or 2) the USB-firmware only implements a bridge for I2C/SPI or other control protocols and the demod/tuner-drivers have to be handled from the host. If your device is of the 2nd kind you should rather look at cxusb.c . HTH -- Patrick Kernel Labs Inc. http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 3.10] DiBxxxx: fixes and improvements
Hi Mauro, These patches contains some fixes and changes for the DiBcom demods and SIPs. Please merge for 3.10 if possible. The following changes since commit 60d509fa6a9c4653a86ad830e4c4b30360b23f0e: Linux 3.9-rc8 (2013-04-21 14:38:45 -0700) are available in the git repository at: git://git.linuxtv.org/pb/media_tree.git/ master for you to fetch changes up to 7e39d1958b186e5af259b9fde1a006853b4663ab: [media] dib8000: do not freeze AGCs by default (2013-04-22 10:06:48 +0200) Olivier Grenie (6): [media] dib8000: enhancement [media] dib7000p: enhancement [media] dib0090: enhancement [media] dib8096: enhancement [media] dib7090p: remove the support for the dib7090E [media] dib7090p: improve the support of the dib7090 and dib7790 Patrick Boettcher (1): [media] dib8000: do not freeze AGCs by default drivers/media/dvb-core/dvb-usb-ids.h |3 +- drivers/media/dvb-frontends/dib0090.c| 438 ++--- drivers/media/dvb-frontends/dib7000p.c | 17 +- drivers/media/dvb-frontends/dib7000p.h |7 + drivers/media/dvb-frontends/dib8000.c| 2239 +- drivers/media/dvb-frontends/dib8000.h|6 +- drivers/media/dvb-frontends/dibx000_common.h |3 +- drivers/media/usb/dvb-usb/dib0700_devices.c | 465 +++-- 8 files changed, 1780 insertions(+), 1398 deletions(-) regards, -- Patrick -- 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: Diversity support?
On Tuesday 04 June 2013 13:17:49 Antti Palosaari wrote: On 06/04/2013 10:29 AM, Luca Olivetti wrote: Al 04/06/13 01:17, En/na Antti Palosaari ha escrit: I'm not easily discouraged :-) so here's the question again: is there some dvb-t usb stick (possibly available on the EU market) with diversity support under Linux? I have feeling AF9035/IT9135 dual devices could do that. Looking at the wiki, most devices based on those demodulators are either unsupported or have a dual tuner but not diversity. Because diversity is not interesting feature at all in normal use case. Whole DVB-T standard fits poorly for mobile usage and you cannot make situation that much better using diversity. Well, I have to disagree on this statement. Diversity does not do a lot in fixed reception. That's right, but depending on the TV-standard the diversity gain in mobile reception can be enormous. Several field trials we did in the past years have shown that large parts of the trial route which have not worked at at all in single receiver work like a charm in diversity. Maybe the route-selection in this cases was biased to show off the performance of diversity ... well, it worked - diversity showed off. best regards, -- Patrick -- 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: Diversity support?
On Monday 03 June 2013 17:14:18 Luca Olivetti wrote: So, what's the real status of diversity support? Nobody knows? I'm not easily discouraged :-) so here's the question again: is there some dvb-t usb stick (possibly available on the EU market) with diversity support under Linux? There is some diversity support hidden in the dib8000-driver and in some board-drivers which use it. Basically it creates several instances of the dib8000-driver (one for each demod) but it exposes only one dvb-frontend to userspace via the API. When the user is tuning the frontend he is, in fact, tuning all of them in diversity. IMO, the question which needs to be discussed is for diversity-support is an how to change the API-question and how does userspace can control it? In my experience with multi-frontend-hardware, which can do diversity or dual/triple-reception or both at the same time, is that the question is the routing and the grouping of frontend and assigning them to their sinks (stream-interfaces). Right now DVB-API can expose several frontends and dvrs and demuxes for one device, but there is no way to userspace telling the hardware to combine frontend0 and frontend1 to do diversity. When looking at diversity/multi-frontend problems, IMHO, we should not limit ourselves to USB-devices. The real usage of those MFE-devices is in an embedded hardware (STB in a car or at home). -- Patrick -- 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 enhancements - comments please?
On Friday 29 June 2012 13:24:52 Patrick Boettcher wrote: That said, IMO, the rtl-sdr driver should sit on the DVB-API. Maybe V4L2 *argl* I wanted to say, ... should _not_ sit on the DVB-API... -- Patrick. Kernel Labs Inc. http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] dvb-demux: add functionality to send raw payload to the dvr device
Hi Mike, On Tuesday 01 May 2012 06:12:22 Michael Krufky wrote: From: Michael Krufky mkru...@kernellabs.com If your driver needs to deliver the raw payload to userspace without passing through the kernel demux, use function: dvb_dmx_swfilter_raw I like this one very much. I had a background task sleeping in my head which was how to add non-Transport-Stream standards to Linux-dvb. This one I can now cancel, thanks to this change. We now can add CMMB-support and DAB to linux-dvb (after more discussions on the API of course). Do you have user-space-tool ready which uses the new RAW-payload mechanism? Something which can be used as an example. Thanks for this development. -- Patrick Kernel Labs Inc. http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB USB issues we has currently
On Thursday 03 May 2012 16:20:23 Antti Palosaari wrote: Hello, Here we are, that's the first part I am going to fix as a GSoC project. Work is planned to start after two weeks but better to discuss beforehand. And wish-list is now open! I see two big DVB USB issues including multiple small issues; 1) Current static structure is too limited as devices are more dynamics nowadays. Driver should be able to probe/read from eeprom device configuration. Fixing all of those means rather much work - I think new version of DVB USB is needed. I'm looking forward to see RFCs about proposals for additions to dvb- usb's structure. Especially the ugly device-usb-id-referencing. What do you mean by new version? 2) Suspend/resume is not supported and crashes Kernel. I have no idea what is wrong here and what is needed. But as it has been long term known problem I suspect it is not trivial. Are you sure that suspend/resume-crashes are related to dvb-usb? Maybe the refactoring of some buffer-handling should be considered. Also adding support for hybrid (analog+dvb-devices) is missing. Mike Krufky did some work somewhere which looked promising but was never merged. best regards, -- Patrick. -- 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 Explained..
Hi Richard, I can maybe answer some of your questions with semi-complete answers in the hope it helps you further. On Saturday 17 November 2012 13:35:18 Richard wrote: struct dvb_demux : This has a start_feed and a stop feed. What feed is this? ... the RAW 188 byte packets from the device perhaps? start/stop_feed are callbacks in the dvb_demux-device (which is represented with dvb/adapterX/demuxX by your driver) which have to be filled in by the driver which implements and controls the HW-demux. E.g: (from dmxdev.c) when a user is issuing the DMX_ADD_PID ioctl (which marks the request of a certain PID from the TS currently received) the start_feed-callback is called. It tells the driver that the TS-packets identified with PID are expected via e.g. the dvrX device. So the driver has to instruct its internal demux to have them pass the filter. What is the main purpose of this structure? struct dmx_demux : This structure holds the frontend device struct and contains the .fops for read/write. Is this the main interface when using the /dev/dvb/adapterX/demux ? /dvr? I'm not sure to get what you want to know here. adapter = dvb_register_adapter() : Register a new DVB device adapter (called once) dvb_dmx_init(dvbdemux); // Called once per Demux chain? dvb_dmxdev_init(); // Called once per demux chain ? same as above --- The hardware I am using has 6 TS data inputs, 4 tuners (linked to TS inputs) and hardware PID filters and I am trying to establish the relationship of dmx and dmxdev. Before understanding the relationship you need to know where, in the end, you want your TS-packets. In user-space? Sent to a hardware-decoder? Somewhere else? All of that? HTH a litte bit, -- Patrick -- 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
