[linux-dvb] [RFC] Change dvb-pll handling of IF frequency
The basic frequency calculation done in dvb-pll is to take the desired frequency, add the IF frequency, and then divide by the reference frequency. When dvb-pll does the division, it just rounds the result down. It would make more sense to round to the nearest integer, which is done by adding 1/2 the divisor (the reference frequency) before dividing. Some PLL definitions already do this, by adding one half the reference frequency to the IF frequency. The effect is the same, except one looking at the code doesn't know if they are seeing the IF frequency, or the IF frequency plus 1/2 the reference frequency. Of course some PLL defintions do it one way and some do it the other and there is no record of which is which. I think it makes a lot more sense put just the IF frequency in the PLL definition, and take care of rounding properly in the dvb-pll code. So I have attached a patch which does this. In order to do this, I had to guess which PLLs had stepsize/2 added to the offset and which didn't. The second patch moves the IF frequency out of the per-band data. There is no reason for the IF to change from one band to another, and in all of the PLLs defined the IF is constant across bands. As far as which PLLs had offsets with stepsize/2 added and which didn't, I've made a list of all the IF frequencies defined in dvb-pll: dvb_pll_thomson_dtt7610 44 dvb_pll_microtune_4042 44 dvb_pll_thomson_dtt761x 44 dvb_pll_lg_tdvs_h06xf 44 dvb_pll_tdhu2 44 dvb_pll_tuv1236d44 dvb_pll_samsung_tbmv44 dvb_pll_tua6010xs 36 1/8 dvb_pll_thomson_dtt7579 36 1/6 dvb_pll_tded4 36 1/6 dvb_pll_tua6034 36 1/6 dvb_pll_unknown_1 36 1/6 dvb_pll_thomson_dtt759x 36 1/6 dvb_pll_lg_z201 36 1/6 dvb_pll_philips_td1316 36 1/6 (rounded to nearest kHz) dvb_pll_tda665x 36 1/6 (rounded to nearest kHz) + step/2 dvb_pll_fmd1216me 36 1/8 (rounded to two decimals) + step/2 dvb_pll_thomson_fe6600 36 1/8 (rounded to two decimals) + step/2 dvb_pll_env57h1xd5 36 1/8 + step dvb_pll_philips_sd1878_tda8261 499 Anyway, from this list I think it's clear that the PLLs with a pre-adjusted offset are dvb_pll_tda665x, dvb_pll_fmd1216me, dvb_pll_thomson_fe6600, and dvb_pll_env57h1xd5. dvb_pll_philips_sd1878_tda8261 is an odd one, as it's the only satellite PLL with zero-IF output in the list. It uses an offset of 499 with a stepsize of 500 kHz so that it rounds _up_. I've left this PLL rounding up, assuming there is a reason it was this way. Also, dvb_pll_env57h1xd5 is not 36 1/8 + step/2, but 36 1/8 + step. I think this is a bug. If you go back to patch 1740 which created the dvb-pll definition, you'll see it was taken from the dibusb driver. The original code for this pll was: u32 freq_khz = fep-frequency / 1000; u32 tfreq = ((freq_khz + 36125)*6 + 500) / 1000; If you multiple that out and reduce it, you get: tfreq = (fep-frequency + 36125000 + 17/2) / 17; But the dvb-pll definition is using 36125000 + 17.# Added/removed/changed files: # linux/drivers/media/dvb/frontends/dvb-pll.c | 148 ++-- # 1 files changed, 75 insertions(+), 73 deletions(-) # # For better log display, please keep a blank line after subject, after from, # and before signed-off-by. # First line should be the subject, without Subject: # dvb-pll: Adjust rounding to be consistent # Now, patch author (just the main one), on a From: field # Please change below if the committer is not the patch author. # From: Trent Piepho [EMAIL PROTECTED] # Then a detailed description: Some PLLs had one half the step size added to the offset, so that the divisor would be rounded to the nearest integer. Some didn't and so would always be rounded down. This makes dvb-pll round to the nearest when calculating the divisor, without the offset needing to be fudged. PLLs that had a fudged offset have the offset changed to be just the IF frequency. The satellite PLL dvb_pll_philips_sd1878_tda8261 was rounding up for some reason, and I've kept it that way. In addition, frequencies that were rounded to the nearest kHz are extended to full Hz resolution. One sixth MHz step sizes that were listed as 166,666 Hz are changed to 166,667 Hz, which is slightly closer. PLLs that were already rounding: dvb_pll_tda665x, offset was 36 1/6 (to nearest kHz) + step/2 dvb_pll_fmd1216me, offset was 36 1/8 (to two digits) + step/2 dvb_pll_thomson_fe6600, offset was 36 1/8 (to two digits) + step/2 dvb_pll_env57h1xd5, offset was 36 1/8 + step Note that the last PLL, dvb_pll_env57h1xd5, appears to have had a bug in the offset. Rather than adding stepsize/2, it was adding a full stepsize. The PLL definition originally came from the dibusb driver, which used 36 1/8 + step/2. The change to 36 1/8 + step was probably a mistake
Re: [linux-dvb] DVB-s signal strength control
Sorry for that, I know that I can do it with splitters, but I would prefer some device which can control gain or knocking down of a signal strength. I need this for testing a dvb-s tuner for stability issues. Thanks Peter D. wrote: Attenuators are cheap, but a little bit hard to find. Normally people save money on the antenna and don't need an attenuator. It is probably easier to find a splitter, that will probably knock the signal strength down by 3 or 6 dB. Did you deliberately reply off list? You'd probably get a better response if you replied to the list. On Tuesday 13 March 2007 19:25, Gregor Fuis wrote: It would be enough for now, just the weakening part -20dB to 0dB! Peter D. wrote: On Tuesday 13 March 2007 09:51, Gregor Fuis wrote: Hello, Does somebody know if there is a device with which you can control signal strength. It would be great if it could control gain from -20dB to +20dB. A mast head amplifier? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Dvico Dual 4 - Australian issues.
Can other people in .au who have this device please post to this thread to keep updated on any progress. Hi Julian, have you tried the updated usbreplay that Markus Rechberger mentioned shortly after your original post? I don't have access to a Windows box at the moment, so I can only use my DualDigital4 with Linux. However have you tried using ProcessMonitor from sysinternals to see what files and registry entries are being accessed when running on the Windows side. I have no idea if that would help or not. Theres a patch for AU that breaks it for UK/EU apparently. Patch? For Windows or Linux? Petey Leinonen. Send instant messages to your online friends http://au.messenger.yahoo.com ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] cx88-dvb card not generating interrupts?
I've got a bit of an odd problem. I'm trying to run a cx88-dvb board (KWorld/VStream XPert DVB-T) in a cobalt raq550. (Yes, I'm probably mad). The card works fine in other boxes, but in this box doesn't generate any interrupts (I get cx88[0]/2-mpeg: cx8802_timeout again and again in the logs, and /proc/interrupts shows 0 for the interrupt count). The lspci output looks fine, and I've tested another multifunction card (dual-channel scsi) and it gets mapped to the same IRQ and works fine. I'm wondering if there's something the driver needs to do to enable generation of interrupts or something like that, which would be done by the bios on a 'normal' machine but doesn't happen on the cobalt? Running tzap actually gives output as if the card was working fine: tzap ABC2 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 78150 Hz video pid 0x090a, audio pid 0x090c status 00 | signal 4a3f | snr | ber | unc | status 1f | signal ec7f | snr 9c9c | ber | unc | FE_HAS_LOCK status 1f | signal ed4f | snr 9c9c | ber | unc | FE_HAS_LOCK status 1f | signal ed1f | snr 9b9b | ber | unc | FE_HAS_LOCK status 1f | signal ed2f | snr 9c9c | ber | unc | FE_HAS_LOCK status 1f | signal edbf | snr 9c9c | ber | unc | FE_HAS_LOCK so clearly at least some of the card is working! (if it wasn't for the scsi card working, I'd be assuming the interrupt routing was simply completely borked for multifunction cards, but since the scsi card works fine I'm rather puzzled). Kernel is a kernel.org 2.6.20 with the minimal patches to get the cobalt working (for the people who haven't had the pleasure of meeting one of these machines, it does not have a regular PC bios; there's a very low level bootstrap in rom which then loads a modified and cut-down linux 2.4 kernel out of flash, which then loads the proper kernel off disk and boots it). Cheers, David ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] same problem with 2.6.20 (FC6) and LITE-ON USB2.0 DVB-T Tuner
Le Mon, 12 Mar 2007 17:24:17 +, Julien Tognazzi a écrit: Hi all, Is it normal that with the Fedora Core 6 kernel, the LITE-ON USB2.0 DVB-T Tuner (dvb_usb_dibusb_mc module) give no frontend ? I just tried with the new kernel available in updates/testing (2.6.20-1.2925.fc6) and I got the same frontend error plus a warning (see below dmesg output) usb 5-7: new high speed USB device using ehci_hcd and address 3 usb 5-7: configuration #1 chosen from 1 choice dvb-usb: found a 'LITE-ON USB2.0 DVB-T Tuner' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-dibusb-6.0.0.8.fw' usbcore: registered new interface driver dvb_usb_dibusb_mc usb 5-7: USB disconnect, address 3 dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. usb 5-7: new high speed USB device using ehci_hcd and address 4 usb 5-7: configuration #1 chosen from 1 choice dvb-usb: found a 'LITE-ON USB2.0 DVB-T Tuner' in warm state. **WARNING** I2C adapter driver [LITE-ON USB2.0 DVB-T Tuner] forgot to specify physical device; fix it! dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (LITE-ON USB2.0 DVB-T Tuner). dvb-usb: no frontend was attached by 'LITE-ON USB2.0 DVB-T Tuner' input: IR-receiver inside an USB DVB receiver as /class/input/input7 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: LITE-ON USB2.0 DVB-T Tuner successfully initialized and connected. Is it a bug with the dvb driver (it used to work like 6 month ago) ? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] cx88-dvb card not generating interrupts?
I had interrupt problems with a cx88 and Asus A8V-MX motherboard. The interrupt assigned was being disabled later on (check dmseg). I eventually got it to work by passing noirqdebug and pci=routeirq to the kernel at boot. HTH regards Patrick davidm wrote: I've got a bit of an odd problem. I'm trying to run a cx88-dvb board (KWorld/VStream XPert DVB-T) in a cobalt raq550. (Yes, I'm probably mad). The card works fine in other boxes, but in this box doesn't generate any interrupts (I get cx88[0]/2-mpeg: cx8802_timeout again and again in the logs, and /proc/interrupts shows 0 for the interrupt count). The lspci output looks fine, and I've tested another multifunction card (dual-channel scsi) and it gets mapped to the same IRQ and works fine. I'm wondering if there's something the driver needs to do to enable generation of interrupts or something like that, which would be done by the bios on a 'normal' machine but doesn't happen on the cobalt? Running tzap actually gives output as if the card was working fine: tzap ABC2 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 78150 Hz video pid 0x090a, audio pid 0x090c status 00 | signal 4a3f | snr | ber | unc | status 1f | signal ec7f | snr 9c9c | ber | unc | FE_HAS_LOCK status 1f | signal ed4f | snr 9c9c | ber | unc | FE_HAS_LOCK status 1f | signal ed1f | snr 9b9b | ber | unc | FE_HAS_LOCK status 1f | signal ed2f | snr 9c9c | ber | unc | FE_HAS_LOCK status 1f | signal edbf | snr 9c9c | ber | unc | FE_HAS_LOCK so clearly at least some of the card is working! (if it wasn't for the scsi card working, I'd be assuming the interrupt routing was simply completely borked for multifunction cards, but since the scsi card works fine I'm rather puzzled). Kernel is a kernel.org 2.6.20 with the minimal patches to get the cobalt working (for the people who haven't had the pleasure of meeting one of these machines, it does not have a regular PC bios; there's a very low level bootstrap in rom which then loads a modified and cut-down linux 2.4 kernel out of flash, which then loads the proper kernel off disk and boots it). Cheers, David ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Change dvb-pll handling of IF frequency
On 3/13/07, Trent Piepho [EMAIL PROTECTED] wrote: The basic frequency calculation done in dvb-pll is to take the desired frequency, add the IF frequency, and then divide by the reference frequency. When dvb-pll does the division, it just rounds the result down. It would make more sense to round to the nearest integer, which is done by adding 1/2 the divisor (the reference frequency) before dividing. Some PLL definitions already do this, by adding one half the reference frequency to the IF frequency. The effect is the same, except one looking at the code doesn't know if they are seeing the IF frequency, or the IF frequency plus 1/2 the reference frequency. Of course some PLL defintions do it one way and some do it the other and there is no record of which is which. I think it makes a lot more sense put just the IF frequency in the PLL definition, and take care of rounding properly in the dvb-pll code. So I have attached a patch which does this. In order to do this, I had to guess which PLLs had stepsize/2 added to the offset and which didn't. The second patch moves the IF frequency out of the per-band data. There is no reason for the IF to change from one band to another, and in all of the PLLs defined the IF is constant across bands. As far as which PLLs had offsets with stepsize/2 added and which didn't, I've made a list of all the IF frequencies defined in dvb-pll: dvb_pll_thomson_dtt7610 44 dvb_pll_microtune_4042 44 dvb_pll_thomson_dtt761x 44 dvb_pll_lg_tdvs_h06xf 44 dvb_pll_tdhu2 44 dvb_pll_tuv1236d44 dvb_pll_samsung_tbmv44 dvb_pll_tua6010xs 36 1/8 dvb_pll_thomson_dtt7579 36 1/6 dvb_pll_tded4 36 1/6 dvb_pll_tua6034 36 1/6 dvb_pll_unknown_1 36 1/6 dvb_pll_thomson_dtt759x 36 1/6 dvb_pll_lg_z201 36 1/6 dvb_pll_philips_td1316 36 1/6 (rounded to nearest kHz) dvb_pll_tda665x 36 1/6 (rounded to nearest kHz) + step/2 dvb_pll_fmd1216me 36 1/8 (rounded to two decimals) + step/2 dvb_pll_thomson_fe6600 36 1/8 (rounded to two decimals) + step/2 dvb_pll_env57h1xd5 36 1/8 + step dvb_pll_philips_sd1878_tda8261 499 IF doesn't apply to this device as it is a ZIF MOPLL manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DSM-CC Synchronized Download Protocol
Hello, not shure if this is the right place for this question, but i don't know any better. I'm looking for information in the DSM-CC Synchronized Download Protocol. In an amandment to MPEG-2 Systems this is stated to be a synchronous method of delivering data in an MPEG-2 stream. It's said that the data is inserted into DSM-CC Download sections which carry a PTS entry for synchronization. But i can't find any information about this in 13818-6 which secifies DSM-CC. Maybe someone can explain me this, or hand me an article for further reading. Thanks in Advance, Thomas ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DSM-CC Synchronized Download Protocol
On Tue, Mar 13, 2007, Thomas Lagemann wrote: I'm looking for information in the DSM-CC Synchronized Download Protocol. In an amandment to MPEG-2 Systems this is stated to be a synchronous method of delivering data in an MPEG-2 stream. It's said that the data is inserted into DSM-CC Download sections which carry a PTS entry for synchronization. But i can't find any information about this in 13818-6 which secifies DSM-CC. Maybe someone can explain me this, or hand me an article for further reading. I have no idea what it is but ISO lists this: ISO/IEC 13818-6:1998/Amd 2:2000 http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=33123ICS1=35ICS2=40ICS3= HTH, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Change dvb-pll handling of IF frequency
Trent Piepho wrote: The basic frequency calculation done in dvb-pll is to take the desired frequency, add the IF frequency, and then divide by the reference frequency. When dvb-pll does the division, it just rounds the result down. It would make more sense to round to the nearest integer, which is done by adding 1/2 the divisor (the reference frequency) before dividing. Some PLL definitions already do this, by adding one half the reference frequency to the IF frequency. The effect is the same, except one looking at the code doesn't know if they are seeing the IF frequency, or the IF frequency plus 1/2 the reference frequency. Of course some PLL defintions do it one way and some do it the other and there is no record of which is which. I think it makes a lot more sense put just the IF frequency in the PLL definition, and take care of rounding properly in the dvb-pll code. So I have attached a patch which does this. In order to do this, I had to guess which PLLs had stepsize/2 added to the offset and which didn't. The second patch moves the IF frequency out of the per-band data. There is no reason for the IF to change from one band to another, and in all of the PLLs defined the IF is constant across bands. As far as which PLLs had offsets with stepsize/2 added and which didn't, I've made a list of all the IF frequencies defined in dvb-pll: dvb_pll_thomson_dtt7610 44 dvb_pll_microtune_4042 44 dvb_pll_thomson_dtt761x 44 dvb_pll_lg_tdvs_h06xf 44 dvb_pll_tdhu2 44 dvb_pll_tuv1236d44 dvb_pll_samsung_tbmv44 dvb_pll_tua6010xs 36 1/8 dvb_pll_thomson_dtt7579 36 1/6 dvb_pll_tded4 36 1/6 dvb_pll_tua6034 36 1/6 dvb_pll_unknown_1 36 1/6 dvb_pll_thomson_dtt759x 36 1/6 dvb_pll_lg_z201 36 1/6 dvb_pll_philips_td1316 36 1/6 (rounded to nearest kHz) dvb_pll_tda665x 36 1/6 (rounded to nearest kHz) + step/2 dvb_pll_fmd1216me 36 1/8 (rounded to two decimals) + step/2 dvb_pll_thomson_fe6600 36 1/8 (rounded to two decimals) + step/2 dvb_pll_env57h1xd5 36 1/8 + step dvb_pll_philips_sd1878_tda8261 499 Anyway, from this list I think it's clear that the PLLs with a pre-adjusted offset are dvb_pll_tda665x, dvb_pll_fmd1216me, dvb_pll_thomson_fe6600, and dvb_pll_env57h1xd5. dvb_pll_philips_sd1878_tda8261 is an odd one, as it's the only satellite PLL with zero-IF output in the list. It uses an offset of 499 with a stepsize of 500 kHz so that it rounds _up_. I've left this PLL rounding up, assuming there is a reason it was this way. Also, dvb_pll_env57h1xd5 is not 36 1/8 + step/2, but 36 1/8 + step. I think this is a bug. If you go back to patch 1740 which created the dvb-pll definition, you'll see it was taken from the dibusb driver. The original code for this pll was: u32 freq_khz = fep-frequency / 1000; u32 tfreq = ((freq_khz + 36125)*6 + 500) / 1000; If you multiple that out and reduce it, you get: tfreq = (fep-frequency + 36125000 + 17/2) / 17; But the dvb-pll definition is using 36125000 + 17. Trent, This looks good to me, pending review from the other dvb developers. Acked-by: Michael Krufky mkrufky at linuxtv dot org ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DSM-CC Synchronized Download Protocol
Johannes Stezenbach schrieb: On Tue, Mar 13, 2007, Thomas Lagemann wrote: I'm looking for information in the DSM-CC Synchronized Download Protocol. In an amandment to MPEG-2 Systems this is stated to be a synchronous method of delivering data in an MPEG-2 stream. It's said that the data is inserted into DSM-CC Download sections which carry a PTS entry for synchronization. But i can't find any information about this in 13818-6 which secifies DSM-CC. Maybe someone can explain me this, or hand me an article for further reading. I have no idea what it is but ISO lists this: ISO/IEC 13818-6:1998/Amd 2:2000 http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=33123ICS1=35ICS2=40ICS3= thanks, that explains at least why there's nothing to find in the original specification. But it seems the paper is not available for free. Before i spend money on this (though its not much) id like to know a bit more about it. Also most of the iso standard papers do not include much info about the practical use. So maybe anyone who worked with this can explain me some details: - does this method require flow-control (kommunication with the server)? - what are the requirements for a receiver to manage dsm-cc download sections ? - is there support of this method in DVB? (since i only know of the DSM-CC caraousel being used in DVB) regards, Thomas ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: DVB - Mega Sky 580 Driver
I think that device should be supported by the official v4l-dvb repository on linuxtv.org. http://linuxtv.org/repo/ follow the steps from the section Checkout V4L-DVB or dvb-apps on. Markus On 3/13/07, Martinho Sambiase [EMAIL PROTECTED] wrote: Hi, Im sorry to disturb you but I think you are the only one that can help me. I just bought a USB DVB-t device called Mega Sky 580 (Bus 001 Device 005: ID 0db0:5581 Micro Star International). I run OpenSuse 10.2. It seems that I need a driver for the device to work. I was searching for it on the web but could not find anything. The only thing I found was a link http://linuxtv.org/hg/~mkrufky/megasky http://linuxtv.org/hg/%7Emkrufky/megasky that could provide me the driver. The link seems not to be working. Please, I would really appreciate any help. Regards, Martinho Sambiase -- Markus Rechberger ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HVR4000 Support
On Tuesday 13 March 2007 14:34, Steven Toth wrote: Hi, I've created a new tree based on the current mainline v4l/dvb tree, Manu's multiproto patches and the HVR400 specific patches. It can be found here http://linuxtv.org/hg/~stoth/hvr4000 I don't have any immediate hardware available for test, so your mileage may vary. If you'd like to spend the time testing then I'll happy take feedback/bugs via this ML. Looking at the patch description: 1. DVB-T is not working, pending a GPIO change 2. DiSEqC is not working Regular DVB-S and DVB-S2 should work fine. Remember you'll need apps that support the multiproto API's to use the S2 functionality. Lastly, see my posting to the ML last week for instructions on obtaining the firmware. Oh goody, we're getting there. When unloading the modules, I get: isl6421 6656 4294967295 cx2411617664 4294967295 Forcing there removal does not seem to harm the system. I'm not too sure whether it is handling the card correctly, although it does see it Mar 13 20:31:49 eth5 kernel: cx2388x alsa driver version 0.0.6 loaded Mar 13 20:31:49 eth5 kernel: PCI: Enabling device :02:0a.1 (0110 - 0112) Mar 13 20:31:49 eth5 kernel: ACPI: PCI Interrupt :02:0a.1[A] - GSI 22 (level, low) - IRQ 217 Mar 13 20:31:49 eth5 kernel: cx88[0]/1: CX88x/0: ALSA support for cx2388x boards Mar 13 20:31:49 eth5 kernel: cx2388x dvb driver version 0.0.6 loaded Mar 13 20:31:49 eth5 kernel: cx8802_register_driver() -registering driver type=dvb access=shared Mar 13 20:31:49 eth5 kernel: CORE cx88[0]: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=57] Mar 13 20:31:49 eth5 kernel: cx88[0]/2: cx2388x based dvb card Mar 13 20:31:49 eth5 kernel: cx24116: cx24116_attach Mar 13 20:31:49 eth5 kernel: DVB: registering new adapter (cx88[0]). Mar 13 20:31:49 eth5 kernel: DVB: registering frontend 1 (Conexant CX24116/CX24118)... Mar 13 20:31:50 eth5 kernel: cx2388x blackbird driver version 0.0.6 loaded Mar 13 20:31:50 eth5 kernel: cx8802_register_driver() -registering driver type=blackbird access=shared Mar 13 20:31:50 eth5 kernel: CORE cx88[0]: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=57] Mar 13 20:31:50 eth5 kernel: cx8802_register_driver() -probe failed err = -19 Other than that, I still cannot get DVB-S or SVB-S2 to work. That could be because my knowledge of about the sat stuff is sadly lacking. Bob ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Random Oops
Why am I getting these random kernel Oops? Is it DVB's fault or something else? I have no knowledge of DVB or kernel internals... Kind regards, Benjie. [17267534.12] ehci_hcd :00:10.4: fatal error [17267534.12] ehci_hcd :00:10.4: HC died; cleaning up [17267534.12] usb 1-3: USB disconnect, address 2 [17267534.12] dvb-usb: bulk message failed: -22 (1/-909000848) [17267534.124000] dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully deinitialized and disconnected. [17267534.132000] BUG: unable to handle kernel paging request at virtual address 2d31005f [17267534.132000] printing eip: [17267534.132000] f8d89b7e [17267534.132000] *pde = [17267534.132000] Oops: [#1] [17267534.132000] SMP [17267534.132000] Modules linked in: lirc_serial binfmt_misc ipt_TCPMSS xt_tcpudp ip_nat_irc ip_nat_ftp iptable_nat cpufreq_userspace cpufreq_stats freq_table cpufreq_powersave cpufreq_ondemand cpufreq_conservative video tc1100_wmi sbs sony_acpi i2c_ec asus_acpi it87 hwmon_vid eeprom i2c_isa ipaq usbserial ppp_async ppp_generic crc_ccitt ip6table_filter ip6_tables sbp2 lirc_dev bt878 tvaudio saa7134_alsa tda9887 tuner snd_seq_dummy snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq nvidia bttv dvb_usb_dtt200u dvb_usb saa7134 snd_bt87x snd_via82xx dvb_core dvb_pll snd_cmipci snd_opl3_lib snd_hwdep snd_mpu401_uart snd_via82xx_modem snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_rawmidi snd_seq_device video_buf v4l1_compat ir_kbd_i2c ir_common analog via_agp agpgart pcspkr v4l2_common tveeprom videodev gameport snd soundcore snd_page_alloc usbhid vesafb fbcon tileblit font bitblit softcursor vga16fb vgastate capability commoncap fan thermal processor sata_via libata sd_mod generic ide_disk ide_cd cdrom ohci1394 ieee1394 uhci_hcd ehci_hcd ide_generic reiserfs evdev sg shpchp pci_hotplug btcx_risc i2c_algo_bit i2c_viapro compat_ioctl32 serio_raw skge psmouse sk98lin floppy tsdev slhc i2c_dev i2c_core usb_storage scsi_mod libusual usbtest usbcore af_packet md_mod dm_mod ipv6 via82cxxx ext2 ext3 jbd hotkey dev_acpi ac pcc_acpi button container battery lp parport_pc ppdev parport iptable_filter xt_state ip_conntrack_ftp ip_conntrack_irc ipt_REJECT ipt_TOS ipt_MASQUERADE ip_nat ip_conntrack nfnetlink ipt_LOG iptable_mangle ip_tables xt_limit x_tables rfcomm l2cap bluetooth [17267534.132000] CPU:0 [17267534.132000] EIP:0060:[f8d89b7e]Tainted: PF VLI [17267534.132000] EFLAGS: 00010246 (2.6.17-11-generic #2) [17267534.132000] EIP is at dvb_dvr_poll+0x3e/0x90 [dvb_core] [17267534.132000] eax: ebx: 0106 ecx: f8d89b40 edx: 2d310063 [17267534.132000] esi: ec931960 edi: 2d310033 ebp: f70c5e9c esp: f70c5c10 [17267534.132000] ds: 007b es: 007b ss: 0068 [17267534.132000] Process mythbackend (pid: 30166, threadinfo=f70c4000 task=f2726030) [17267534.132000] Stack: c012b7c0 f2726030 0020 ec931960 c017e085 f70c5c54 f70c5fac [17267534.132000]a39fe3f4 a39fe3fc f70c5e94 f70c5e94 0001 0001 [17267534.132000]f70c5e94 c017ed60 0001 ec931960 f2726030 [17267534.132000] Call Trace: [17267534.132000] c012b7c0 process_timeout+0x0/0x10 c017e085 do_sys_poll+0x205/0x400 [17267534.132000] c017ed60 __pollwait+0x0/0xf0 c011bde0 default_wake_function+0x0/0x10 [17267534.132000] f8ab58f3 qh_append_tds+0x133/0x540 [ehci_hcd] f8ab5dca qh_urb_transaction+0xca/0x320 [ehci_hcd] [17267534.132000] f8ab6b64 ehci_urb_enqueue+0xf4/0xd00 [ehci_hcd] f8d8b37d dvb_dmx_swfilter_packet+0x34d/0x370 [dvb_core] [17267534.132000] f8a077b9 usb_submit_urb+0x199/0x200 [usbcore] f8a06e4d hcd_submit_urb+0x1dd/0x930 [usbcore] [17267534.132000] f8d8ac34 dvb_dmxdev_ts_callback+0xa4/0xd0 [dvb_core] f8d8b37d dvb_dmx_swfilter_packet+0x34d/0x370 [dvb_core] [17267534.132000] c01e3071 rb_insert_color+0x71/0xd0 f8a077b9 usb_submit_urb+0x199/0x200 [usbcore] [17267534.132000] f8d379d8 dvb_usb_urb_complete+0x88/0x100 [dvb_usb] c012b819 do_timer+0x39/0x360 [17267534.132000] c010f142 mark_offset_pmtmr+0x22/0xee0 c010709e timer_interrupt+0x6e/0xb0 [17267534.132000] c0149415 __do_IRQ+0xc5/0x110 c0105c8e do_IRQ+0x1e/0x30 [17267534.132000] c010408a common_interrupt+0x1a/0x20 c01e55b9 copy_to_user+0x39/0x70 [17267534.132000] f8d9301f dvb_ringbuffer_read+0xcf/0x100 [dvb_core] f8d89c2f dvb_dmxdev_buffer_read+0x5f/0x1b0 [dvb_core] [17267534.132000] f8ab7afe ehci_irq+0x11e/0x190 [ehci_hcd] c016afc9 vfs_read+0x119/0x180 [17267534.132000] f8d89d80 dvb_dvr_read+0x0/0x40 [dvb_core] c017e2bd sys_poll+0x3d/0x50 [17267534.132000] c0102fbb sysenter_past_esp+0x54/0x79 [17267534.132000] Code: 8b 40 78 8b 78 28 a1 88 d5 d9 f8 85 c0 75 4e 85 db 8d 57 30 74 0a 85 d2 74 06 89 d9 89 f0 ff 13 f6 46 18 03 bb 06 01 00 00 75 1a 83 7f 2c 01 8d 47 1c 19 db e8 84 90 00 00 f7 d3 83 e3 4b 85 c0 [17267534.132000] EIP: [f8d89b7e]
Re: [linux-dvb] fmd1216 integration
hi
Trent Piepho schrieb:
On Tue, 13 Mar 2007, Hartmut Hackmann wrote:
I think that should be done is adjust the IF values in in the dvb-pll
config structs to NOT include step-size/2 for rounding. Just use the IF
frequency. This is how most of the PLL definitions are already. The code
which calculates the divisor should be changed to round to the nearest
integer, rather than round down.
Jep
I've made patches to do this, I'll send them to the list later.
philips_fmd1216_tuner_init() just sends { 0x0b, 0xdc, 0x9c, 0xa0 } to the
tuner. It could be replaced with the dvb-pll version, which will have
the same effect.
I will have a look
My fmd1216 patch will have the tuner init function send {0xdd, 0xa0} to the
tuner. That will set the agc value (byte AB) to 0xa0, the same thing.
That's new for me. But if the data go to the upper bytes first, you are right.
after _module loading_ it will send {0x0b, 0xdc, 0x9c, 0x60} and then
{0x0b, 0xdc, 0x86, 0x54} to the tuner. The first sequence sets AGC to
analog mode (IMHO, the v4l tuner driver should do this for tuner init,
but it doesn't). The second sequence just tunes to some random frequency
for no apparent reason. Neither actually turns the tuner off!
AFIK the v4l tuner driver can't do this since init is called only one at
module initialization. Maybe the sequence is overdone but the intention is:
Yeah, V4L should do it, but doesn't. I think there is a special case hack
for some tuners where on every tune, they take the 4-byte command, send it
once, then modify the last two bytes to set AGC, and then send it again.
- set up RF AGC
- set the PLL to a valid frequency. I was told that this is important.
If you just send two bytes, then it's not necessary to change the frequency
from what it was at before.
Anyway, I don't think the frequency is valid either:
divisor = 0x0bdc, ratio bits = 1,1 = 62.5 kHz, so freq = 189.75 MHz
But, BB = 0x54, which is analog mode HIGH band. 189.75 MHz would be in the
LOW band. (remember to subtract the IF frequency to compare to the
bandswitch points used in the code)
Ratio bits are 1,0 so 167kHz. But i don't think ath this is so important..
- turn on the tda9887. This is invisible on the I2C bus in DVB mode.
How does that happen? I figured P4 just changed the SAW filters, but it
enables/disables the tda9887 too?
I have no idea why and how this is done, i just observed that...
I am not aware that the tuner actually has a sleep mode. I used the sleep
call be cause it simply was there.
If you set the low bit of CB, it disables the tuning voltage. That's
probably the closest thing to sleep mode there is.
I think this could be replaced with the dvb-pll sleep function, if a
sleep sequence was added to dvb_pll_fmd1216me. We should send {0x9d,
0x60}, which will turn the tuner off and set the AGC back to the analog
recommended value.
Hm, the sequence is incomplete.. Do you have more information about the
PLL chip?
The documentation for the Infineon TUA6034 should be easy to find if you
don't have it. It's pretty clear that you don't need to send the divisor
bytes each time. You can just send CB+BB or in this case CB+AB. And I've
verified that indeed you can set the AGC values with just two bytes.
If this is the used PLL chip, i should have a look.
Did you check whether it is allowed to cut off the lo?
Are you aware that there is also the td1316?
One tuner at a time
Ack
I'd like to proceed this way:
- first i correct the bug in the sleep function.
- When your changes in dvb-pll are in mainstream, i will adapt the code in
saa7134-dvb. (you might decide to kick me)
OK?
Hartmut
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DSM-CC Synchronized Download Protocol
DSM-CC is used a lot in ISDB-T / ISDB-S for data broadcasting and firmware download. Have a poke around http://www.dibeg.org/aribstd/ARIBSTD.htm One of B-xx standards should cover DSM-CC related stuff. I know it does because I wrote a parser for DDI and DDB messages a few months ago. By the way, the stuff follows standard section table format. -t On 3/14/07, Thomas Lagemann [EMAIL PROTECTED] wrote: Johannes Stezenbach schrieb: On Tue, Mar 13, 2007, Thomas Lagemann wrote: I'm looking for information in the DSM-CC Synchronized Download Protocol. In an amandment to MPEG-2 Systems this is stated to be a synchronous method of delivering data in an MPEG-2 stream. It's said that the data is inserted into DSM-CC Download sections which carry a PTS entry for synchronization. But i can't find any information about this in 13818-6 which secifies DSM-CC. Maybe someone can explain me this, or hand me an article for further reading. I have no idea what it is but ISO lists this: ISO/IEC 13818-6:1998/Amd 2:2000 http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=33123ICS1=35ICS2=40ICS3= thanks, that explains at least why there's nothing to find in the original specification. But it seems the paper is not available for free. Before i spend money on this (though its not much) id like to know a bit more about it. Also most of the iso standard papers do not include much info about the practical use. So maybe anyone who worked with this can explain me some details: - does this method require flow-control (kommunication with the server)? - what are the requirements for a receiver to manage dsm-cc download sections ? - is there support of this method in DVB? (since i only know of the DSM-CC caraousel being used in DVB) regards, Thomas ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HVR4000 Support
Bob wrote: On Tuesday 13 March 2007 14:34, Steven Toth wrote: Hi, I've created a new tree based on the current mainline v4l/dvb tree, Manu's multiproto patches and the HVR400 specific patches. It can be found here http://linuxtv.org/hg/~stoth/hvr4000 I don't have any immediate hardware available for test, so your mileage may vary. If you'd like to spend the time testing then I'll happy take feedback/bugs via this ML. Looking at the patch description: 1. DVB-T is not working, pending a GPIO change 2. DiSEqC is not working Regular DVB-S and DVB-S2 should work fine. Remember you'll need apps that support the multiproto API's to use the S2 functionality. Lastly, see my posting to the ML last week for instructions on obtaining the firmware. Oh goody, we're getting there. When unloading the modules, I get: isl6421 6656 4294967295 cx2411617664 4294967295 Forcing there removal does not seem to harm the system. I'm not too sure whether it is handling the card correctly, although it does see it Mar 13 20:31:49 eth5 kernel: cx2388x alsa driver version 0.0.6 loaded Mar 13 20:31:49 eth5 kernel: PCI: Enabling device :02:0a.1 (0110 - 0112) Mar 13 20:31:49 eth5 kernel: ACPI: PCI Interrupt :02:0a.1[A] - GSI 22 (level, low) - IRQ 217 Mar 13 20:31:49 eth5 kernel: cx88[0]/1: CX88x/0: ALSA support for cx2388x boards Mar 13 20:31:49 eth5 kernel: cx2388x dvb driver version 0.0.6 loaded Mar 13 20:31:49 eth5 kernel: cx8802_register_driver() -registering driver type=dvb access=shared Mar 13 20:31:49 eth5 kernel: CORE cx88[0]: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=57] Mar 13 20:31:49 eth5 kernel: cx88[0]/2: cx2388x based dvb card Mar 13 20:31:49 eth5 kernel: cx24116: cx24116_attach Mar 13 20:31:49 eth5 kernel: DVB: registering new adapter (cx88[0]). Mar 13 20:31:49 eth5 kernel: DVB: registering frontend 1 (Conexant CX24116/CX24118)... Mar 13 20:31:50 eth5 kernel: cx2388x blackbird driver version 0.0.6 loaded Mar 13 20:31:50 eth5 kernel: cx8802_register_driver() -registering driver type=blackbird access=shared Mar 13 20:31:50 eth5 kernel: CORE cx88[0]: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=57] Mar 13 20:31:50 eth5 kernel: cx8802_register_driver() -probe failed err = -19 Other than that, I still cannot get DVB-S or SVB-S2 to work. That could be because my knowledge of about the sat stuff is sadly lacking. Bob Thanks for the feedback. Gregoire reported an issue via IRC today. It looks like the HVR4000 demod driver never receives the set_params call, to actually tune. I think this is probably a bug in dvb_core - manu's patches. I plan to repro tomorrow, expect more progress in the next day or so. Regards, Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
