Re: [linux-dvb] NXP 18211HDC1 tuner
Jarryd Beck wrote: On Sun, Mar 16, 2008 at 11:37 AM, Antti Palosaari [EMAIL PROTECTED] wrote: Jarryd Beck wrote: Here's the first frequency it tuned to, as you can see the one you set auto on is still auto, it didn't seem to autodetect anything. It was the same for all the other frequencies as well. tune to: 22650:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_1_16:HIERARCHY_NONE WARNING: tuning failed!!! tune to: 22650:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_1_16:HIERARCHY_NONE (tuning failed) WARNING: tuning failed!!! It does not matter what scan outputs as tuning parameters because it just shows same parameter that are set by used tuning file (at least when tuning fails). Driver will still try to auto detect correct parameters. In this case it still fails for reason or other that is not found yet. regards Antti -- http://palosaari.fi/ So the fact that it failed isn't actually telling us anything extra then? Would it only have been useful if it had actually worked? Also just to make sure I'm using the right drivers here, I'm using Michael's patch and not Antti's patch. Since it kernel oopses with both, Antti, do you want me to try with just your patch and not Michael's? Jarryd. You need to use that patch of mine because I dont think the af9015 i2c likes 39-byte i2c transfers. The patch that I sent to you breaks the tda182x1 register initialization into 16 register chunks. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] NXP 18211HDC1 tuner
Antti Palosaari wrote: I have no idea how to debug more. Without device it is rather hard to test many things. It will help a little if we know is tuner locked. Mike, is it easy to add debug writing for tuner to indicate if tuner is locked or not locked? I have used that method earlier with mt2060 tuner... There is a lock bit in register 0x01[6] but I have not found it to be reliable, especially not on the c1 part. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] NXP 18211HDC1 tuner
Jarryd Beck wrote: On Sun, Mar 16, 2008 at 11:47 AM, Michael Krufky [EMAIL PROTECTED] wrote: Antti Palosaari wrote: I have no idea how to debug more. Without device it is rather hard to test many things. It will help a little if we know is tuner locked. Mike, is it easy to add debug writing for tuner to indicate if tuner is locked or not locked? I have used that method earlier with mt2060 tuner... There is a lock bit in register 0x01[6] but I have not found it to be reliable, especially not on the c1 part. -Mike You won't believe this, but it worked. I think every time I tried both patches together I left .no_reconnect in. I tried it again with both patches applied, no other modifications, and it worked. Thanks for all your help, Jarryd. This is great news! For an experiment, can you try once more without my patch applied? This will just confirm whether or not we can write all 39 registers at once. If the patch that I gave you is truly needed, then I will integrate it into the official driver. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] NXP 18211HDC1 tuner
Jarryd Beck wrote: On Sun, Mar 16, 2008 at 1:04 PM, Michael Krufky [EMAIL PROTECTED] wrote: Jarryd Beck wrote: On Sun, Mar 16, 2008 at 11:47 AM, Michael Krufky [EMAIL PROTECTED] wrote: Antti Palosaari wrote: I have no idea how to debug more. Without device it is rather hard to test many things. It will help a little if we know is tuner locked. Mike, is it easy to add debug writing for tuner to indicate if tuner is locked or not locked? I have used that method earlier with mt2060 tuner... There is a lock bit in register 0x01[6] but I have not found it to be reliable, especially not on the c1 part. -Mike You won't believe this, but it worked. I think every time I tried both patches together I left .no_reconnect in. I tried it again with both patches applied, no other modifications, and it worked. Thanks for all your help, Jarryd. This is great news! For an experiment, can you try once more without my patch applied? This will just confirm whether or not we can write all 39 registers at once. If the patch that I gave you is truly needed, then I will integrate it into the official driver. Regards, Mike Takes half a minute to load when plugging in, keyboard is slow to respond when tuning, and I get lots of this: af9013_i2c_gate_ctrl: enable:0 af9013_i2c_gate_ctrl: enable:1 Applied the patch again and it was all fine. Jarryd. Thanks for the test, Jarryd. I will integrate this into the official tda18271 driver after testing again on my hardware here. I will probably make it an attach-time configurable option. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] NXP 18211HDC1 tuner
Antti Palosaari wrote: Jarryd Beck wrote: Also there's a blue light that comes on in windows when I tune, but it didn't come on in linux when tuned. Would it be possible to work out how to make that light come on when it has successfully tuned? Should be peace of cake to fix. I will check it later... Antti Antti, I created an attach-time parameter to limit the i2c transfer size during tda18271 initialization. Please take a look: http://linuxtv.org/hg/~mkrufky/tda18271/rev/8ab90c649c7b Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] NXP 18211HDC1 tuner
Antti Palosaari wrote: looks like possible bug found! Jarryd Beck wrote: On Fri, Mar 14, 2008 at 2:19 PM, Michael Krufky [EMAIL PROTECTED] wrote: This all happens very quickly on the hardware that I've tested ( a cx23887-based pcie card and a cypress fx2-based usb device). I've also heard good reports on saa713x-based pci cards. Is the i2c slow in the af9013 driver? Just checked from code and it looks like it is 60 kHz currently. It is not clear for me how kHz correlates to value written to register so let is be this time. Hmm.. 60 kHz compared to 400 kHz is a big difference, but we can deal with that later. The tuner driver is programmed to use 7mhz dvbt with IF centered at 3.8 mhz -- is the demod set to the same? hmm, I think there is bug now. I compared eeprom dumps and found that my MT2060 has IF1 = 36125 and eeprom of this device says it should be IF1 = 4300. Is 4.3 Mhz close enough (we are speaking same thing?)? 4.3 is not close enough to 3.8. If you don't know how to set the demod to 3.8, then we can do some hacks to make it work, but signal reception is likely to be very poor -- better off looking in his snoop log to see how the windows driver sets the demod to 3.8 Jerryd, change .tuner_if = 36125 to 4300 . It can be found from af9015 module. How do I find out about the demod? Is the speed of af9013 a question for me because I have no idea. One thing to test speed is also commenting out program tuner part from af9013 so it does not ask tuner to go frequency. It did not tune then. But, I still needs debug logs of the af9013. Then I can compare much more easier usb-sniff and debug values got from driver. Antti -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] NXP 18211HDC1 tuner
Jarryd Beck wrote: On Fri, Mar 14, 2008 at 11:13 AM, Antti Palosaari [EMAIL PROTECTED] wrote: Jarryd Beck wrote: I found the problem, the driver I had set .no_reconnect = 1 in af9015_properties, the one in af9015_new didn't. So after I changed that I tried again, it still didn't work. I enabled debugging and tried to tune to a channel and this is what I got in dmesg. I know this no_reconnect problem. But haven't found proper correction yet. Looks like sometimes with some hw / sw configuration it reconnects USB-bus after firmware download and sometimes not. When there is no_reconnect set it is possible that driver loads twice (two adapters) and it causes race condition when two drivers are accessing same hw same time and it hangs (remote polling causes hangs very soon after plug). You can help and test if it is OK set no_reconnect=0 and remove #if 0 -killed code by changing it to #if 1 in line where is comment firmware is running, reconnect device in the usb bus. This forces AF9015 chipset reconnect USB. usb 2-10: new high speed USB device using ehci_hcd and address 27 usb 2-10: configuration #1 chosen from 1 choice af9015_usb_probe: af9015_identify_state: reply:01 dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' af9015_download_firmware: dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Afatech AF9015 DVB-T USB2.0 stick) af9015_eeprom_dump: 00: 31 c2 bb 0b 00 00 00 00 13 04 29 60 00 02 01 02 10: 00 80 00 fa fa 10 40 ef 01 30 31 30 31 30 32 30 20: 35 30 35 30 30 30 30 31 ff ff ff ff ff ff ff ff 30: 00 00 3a 01 00 08 02 00 cc 10 00 00 9c ff ff ff 40: ff ff ff ff ff 08 02 00 1d 8d c4 04 82 ff ff ff 50: ff ff ff ff ff 26 00 00 04 03 09 04 10 03 4c 00 60: 65 00 61 00 64 00 74 00 65 00 6b 00 30 03 57 00 70: 69 00 6e 00 46 00 61 00 73 00 74 00 20 00 44 00 80: 54 00 56 00 20 00 44 00 6f 00 6e 00 67 00 6c 00 90: 65 00 20 00 47 00 6f 00 6c 00 64 00 20 03 30 00 a0: 31 00 30 00 31 00 30 00 31 00 30 00 31 00 30 00 b0: 36 00 30 00 30 00 30 00 30 00 31 00 00 ff ff ff c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff af9015_read_config: xtal:2 set adc_clock:28000 af9015_read_config: tuner id1:156 af9015_read_config: spectral inversion:0 af9015_set_gpios: af9013: firmware version:4.95.0 DVB: registering frontend 0 (Afatech AF9013 DVB-T)... af9015_tuner_attach: af9015_tda18271_tuner_attach: tda18271 5-00c0: creating new instance TDA18271HD/C1 detected @ 5-00c0 tda18271_init_regs: initializing registers for device @ 5-00c0 input: IR-receiver inside an USB DVB receiver as /class/input/input39 dvb-usb: schedule remote query interval to 200 msecs. dvb-usb: Afatech AF9015 DVB-T USB2.0 stick successfully initialized and connected. af9015_init: af9015_download_ir_table: input: Leadtek WinFast DTV Dongle Gold as /class/input/input40 input: USB HID v1.01 Keyboard [Leadtek WinFast DTV Dongle Gold] on usb-:00:02.1-10 tda18271_set_standby_mode: sm = 0, sm_lt = 0, sm_xt = 0 tda18271_init_regs: initializing registers for device @ 5-00c0 tda18271_tune: freq = 21950, ifc = 380, bw = 700, std = 0x1d tda18271_set_standby_mode: sm = 0, sm_lt = 0, sm_xt = 0 tda18271_init_regs: initializing registers for device @ 5-00c0 tda18271_set_standby_mode: sm = 1, sm_lt = 0, sm_xt = 0 There is no debug logs from af9013 demodulator module. You can enable logs by modprobe af9013 debug=1. Remember rmmod modules first from memory rmmod dvb_usb_af9015 af9013 mt2060 dvb_usb dvb_core af9013 debug should log rather much useful data when tuning to channel. Did you try change GPIO3 as mentioned earlier? regards Antti -- http://palosaari.fi/ I tried what you said, it works with no_reconnect = 1 and #if 0, and it also works with no_reconnect = 0 and #if 1, but no_reconnect = 0 and #if 0 doesn't work. It has a fit if I use no_reconnect = 1 and #if 1. It gives me a lot of this: Mar 14 13:42:17 localhost kernel: af9015: af9015_rw_udev: receiving failed: -22 Mar 14 13:42:17 localhost kernel: dvb-usb: error while querying for an remote control event. I also tried changing the rf_spec_inv and gpio3 but that didn't seem to do anything. It seems like it's the tuner, from dmesg the rest seems to be working fine. Here is dmesg with debug enabled on af9013 too: usb 2-10: new high speed USB device using ehci_hcd and address 7 usb 2-10: configuration #1 chosen from 1 choice af9015_usb_probe: af9015_identify_state:
Re: [linux-dvb] NXP 18211HDC1 tuner
Jarryd Beck wrote: On Fri, Mar 14, 2008 at 2:22 PM, Jarryd Beck [EMAIL PROTECTED] wrote: Here is dmesg with debug enabled on af9013 too: usb 2-10: new high speed USB device using ehci_hcd and address 7 usb 2-10: configuration #1 chosen from 1 choice af9015_usb_probe: af9015_identify_state: reply:01 dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' af9015_download_firmware: dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Afatech AF9015 DVB-T USB2.0 stick) af9015_eeprom_dump: 00: 31 c2 bb 0b 00 00 00 00 13 04 29 60 00 02 01 02 10: 00 80 00 fa fa 10 40 ef 01 30 31 30 31 30 32 30 20: 35 30 35 30 30 30 30 31 ff ff ff ff ff ff ff ff 30: 00 00 3a 01 00 08 02 00 cc 10 00 00 9c ff ff ff 40: ff ff ff ff ff 08 02 00 1d 8d c4 04 82 ff ff ff 50: ff ff ff ff ff 26 00 00 04 03 09 04 10 03 4c 00 60: 65 00 61 00 64 00 74 00 65 00 6b 00 30 03 57 00 70: 69 00 6e 00 46 00 61 00 73 00 74 00 20 00 44 00 80: 54 00 56 00 20 00 44 00 6f 00 6e 00 67 00 6c 00 90: 65 00 20 00 47 00 6f 00 6c 00 64 00 20 03 30 00 a0: 31 00 30 00 31 00 30 00 31 00 30 00 31 00 30 00 b0: 36 00 30 00 30 00 30 00 30 00 31 00 00 ff ff ff c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff af9015_read_config: xtal:2 set adc_clock:28000 af9015_read_config: tuner id1:156 af9015_read_config: spectral inversion:0 af9015_set_gpios: af9013: firmware version:4.95.0 DVB: registering frontend 2 (Afatech AF9013 DVB-T)... af9015_tuner_attach: af9015_tda18271_tuner_attach: tda18271 5-00c0: creating new instance af9013_i2c_gate_ctrl: enable:1 af9013_i2c_gate_ctrl: enable:0 TDA18271HD/C1 detected @ 5-00c0 tda18271_init_regs: initializing registers for device @ 5-00c0 af9013_i2c_gate_ctrl: enable:1 af9013_i2c_gate_ctrl: enable:0 af9013_i2c_gate_ctrl: enable:1 af9013_i2c_gate_ctrl: enable:0 [...] af9013_i2c_gate_ctrl: enable:1 af9013_i2c_gate_ctrl: enable:0 input: IR-receiver inside an USB DVB receiver as /class/input/input9 dvb-usb: schedule remote query interval to 200 msecs. dvb-usb: Afatech AF9015 DVB-T USB2.0 stick successfully initialized and connected. af9015_init: af9015_download_ir_table: input: Leadtek WinFast DTV Dongle Gold as /class/input/input10 input: USB HID v1.01 Keyboard [Leadtek WinFast DTV Dongle Gold] on usb-:00:02.1-10 and when I try to tune it I get this: af9013_init af9013_reset af9013_power_ctrl: onoff:1 af9013_set_adc_ctrl: adc_clock:28000 af913_div: a:2800 b:100 x:19 af913_div: a:0 b:100 x:19 r:14680064 r:e0 af9013_init: load ofsm settings af9013_init: load tuner specific settings af9013_init: setting ts mode af9013_lock_led: onoff:1 tda18271_set_standby_mode: sm = 0, sm_lt = 0, sm_xt = 0 af9013_i2c_gate_ctrl: enable:1 af9013_i2c_gate_ctrl: enable:0 af9013_i2c_gate_ctrl: enable:1 af9013_i2c_gate_ctrl: enable:0 tda18271_init_regs: initializing registers for device @ 5-00c0 af9013_i2c_gate_ctrl: enable:1 af9013_i2c_gate_ctrl: enable:0 the last two lines are repeated about another 30 times and it just sits there doing nothing. Also for some reason it makes my keyboard really slow to respond just while it's tuning. Jarryd. The tda18271c1 driver does many i2c transactions during a tune request. This involves image rejection filter calibration, if it hasnt already been done at least once, and rf tracking filter calibration on every tune. This all happens very quickly on the hardware that I've tested ( a cx23887-based pcie card and a cypress fx2-based usb device). I've also heard good reports on saa713x-based pci cards. Is the i2c slow in the af9013 driver? The tuner driver is programmed to use 7mhz dvbt with IF centered at 3.8 mhz -- is the demod set to the same? -Mike How do I find out about the demod? Is the speed of af9013 a question for me because I have no idea. Somewhere along the way demod_address in a struct is set to AF9015_I2C_DEMOD which is 0x38. Is that what you wanted? I was hoping that Antti might know the answers those questions. Anyhow, there is something else related to the tuner that we can try. In the snoop log, I see that no i2c transactions are longer than 16 bytes. The linux driver writes 39 registers at once during its
Re: [linux-dvb] NXP 18211HDC1 tuner
On Tue, Mar 11, 2008 at 11:06 PM, Jarryd Beck [EMAIL PROTECTED] wrote: Also when I plugged it in, it sat there for about 10 seconds before finishing loading (dmesg printed another 5 lines about the device after about 10 seconds), but still no tuning. Can I see those five lines? ;-) While you're at it, you may as well include dmesg from the point that the bridge driver loads and on. Here's dmesg from the point it starts up until it finishes printing stuff. usb 2-10: new high speed USB device using ehci_hcd and address 22 usb 2-10: configuration #1 chosen from 1 choice af9015_usb_probe: af9015_identify_state: reply:01 dvb-usb: found a 'Leadtek Winfast DTV Dongle Gold' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' af9015_download_firmware: dvb-usb: found a 'Leadtek Winfast DTV Dongle Gold' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Leadtek Winfast DTV Dongle Gold) af9015_eeprom_dump: 00: 31 c2 bb 0b 00 00 00 00 13 04 29 60 00 02 01 02 10: 00 80 00 fa fa 10 40 ef 01 30 31 30 31 30 32 30 20: 35 30 35 30 30 30 30 31 ff ff ff ff ff ff ff ff 30: 00 00 3a 01 00 08 02 00 cc 10 00 00 9c ff ff ff 40: ff ff ff ff ff 08 02 00 1d 8d c4 04 82 ff ff ff 50: ff ff ff ff ff 26 00 00 04 03 09 04 10 03 4c 00 60: 65 00 61 00 64 00 74 00 65 00 6b 00 30 03 57 00 70: 69 00 6e 00 46 00 61 00 73 00 74 00 20 00 44 00 80: 54 00 56 00 20 00 44 00 6f 00 6e 00 67 00 6c 00 90: 65 00 20 00 47 00 6f 00 6c 00 64 00 20 03 30 00 a0: 31 00 30 00 31 00 30 00 31 00 30 00 31 00 30 00 b0: 36 00 30 00 30 00 30 00 30 00 31 00 00 ff ff ff c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff af9015_read_config: xtal:2 set adc_clock:28000 af9015_read_config: tuner id1:156 af9015_read_config: spectral inversion:0 af9015_set_gpios: af9013: firmware version:4.95.0 DVB: registering frontend 2 (Afatech AF9013 DVB-T)... af9015_tuner_attach: tda18271_tuner_attach: tda18271 5-00c0: creating new instance TDA18271HD/C1 detected @ 5-00c0 input: IR-receiver inside an USB DVB receiver as /class/input/input34 dvb-usb: schedule remote query interval to 200 msecs. dvb-usb: Leadtek Winfast DTV Dongle Gold successfully initialized and connected. af9015_init: af9015_download_ir_table: input: Leadtek WinFast DTV Dongle Gold as /class/input/input35 input: USB HID v1.01 Keyboard [Leadtek WinFast DTV Dongle Gold] on usb-:00:02.1-10 This is channel 7's entry in channels.conf: 7 Digital:17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:513:514:1312 Jarryd, I've analyzed the snoop that you've taken of the windows driver, and I conclude that the driver is basically doing exactly the same that the linux driver would do. The only thing that I cannot verify is whether or not the tda18211 uses the same table values as the tda18271c1. Based on the traffic in your snoop, it looks like the exact same algorithm is used, but based on a new set of tables -- I will not be able to confirm that without a tda18211 datasheet. The only thing that you can do is try the tda18271 driver and hopefully it will work. Have you tried to tune yet? There is a space in your channels.conf, 7 Digital -- you may want to change that to something like, 7Digital so that command line applications will work. Good Luck, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] NXP 18211HDC1 tuner
On Wed, Mar 12, 2008 at 4:36 PM, Jarryd Beck [EMAIL PROTECTED] wrote: Jarryd, I've analyzed the snoop that you've taken of the windows driver, and I conclude that the driver is basically doing exactly the same that the linux driver would do. The only thing that I cannot verify is whether or not the tda18211 uses the same table values as the tda18271c1. Based on the traffic in your snoop, it looks like the exact same algorithm is used, but based on a new set of tables -- I will not be able to confirm that without a tda18211 datasheet. The only thing that you can do is try the tda18271 driver and hopefully it will work. Have you tried to tune yet? There is a space in your channels.conf, 7 Digital -- you may want to change that to something like, 7Digital so that command line applications will work. Antti Palosaari wrote: hello I looked sniffs and find correct demodulator initialization values for this NXP tuner. Copy paste correct table from attached file and try. Hopefully it works. I compared your sniff to mt2060 and qt1010 based devices and there was still some minor differences to check. regards, Antti Antti, Please remember not to top-post. Jarryd, I have done further analysis on the snoop logs. Not only is the driver using the same protocol as the tda18271 linux driver, it also seems to use the same table values as used with the tda18271c1 -- The linux driver should work on your tuner without any modification at all. Regards, Mike I've got another tuner which works, so I know I'm tuning correctly, it just doesn't actually tune. I tried with mplayer, it just sat there saying dvb_tune Freq: 21950 and did nothing. It also made my whole computer go really slow, I don't know what it was actually doing. Antti, as I said I've never done anything like this before so I have no idea what I'm doing, so I have no idea where to paste which table. Please try using tzap. This will show you FE status once every second. Let it run for a whole minute -- maybe there is some noise that may cause it to take a longer time to lock (if that's the case, then there are some tweaks that we can do.) Show us the femon output produced by running tzap. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] NXP 18211HDC1 tuner
On Tue, Mar 11, 2008 at 5:05 PM, Jarryd Beck [EMAIL PROTECTED] wrote: Can you take logs with vendor WHQL driver and sent for further analysis? http://www.afatech.com/EN/support.aspx Antti -- http://palosaari.fi For some reason windows didn't like that driver. When I used the installer nothing happened, and when I used device manager it said this folder contains no information about your device. So I made a snoop with the driver on the CD, I hope it's good enough. I uploaded the snoop to http://download.yousendit.com/2B0B420876BFB959 While it was snooping, I plugged it in, tuned the card to a tv channel and pulled it out as quick as I could. If it helps, the channel was channel 7, sydney, australia. This helps. I can tell that your tda18211 is located at 0xC0, and it contains 0x83 in its ID register. This is the same ID byte that the tda18271c1 uses to identify itself -- hopefully that implies driver compatability, but we won't know for sure until you try it. The windows driver is only using the primary sixteen registers -- I don't know if the device even HAS the 23 extended registers that the tda18271 has... The driver that you're running does not seem to touch the extended registers at all. It's possible that the driver is simply blasting the register bytes to the tuner, without doing any calibration explicitly -- that could explain the 16 byte blasts without any transactions to the extended registers not sure -- this is all speculation. One thing I can say -- the Linux tda18271 driver should be able to detect your tuner at 0xC0 (0x60) as a tda18271c1 -- It's worth a try, and could certainly be possible that the driver *may* work as-is, although I suspect that some tweaking will be needed. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] NXP 18211HDC1 tuner
Jarryd Beck wrote: One thing I can say -- the Linux tda18271 driver should be able to detect your tuner at 0xC0 (0x60) as a tda18271c1 -- It's worth a try, and could certainly be possible that the driver *may* work as-is, although I suspect that some tweaking will be needed. Regards, Mike I changed it's i2c as loaded by af9015 to 0xC0, then got this in dmesg: TDA18271HD/C1 detected @ 5-00c0 Also when I plugged it in, it sat there for about 10 seconds before finishing loading (dmesg printed another 5 lines about the device after about 10 seconds), but still no tuning. Can I see those five lines? ;-) While you're at it, you may as well include dmesg from the point that the bridge driver loads and on. I don't know how the AF9015 works, but Antti does. What demod is on this device? ...or is that part of the AF9015? After googling some more, I found that the tda18211 supports DVB-T, ATSC and QAM ... Seems to be a digital-only tuner, while the tda18271 supports both digital and analog. The IF frequencies used for the tda18211 are the same as the default settings for the tda18271c1. - QAM: IF output centered at 4 and 5 MHz (bandwidth = 6 and 8 MHz respectively) - DVB-T: IF output centered at 3.3, 3.8 and 4.3 MHz (bandwidth = 6, 7 and 8MHz respectively) - ATSC: IF output centered at 3.25 MHz (bandwidth = 6MHz) ...I am looking at the snoop log some more -- My earlier statement was wrong -- I *do* see the driver programming all 39 registers, and now I do see calibration transactions taking place. I can see from this snoop that the value that belongs in the linux driver's std_bits parameter should be 0x19. It looks like the windows driver starts off with 0x18, and after some wiggling, locks at 0x19. Maybe it is first trying to tune to a 7 MHz DVB-T channel, then changes to 8 MHz. You said that you tuned to channel 7, sydney, australia -- is that an 8 MHz channel? What frequency is it on? -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] ~stoth/cx23885-video compile failure
aldebaran wrote: I own an HP/Hauppauge WinTv885 mod 77001 with cx23885 and xc3028 chipsets. Following the threads on this mailing list I understood these chipsets were supported by http://linuxtv.org/hg/~stoth/cx23885-video code, however I cannot even get past the 'make all'. [snip] Is it a bug? Were I supposed to do something? Thank you. your card is supported in the master repository: http://linuxtv.org/hg/v4l-dvb If you continue to see these types of errors, please post again. While waiting for a response, you can get past those errors by disabling the offending driver from the build. try 'make menuconfig'. hth, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] NXP 18211HDC1 tuner
Jarryd Beck wrote: Would someone be interested in writing tuner drivers for the NXP 18211HDC1 tuner? I recently bought the Winfast DTV Dongle Gold which uses an AF9015 chip and the NXP tuner. I've managed to get it working up to the point of needing the tuner, after that nothing works. I have no idea how to write tuner code, so if someone is interested, I can supply all the info I've got about the card and test whatever you write. Jarryd. Try the tda18271 driver -- I am under the impression that the tda18211 is a dvb-t only subset of the tda18271, but I dont have a tda18211 to test with and find out, nor do I have a tda18211 spec to look at. :-( Good Luck, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] NXP 18211HDC1 tuner
On Mon, Mar 10, 2008 at 12:46 PM, Michael Krufky [EMAIL PROTECTED] wrote: Jarryd Beck wrote: Would someone be interested in writing tuner drivers for the NXP 18211HDC1 tuner? I recently bought the Winfast DTV Dongle Gold which uses an AF9015 chip and the NXP tuner. I've managed to get it working up to the point of needing the tuner, after that nothing works. I have no idea how to write tuner code, so if someone is interested, I can supply all the info I've got about the card and test whatever you write. Jarryd. Try the tda18271 driver -- I am under the impression that the tda18211 is a dvb-t only subset of the tda18271, but I dont have a tda18211 to test with and find out, nor do I have a tda18211 spec to look at. :-( Good Luck, Mike Jarryd Beck wrote: I tried that, but I wasn't sure about a few things, I was kind of making stuff up as I went along. Can you tell me if I've done this right? At the af9015_tuner_attach function I wrote a function tda18211_tuner_attach which calls dvb_attach. The one thing I'm not sure about is the function tda18271_attach has a parameter u8 addr. I don't know what that is supposed to do or where I am supposed to get it from. You can look up a datasheet from the nxp site, it appears it goes under the name tda18211HD, I don't know what the C1 at the end means, I'm hoping it's the same thing. The datasheet isn't very useful though, it pretty much only has a circuit diagram and a couple of numbers on it. Jarryd. Jarryd, Please don't drop cc to the mailing list (added back), and also remember not to top quote. The addr parameter is the i2c address of the tuner. It is most likely 0x60 or 0x61. For an example of how to attach the tda18271 driver, look in cx23885-dvb.c for CX23885_BOARD_HAUPPAUGE_HVR1800 where alt_tuner is 1. The datasheet on the nxp site wont help me -- i need to see the register map. I think that the tda18271 driver will work with your tuner, but we may need to make some small adjustments. If you look in tda18271-fe.c , you'll find the code that autodetects between a TDA18271c1 and a TDA18271c2 ... If the autodetection fails for your tuner, you might want to try hardcoding it to the tda18271c1. If that works, then I'll ask you to enable the register dump debug option (debug = 4) in the tda18271 driver and send me a dmesg snippit. That should help us to add the autodetection later. hth, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Supported ATSC cards with HW mpeg encoders
Timothy D. Lenz wrote: I plan to get a dual ATSC tunner at some point, but as the 2250 does not seem to even be out yet and the HDHomeRun does not support NTSC, I am looking at getting a cheaper card that does suport NTSC for now. I am runing VDR and using the Nexus RGB out to a 23 year old Sony. So any HD must be down scaled anyway. AS a couple of our Digital locals are HD, this is what I want a card with NTSC for, to get the SDTV format of those channels. Cards like the pcHDTV HD-5500 while claiming to suport NTSC, do not have a HW mpeg encoder to convert the video to a format that can be sent out the Nexus video out. You would still need to set up software encoder/decoders. Problem is, the specs for ATSC tuner cards fall far short of providing this info. So what I want to know is, do any of the following cards have HW mpeg2 encoders that is suported by linux/vdr: DVICO FusionHDTV 5 RT Lite http://store.snapstream.com/fusionhdtv-lite.html?gclid=CJODl6T0-ZECFQovgwod0Vg_xA KWorld ATSC 115 http://www.newegg.com/Product/Product.aspx?Item=N82E16815260005 (they also have a 120, but I'm not finding much about linix suport for it ether) Pinnacle PCTV HD http://www.newegg.com/Product/Product.aspx?Item=N82E16815144018 None of the above have hardware mpeg encoders. A good card that I'd recommend for your needs right now is the Hauppauge HVR-1800. This is a dual tuner combo atsc/qam / hardware mpeg encoder card. Already the ATSC/QAM support is in the 2.6.24 kernel. Stoth has the hardware mpeg encoder working in his cx23885-video tree. After some more testing and cleanups, it will eventually be merged into the master repository, hopefully in time for the 2.6.26 kernel release. HTH, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [EXPERIMENTAL] cx88+xc3028 - tests are required - was: Re: Wh en xc3028/xc2028 will be supported?
Mauro Carvalho Chehab wrote: On Thu, 21 Feb 2008 20:38:09 -0500 Michael Krufky [EMAIL PROTECTED] wrote: Mauro Carvalho Chehab wrote: It is not that simple. Steven patch works for DTV on PCI Nano; Christopher patches for some other DiVCO boards (DTV also); my port of Markus patch for other boards (tested by Dâniel Fraga - Analog TV). What does one board have to do with another? Just because these boards all use xceive tuners does not mean that they should be grouped together. No, but we have patches for all of them. Because the user has the ability to load cx8800 without cx88-dvb, and likewise, the user has the ability to load cx88-dvb without cx8800, the attach call must be fully qualified such that the other side of the driver is not required to be loaded in order for the tuner to work. If you take a look at the code, you'll see that all code is at cx88xx. This module is loaded by cx8800, if you're using analog, or by cx8802, if you're using cx88-dvb or cx88-blackbird. The code initializes xc3028 before tuner attach. In the case of FusionHDTV5 pci nano, there will never be an attach call from the analog side of the driver, since the tuner is hidden behind the s5h1409's i2c gate, and analog mode is not supported with the current driver. If you set i2c_scan=1 on the PCI nano, the xceive tuner will not even show up in the scan. The proper fix is to open the i2c gate before loading tuner. This will allow i2c_scan to work and both analog and digital modes will work. Btw, this somewhat similar to what dvico_fusionhdtv_hybrid_init() does on cx88-cards. I've added a patch that should open the bridge for s5h1409. Please test. Mauro, It does not work. See my prior email in this thread for the explanation. [ 2912.355967] Linux video capture interface: v2.00 [ 2912.373470] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded [ 2912.373536] ACPI: PCI Interrupt :02:07.0[A] - GSI 19 (level, low) - IRQ 17 [ 2912.373601] cx88[0]: subsystem: 18ac:d530, board: DVICO HDTV5 PCI Nano [card=59,autodetected] [ 2912.373607] cx88[0]: TV tuner type 71, Radio tuner type -1 [ 2912.555088] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw The above message were generated by cx88-cards. So, as I said before, this were called _before_ running dvb_register, defined at cx88-dvb. The issue is simple: the i2c gate code were wrong. So, xc3028 is not visible on that point of the code. With this, analog support will never work. The proper fix is to enable xc3028 before enabling i2c, meaning to correct the code at cx88_pci_nano_init(). After re-visiting s5h1409 code, I noticed that I've used the wrong sequence for the gate. The state should be i2c closed, for xc3028 to work. The following patch should fix: http://linuxtv.org/hg/~mchehab/cx88-xc2028/rev/871db4e0451c Please test it, with i2c_scan=1, and post the results. Doesn't work. [ 795.056020] Linux video capture interface: v2.00 [ 798.235564] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded [ 798.235643] ACPI: PCI Interrupt :02:07.0[A] - GSI 19 (level, low) - IRQ 18 [ 798.235718] cx88[0]: subsystem: 18ac:d530, board: DVICO HDTV5 PCI Nano [card=59,autodetected] [ 798.235722] cx88[0]: TV tuner type 71, Radio tuner type -1 [ 798.371224] cx88[0]: i2c scan: found device @ 0x32 [???] [ 798.371391] cx88[0]: i2c scan: found device @ 0x34 [???] [ 798.399887] cx88[0]: i2c scan: found device @ 0xa0 [eeprom] [ 798.400319] cx88[0]: i2c scan: found device @ 0xa2 [???] [ 798.400482] cx88[0]: i2c scan: found device @ 0xa4 [???] [ 798.400642] cx88[0]: i2c scan: found device @ 0xa6 [???] [ 798.400800] cx88[0]: i2c scan: found device @ 0xa8 [???] [ 798.400957] cx88[0]: i2c scan: found device @ 0xaa [???] [ 798.401116] cx88[0]: i2c scan: found device @ 0xac [???] [ 798.401272] cx88[0]: i2c scan: found device @ 0xae [???] [ 798.411996] cx88[0]: i2c scan: found device @ 0xd6 [???] [ 798.488821] Closing s5h1409 i2c gate to allow xc3028 detection [ 798.489283] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw [ 798.489301] cx88[0]/0: found at :02:07.0, rev: 5, irq: 18, latency: 64, mmio: 0xe400 [ 798.489376] cx88[0]/0: registered device video0 [v4l2] [ 798.489408] cx88[0]/0: registered device vbi0 [ 818.236239] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded [ 818.236443] cx88[0]/2: cx2388x 8802 Driver Manager [ 818.236465] ACPI: PCI Interrupt :02:07.2[A] - GSI 19 (level, low) - IRQ 18 [ 818.236480] cx88[0]/2: found at :02:07.2, rev: 5, irq: 18, latency: 64, mmio: 0xe600 [ 818.254906] cx88/2: cx2388x dvb driver version 0.0.6 loaded [ 818.254913] cx88/2: registering cx8802 driver, type: dvb access: shared [ 818.254918] cx88[0]/2: subsystem: 18ac:d530, board
Re: [linux-dvb] [EXPERIMENTAL] cx88+xc3028 - tests are required - was: Re: Wh en xc3028/xc2028 will be supported?
Michael Krufky wrote: Mauro Carvalho Chehab wrote: On Thu, 21 Feb 2008 20:38:09 -0500 Michael Krufky [EMAIL PROTECTED] wrote: Mauro Carvalho Chehab wrote: It is not that simple. Steven patch works for DTV on PCI Nano; Christopher patches for some other DiVCO boards (DTV also); my port of Markus patch for other boards (tested by Dâniel Fraga - Analog TV). What does one board have to do with another? Just because these boards all use xceive tuners does not mean that they should be grouped together. No, but we have patches for all of them. Because the user has the ability to load cx8800 without cx88-dvb, and likewise, the user has the ability to load cx88-dvb without cx8800, the attach call must be fully qualified such that the other side of the driver is not required to be loaded in order for the tuner to work. If you take a look at the code, you'll see that all code is at cx88xx. This module is loaded by cx8800, if you're using analog, or by cx8802, if you're using cx88-dvb or cx88-blackbird. The code initializes xc3028 before tuner attach. In the case of FusionHDTV5 pci nano, there will never be an attach call from the analog side of the driver, since the tuner is hidden behind the s5h1409's i2c gate, and analog mode is not supported with the current driver. If you set i2c_scan=1 on the PCI nano, the xceive tuner will not even show up in the scan. The proper fix is to open the i2c gate before loading tuner. This will allow i2c_scan to work and both analog and digital modes will work. Btw, this somewhat similar to what dvico_fusionhdtv_hybrid_init() does on cx88-cards. I've added a patch that should open the bridge for s5h1409. Please test. Mauro, It does not work. See my prior email in this thread for the explanation. [ 2912.355967] Linux video capture interface: v2.00 [ 2912.373470] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded [ 2912.373536] ACPI: PCI Interrupt :02:07.0[A] - GSI 19 (level, low) - IRQ 17 [ 2912.373601] cx88[0]: subsystem: 18ac:d530, board: DVICO HDTV5 PCI Nano [card=59,autodetected] [ 2912.373607] cx88[0]: TV tuner type 71, Radio tuner type -1 [ 2912.555088] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw The above message were generated by cx88-cards. So, as I said before, this were called _before_ running dvb_register, defined at cx88-dvb. The issue is simple: the i2c gate code were wrong. So, xc3028 is not visible on that point of the code. With this, analog support will never work. The proper fix is to enable xc3028 before enabling i2c, meaning to correct the code at cx88_pci_nano_init(). After re-visiting s5h1409 code, I noticed that I've used the wrong sequence for the gate. The state should be i2c closed, for xc3028 to work. The following patch should fix: http://linuxtv.org/hg/~mchehab/cx88-xc2028/rev/871db4e0451c Please test it, with i2c_scan=1, and post the results. Doesn't work. [ 795.056020] Linux video capture interface: v2.00 [ 798.235564] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded [ 798.235643] ACPI: PCI Interrupt :02:07.0[A] - GSI 19 (level, low) - IRQ 18 [ 798.235718] cx88[0]: subsystem: 18ac:d530, board: DVICO HDTV5 PCI Nano [card=59,autodetected] [ 798.235722] cx88[0]: TV tuner type 71, Radio tuner type -1 [ 798.371224] cx88[0]: i2c scan: found device @ 0x32 [???] [ 798.371391] cx88[0]: i2c scan: found device @ 0x34 [???] [ 798.399887] cx88[0]: i2c scan: found device @ 0xa0 [eeprom] [ 798.400319] cx88[0]: i2c scan: found device @ 0xa2 [???] [ 798.400482] cx88[0]: i2c scan: found device @ 0xa4 [???] [ 798.400642] cx88[0]: i2c scan: found device @ 0xa6 [???] [ 798.400800] cx88[0]: i2c scan: found device @ 0xa8 [???] [ 798.400957] cx88[0]: i2c scan: found device @ 0xaa [???] [ 798.401116] cx88[0]: i2c scan: found device @ 0xac [???] [ 798.401272] cx88[0]: i2c scan: found device @ 0xae [???] [ 798.411996] cx88[0]: i2c scan: found device @ 0xd6 [???] [ 798.488821] Closing s5h1409 i2c gate to allow xc3028 detection [ 798.489283] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw [ 798.489301] cx88[0]/0: found at :02:07.0, rev: 5, irq: 18, latency: 64, mmio: 0xe400 [ 798.489376] cx88[0]/0: registered device video0 [v4l2] [ 798.489408] cx88[0]/0: registered device vbi0 [ 818.236239] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded [ 818.236443] cx88[0]/2: cx2388x 8802 Driver Manager [ 818.236465] ACPI: PCI Interrupt :02:07.2[A] - GSI 19 (level, low) - IRQ 18 [ 818.236480] cx88[0]/2: found at :02:07.2, rev: 5, irq: 18, latency: 64, mmio
Re: [linux-dvb] [EXPERIMENTAL] cx88+xc3028 - tests are required - was: Re: Wh en xc3028/xc2028 will be supported?
Mauro Carvalho Chehab wrote: It is not that simple. Steven patch works for DTV on PCI Nano; Christopher patches for some other DiVCO boards (DTV also); my port of Markus patch for other boards (tested by Dâniel Fraga - Analog TV). What does one board have to do with another? Just because these boards all use xceive tuners does not mean that they should be grouped together. No, but we have patches for all of them. Because the user has the ability to load cx8800 without cx88-dvb, and likewise, the user has the ability to load cx88-dvb without cx8800, the attach call must be fully qualified such that the other side of the driver is not required to be loaded in order for the tuner to work. If you take a look at the code, you'll see that all code is at cx88xx. This module is loaded by cx8800, if you're using analog, or by cx8802, if you're using cx88-dvb or cx88-blackbird. The code initializes xc3028 before tuner attach. In the case of FusionHDTV5 pci nano, there will never be an attach call from the analog side of the driver, since the tuner is hidden behind the s5h1409's i2c gate, and analog mode is not supported with the current driver. If you set i2c_scan=1 on the PCI nano, the xceive tuner will not even show up in the scan. The proper fix is to open the i2c gate before loading tuner. This will allow i2c_scan to work and both analog and digital modes will work. Btw, this somewhat similar to what dvico_fusionhdtv_hybrid_init() does on cx88-cards. I've added a patch that should open the bridge for s5h1409. Please test. Mauro, It does not work. See my prior email in this thread for the explanation. [ 2912.355967] Linux video capture interface: v2.00 [ 2912.373470] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded [ 2912.373536] ACPI: PCI Interrupt :02:07.0[A] - GSI 19 (level, low) - IRQ 17 [ 2912.373601] cx88[0]: subsystem: 18ac:d530, board: DVICO HDTV5 PCI Nano [card=59,autodetected] [ 2912.373607] cx88[0]: TV tuner type 71, Radio tuner type -1 [ 2912.555088] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw [ 2912.555111] cx88[0]/0: found at :02:07.0, rev: 5, irq: 17, latency: 64, mmio: 0xe400 [ 2912.555184] cx88[0]/0: registered device video0 [v4l2] [ 2912.555215] cx88[0]/0: registered device vbi0 [ 2936.013682] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded [ 2936.013886] cx88[0]/2: cx2388x 8802 Driver Manager [ 2936.013910] ACPI: PCI Interrupt :02:07.2[A] - GSI 19 (level, low) - IRQ 17 [ 2936.013924] cx88[0]/2: found at :02:07.2, rev: 5, irq: 17, latency: 64, mmio: 0xe600 [ 2936.051716] cx88/2: cx2388x dvb driver version 0.0.6 loaded [ 2936.051725] cx88/2: registering cx8802 driver, type: dvb access: shared [ 2936.051733] cx88[0]/2: subsystem: 18ac:d530, board: DVICO HDTV5 PCI Nano [card=59] [ 2936.051737] cx88[0]/2: cx2388x based DVB/ATSC card [ 2936.094831] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [ 2936.094837] cx88[0]/2: xc3028 attached [ 2936.095819] DVB: registering new adapter (cx88[0]) [ 2936.095825] DVB: registering frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)... [ 2943.273085] xc2028 1-0061: xc2028/3028 firmware name not set! [ 2944.378510] xc2028 1-0061: xc2028/3028 firmware name not set! [ 2945.483933] xc2028 1-0061: xc2028/3028 firmware name not set! [ 2946.589366] xc2028 1-0061: xc2028/3028 firmware name not set! [ 2946.594186] xc2028 1-0061: Error on line 1068: -121 [ 2948.664531] xc2028 1-0061: xc2028/3028 firmware name not set! [ 2949.765979] xc2028 1-0061: xc2028/3028 firmware name not set! [ 2950.867404] xc2028 1-0061: xc2028/3028 firmware name not set! [ 2951.968841] xc2028 1-0061: xc2028/3028 firmware name not set! [ 2953.070277] xc2028 1-0061: xc2028/3028 firmware name not set! [ 2954.171711] xc2028 1-0061: xc2028/3028 firmware name not set! [ 2955.273151] xc2028 1-0061: xc2028/3028 firmware name not set! [ 2956.374804] xc2028 1-0061: xc2028/3028 firmware name not set! [ 2957.476020] xc2028 1-0061: xc2028/3028 firmware name not set! [ 2958.473772] xc2028 1-0061: Error on line 1068: -121 -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [EXPERIMENTAL] cx88+xc3028 - tests are required - was: Re: When xc3028/xc2028 will be supported?
On Jan 29, 2008 9:25 AM, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: Dâniel and others, Having this tested is a very good news! I'll need to merge this patch with two other patches that adds DVB support for cx88/xc3028. If I can manage to have some time for this merge, I'll commit and ask Linus to add this to 2.6.25. :) I've merged some patches from several authors, that add xc3028 support for cx88. The experimental tree is available at: http://linuxtv.org/hg/~mchehab/cx88-xc2028 This patch series adds support for the following boards: 59 - DVICO HDTV5 PCI Nano[18ac:d530] 60 - Pinnacle Hybrid PCTV[12ab:1788] 61 - Winfast TV2000 XP Global[107d:6f18] 62 - PowerColor Real Angel 330 [14f1:ea3d] 63 - Geniatech X8000-MT DVBT [14f1:8852] 64 - DViCO FusionHDTV DVB-T PRO [18ac:db30] In thesis, both analog and DVB support (for boards with DVB/ATSC) should be working (*). Maybe analog audio may need an additional configuration for some specific board (since they may require to add cfg.mts = 1 at xc3028 initialization code, on cx88-cards). Please test. Mauro, We spoke on Thursday, and you asked me to take a look at the code in your 'cx88-xc2028' tree over the weekend and fix it, if possible. The repository is broken after and including changeset ce6afd207b71 - Make xc3028 support more generic This changeset moves the device-specific configuration out of the cx88-dvb.c device-specific switch..case block, into a generic function. This patch breaks functionality, and imho, is not a good idea. Your changes assume that the analog side of the driver will come up before the digital side of the driver, which is not necessarily the case. Additionally, in some cases, the tuner itself is hidden behind an i2c gate that is controlled by the dvb / atsc demodulator. Because of the i2c gate, communication to the tuner might not be available at the time that the i2c bus is probed. For those reasons, the attach calls to the tuner driver should be fully qualified, relative to the functionality of the side of the driver that is attaching it. The device that I used to test is the FusionHDTV 5 PCI nano. This device uses an xc3008 (yes, that is xc3008 -- not a typo) and a s5h1409 demod. The device is capable of receiving ATSC digital broadcasts and the driver does not yet support analog television. Steve Toth made the patch that adds atsc support for that card, and his patch worked without the additional changesets that were added afterwards. I made some small fixes and enabled IR support -- see the bottom of this email for my pull request. Your email above states that you've merged some patches from several authors. What I recommend, in order to properly support each device, would be to apply each patch for each card separately, as we do with all card support additions. We know that the original patches, as submitted by the original authors work properly , since those authors have conducted their own tests. I understand that you've made some attempts to optimize the code in an effort to reduce memory consumption. Unfortunately, these efforts have broken functionality of these devices. I think that it would make more sense to work on optimizations after the basic device support patches are first applied in the standard manner. This way, you would have a good point of reference for before and after that testers will be able to use for comparison (and bisection). Since the only card that I can test is the PCI nano, please pull these changesets into master for now. Please pull from: http://linuxtv.org/hg/~mkrufky/cx88-xc2028 for: (91113b8955e2) 4 weeks ago Steven Toth cx88: Add support for the Dvico PCI Nano. (394d249f03f1) 47 hours ago Michael Krufky cx88: fix FusionHDTV 5 PCI nano name and enable IR support Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [OT] request_firmware()
On Thu, Feb 14, 2008 at 3:37 PM, Thomas Kaiser [EMAIL PROTECTED] wrote: Hello I know this is the wrong list to ask, but you use this function (see subject) and I think somebody can answer my question. Why does request_firmware need a device as parameter? int request_firmware(const struct firmware **fw, const char *name, struct device *device); I thought request_firmware just loads the firmware in the struct firmware? IIRC, when the device is destroyed, it is a signal for the memory used to store the firmware to be freed if not done already. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] XC3028 in HVR-950 but no DVB-T?
optix optix wrote: I'm haveing a hard time choosing a TV solution for my laptop. It supports USB 2.0 and has an Expresscard slot. I run Ubuntu feisty and quite willing to play around a bit to get things to work. But i'm not really up for writing my own drivers or anything too hardcore like that. I've been looking for a global analog and global HDTV hybrid tuners. that is it should support NTSC, PAL, DVD-T, ATSC and if possible FM, DVB-C and QAM. I noticed Xceive's XC3028(L) does pretty much all of this and more. From what i can tell it's in various tuners i could use. for example the HVR-950. however officially (according the hauppage site) this tuner doesn't support DVB-T for example. is that true? i mean if i were to setup the right drivers in linux can i watch DVB-T when in europe or is there really some extra hardware missing? more generally what suggestions do people have as to which tuner i should get which fit's the requirments i mentioned above? The demodulator inside of the HVr950 device that you're talking about is the LG DT3303 -- it does not demodulate DVB-T, and is meant for use with North American ATSC/QAM. There are the HVR900 sticks that use a zl10353 (or other demods for different models) -- this rev is targeted at DVB-T, and does not work with ATSC. There aren't many devices out there yet that can demodulate digital television signals from all around the world -- you need to get one specific to your locale. Analog television is different, however. Something like the HVR950 *can* receive analog broadcasts in almost any analog video standard. I hope this helps, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Pinnacle 800i driver problems
2008/1/24 Muppet Man [EMAIL PROTECTED]: - Original Message From: Steven Toth [EMAIL PROTECTED] Did you _really_ read the output from the extract script, which says something like... Now copy this file into your firmware folder. EG. sudo cp firmware.fw /lib/firmware/`uname -r/' Are you _SURE_ you read the output from the extract script? Steve, There was no output from the script. I ran the script, a white screen popped up for less than a second, and then it went back to my desktop. I think that is where my confusion is coming in at. Ed For future reference, next time you try to run a shell script, run it from a shell. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Dvico's new generation of ATSC/QAM cards. Drivers needed.
Ralph LoBianco wrote: I have a few FusionHDTV7 Gold cards that I can offer at a discounted price to anyone that's interested in developing drivers. Contact me if you're interested. If you give me one for _free_ , then I'll add support for it. Email me privately for mailing address. -Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Pinnacle 800i driver analog audio issues
2008/1/21 Timothy E. Krantz [EMAIL PROTECTED]: After compiling the latest Pinnacle 800i driver from the tree I have the following : cx88_alsa: disagrees about version of symbol [foo] cx88_alsa: Unknown symbol [foo] this is after doing make make unload make install make load I have removed 'make load' from the repo howto -- this should not be used. 'make unload' is very good for unloading the all modules, but to load them, you should manually modprobe the driver that you need, by name. ...and Chaogui is correct -- rebooting your system should fix your problem. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Pinnacle 800i driver analog audio issues
On Jan 21, 2008 11:14 AM, Timothy E. Krantz [EMAIL PROTECTED] wrote: After compiling the latest Pinnacle 800i driver from the tree I have the following : cx88_alsa: disagrees about version of symbol snd_ctl_add cx88_alsa: Unknown symbol snd_ctl_add cx88_alsa: disagrees about version of symbol snd_pcm_new cx88_alsa: Unknown symbol snd_pcm_new cx88_alsa: disagrees about version of symbol snd_card_register cx88_alsa: Unknown symbol snd_card_register cx88_alsa: disagrees about version of symbol snd_card_free cx88_alsa: Unknown symbol snd_card_free cx88_alsa: disagrees about version of symbol snd_ctl_new1 cx88_alsa: Unknown symbol snd_ctl_new1 cx88_alsa: disagrees about version of symbol snd_card_new cx88_alsa: Unknown symbol snd_card_new cx88_alsa: disagrees about version of symbol snd_pcm_lib_ioctl cx88_alsa: Unknown symbol snd_pcm_lib_ioctl cx88_alsa: disagrees about version of symbol snd_pcm_hw_constraint_pow2 cx88_alsa: Unknown symbol snd_pcm_hw_constraint_pow2 cx88_alsa: disagrees about version of symbol snd_pcm_set_ops cx88_alsa: Unknown symbol snd_pcm_set_ops cx88_alsa: disagrees about version of symbol snd_pcm_period_elapsed cx88_alsa: Unknown symbol snd_pcm_period_elapsed this is after doing make make unload make install make load I suspect a reboot should solve the problem for you if you haven't tried that. Same thing after a reboot. But thanks! Did you install an alsa update? The v4l-dvb repository expects the ALSA drivers to be the same as what is found in your kernel version -- if you updated them yourself, or installed a newer alsa package, that would explain your symbol version conflicts. You don't need cx88-alsa to work anyway, unless you plan to use analog video and pass the audio over DMA. Digital TV works without it. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] allow dvb-usb firmware loading in warm state?
On Jan 21, 2008 3:19 PM, Ivor Hewitt [EMAIL PROTECTED] wrote:
Hi,
I was having (still am! :) trouble with my nova-t 500 card and I wanted
a way to be able try a different firmware... but the current code only
loads in a cold state... and my mythbackend is pretty inaccessible, so
I made the attached change. This allows a module parameter of
force_load_firmware which causes the cold state logic to be used
when warm. Thought this might be a useful idea, it was handy for me anyway.
Cheers,
Ivor
-- snip --
/* DIB7070 generic */
diff -r 7564c110491e linux/drivers/media/dvb/dvb-usb/dvb-usb-init.c
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-init.cSun Jan 20
09:13:44 2008 -0200
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-init.cMon Jan 21
11:55:20 2008 +
@@ -25,6 +25,10 @@ static int dvb_usb_force_pid_filter_usag
static int dvb_usb_force_pid_filter_usage;
module_param_named(force_pid_filter_usage,
dvb_usb_force_pid_filter_usage, int, 0444);
MODULE_PARM_DESC(force_pid_filter_usage, force all dvb-usb-devices to
use a PID filter, if any (default: 0).);
+
+int dvb_usb_force_firmware;
+module_param_named(force_load_firmware, dvb_usb_force_firmware, int, 0444);
+MODULE_PARM_DESC(force_load_firmware, force firmware loading even when
in warm state.);
static int dvb_usb_adapter_init(struct dvb_usb_device *d)
{
@@ -230,7 +234,7 @@ int dvb_usb_device_init(struct usb_inter
return -ENODEV;
}
- if (cold) {
+ if (cold||dvb_usb_force_firmware) {
info(found a '%s' in cold state, will try to load a
firmware,desc-name);
ret = dvb_usb_download_firmware(udev,props);
if (!props-no_reconnect || ret != 0)
Doesn't this cause an endless loop? How does the driver know when to
stop uploading firmware?
-Mike
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Pinnacle 800i - obsolete tuner i2c address?
Tim, In the future, please don't dropp cc from the mailing list. Steve, Chaogui's patch fixed Tim's XC5000 initialization problem -- we should merge it if all is well with it. Please see below. -Mike Timothy E. Krantz wrote: John, Sorry for sending this twice -- I sent it the first time from an email address not subscribed to linux-dvb :-/ John Massengale wrote: I got the Pinnacle 800i working on Mythbuntu, I can tune both analog and digital channels, but if I reboot, for some reason it starts having problems. Thanks for sending in the obsolete tuner address message -- I'll remove this warning for the XC5000 tuners. Unfortunately, I don't know why your tuner isn't working after a reboot... Perhaps the device gets held in reset after a reboot, and it isn't properly being taken out as needed? Try the patch in this email and let us know if that fixes the problem: http://linuxtv.org/pipermail/linux-dvb/2008-January/022977.html Regards, Mike That patch resolved the problem for me. Tim ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Pinnacle 800i - obsolete tuner i2c address?
John, Sorry for sending this twice -- I sent it the first time from an email address not subscribed to linux-dvb :-/ John Massengale wrote: I got the Pinnacle 800i working on Mythbuntu, I can tune both analog and digital channels, but if I reboot, for some reason it starts having problems. Thanks for sending in the obsolete tuner address message -- I'll remove this warning for the XC5000 tuners. Unfortunately, I don't know why your tuner isn't working after a reboot... Perhaps the device gets held in reset after a reboot, and it isn't properly being taken out as needed? Try the patch in this email and let us know if that fixes the problem: http://linuxtv.org/pipermail/linux-dvb/2008-January/022977.html Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DViCO FusionHDTV5 Express and cx23885 support
On Jan 17, 2008 12:15 PM, [EMAIL PROTECTED] wrote: Andrew Casper wrote: On Jan 16, 2008, at 8:54 PM, Michael Krufky wrote: Andrew Casper wrote: No cx23885.ko is made - just links to the src files. And I did a make install. - Andrew Mike - You'd think that would work, but no. And it that killed my other two tuner card (an hd3000 and an hd5500). And no Fusion Card in sight. Ah, I misread your previous response, No cx23885.ko is made - just links to the src files. And I did a make install. I had misinterpreted this as No [not so --], cx23885.ko is made [and there are] links to the src files. I am seeing an issue now in the master branch that the build system of a fresh clone does select all drivers to build, but VIDEO drivers don't actually get built. (cc added to mauro) This is consistent with what you are seeing -- neither cx88 nor cx23885 is being built for you, so you've lost all your cards. I don't know what's wrong, but now I cant work on any drivers until this issue is resolved. Why dont VIDEO drivers build anymore, even if they are correctly selected via Kconfig? -Mike Andrew, I don't know exactly what is CAUSING this problem, and I dont have time to debug this right now (hopefully Mauro will) ... but a workaround to the issue that I am seeing, to enable build of the VIDEO drivers, i must enter menuconfig, and then disable RADIO. After doing so, I get the full tree to build again. Can you give this a try and let us know what happens on your end? Good Luck, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DViCO FusionHDTV5 Express and cx23885 support
On Jan 17, 2008 12:34 PM, Michael Krufky [EMAIL PROTECTED] wrote: On Jan 17, 2008 12:15 PM, [EMAIL PROTECTED] wrote: Andrew Casper wrote: On Jan 16, 2008, at 8:54 PM, Michael Krufky wrote: Andrew Casper wrote: No cx23885.ko is made - just links to the src files. And I did a make install. - Andrew Mike - You'd think that would work, but no. And it that killed my other two tuner card (an hd3000 and an hd5500). And no Fusion Card in sight. Ah, I misread your previous response, No cx23885.ko is made - just links to the src files. And I did a make install. I had misinterpreted this as No [not so --], cx23885.ko is made [and there are] links to the src files. I am seeing an issue now in the master branch that the build system of a fresh clone does select all drivers to build, but VIDEO drivers don't actually get built. (cc added to mauro) This is consistent with what you are seeing -- neither cx88 nor cx23885 is being built for you, so you've lost all your cards. I don't know what's wrong, but now I cant work on any drivers until this issue is resolved. Why dont VIDEO drivers build anymore, even if they are correctly selected via Kconfig? -Mike Andrew, I don't know exactly what is CAUSING this problem, and I dont have time to debug this right now (hopefully Mauro will) ... but a workaround to the issue that I am seeing, to enable build of the VIDEO drivers, i must enter menuconfig, and then disable RADIO. After doing so, I get the full tree to build again. Can you give this a try and let us know what happens on your end? Good Luck, Mike _very_ interesting... Looks like if I have CONFIG_USB_SI470X enabled, then video drivers fail to get built... but if I disable CONFIG_USB_SI470X, then all is well. ...strange... Somebody want to try to make some sense of this? -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DViCO FusionHDTV5 Express and cx23885 support
On Jan 17, 2008 12:52 PM, Michael Krufky [EMAIL PROTECTED] wrote: On Jan 17, 2008 12:34 PM, Michael Krufky [EMAIL PROTECTED] wrote: On Jan 17, 2008 12:15 PM, [EMAIL PROTECTED] wrote: Andrew Casper wrote: On Jan 16, 2008, at 8:54 PM, Michael Krufky wrote: Andrew Casper wrote: No cx23885.ko is made - just links to the src files. And I did a make install. - Andrew Mike - You'd think that would work, but no. And it that killed my other two tuner card (an hd3000 and an hd5500). And no Fusion Card in sight. Ah, I misread your previous response, No cx23885.ko is made - just links to the src files. And I did a make install. I had misinterpreted this as No [not so --], cx23885.ko is made [and there are] links to the src files. I am seeing an issue now in the master branch that the build system of a fresh clone does select all drivers to build, but VIDEO drivers don't actually get built. (cc added to mauro) This is consistent with what you are seeing -- neither cx88 nor cx23885 is being built for you, so you've lost all your cards. I don't know what's wrong, but now I cant work on any drivers until this issue is resolved. Why dont VIDEO drivers build anymore, even if they are correctly selected via Kconfig? -Mike Andrew, I don't know exactly what is CAUSING this problem, and I dont have time to debug this right now (hopefully Mauro will) ... but a workaround to the issue that I am seeing, to enable build of the VIDEO drivers, i must enter menuconfig, and then disable RADIO. After doing so, I get the full tree to build again. Can you give this a try and let us know what happens on your end? Good Luck, Mike _very_ interesting... Looks like if I have CONFIG_USB_SI470X enabled, then video drivers fail to get built... but if I disable CONFIG_USB_SI470X, then all is well. ...strange... Somebody want to try to make some sense of this? -Mike :-D I found and fixed the problem: # HG changeset patch # User Michael Krufky [EMAIL PROTECTED] # Date 1200592493 18000 # Node ID db9cd7224d965366c12515a17c2f64de7ae7c65c # Parent 7d364b375fb7d2d502aa0767910b3f6cb219ff4c fix broken build when CONFIG_USB_SI470X is set From: Michael Krufky [EMAIL PROTECTED] Signed-off-by: Michael Krufky [EMAIL PROTECTED] --- a/linux/drivers/media/radio/MakefileTue Jan 15 15:42:12 2008 -0200 +++ b/linux/drivers/media/radio/MakefileThu Jan 17 12:54:53 2008 -0500 @@ -21,6 +21,6 @@ obj-$(CONFIG_RADIO_TRUST) += radio-trust obj-$(CONFIG_RADIO_TRUST) += radio-trust.o obj-$(CONFIG_RADIO_MAESTRO) += radio-maestro.o obj-$(CONFIG_USB_DSBR) += dsbr100.o -obj-$(CONFIG_USB_SI470X) := radio-si470x.o +obj-$(CONFIG_USB_SI470X) += radio-si470x.o EXTRA_CFLAGS += -Isound I pushed the fix to http://linuxtv.org/hg/~mkrufky/build-fix/ Please pull from that tree -- it will fix the problem for you... Thanks for reporting this. Cheers, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Compiling the latest hg
James, On Jan 17, 2008 3:26 PM, James Klaas [EMAIL PROTECTED] wrote: After getting all excited about the new driver for the Pinnacle PCTV HD 800i and the Silicon Labs FM radio tuner, I decided to grab the latest pull from hg to rebuild a module for my DViCO FusionHDTV 3 Gold-T. However, when I went to make the tree, it didn't seem to build all of the modules, espcecially the one I was interested in, the cx88 stuff. I also got a lot of WARNING: ... undefined! messages. I'm runnning the Ubuntu 2.6.22 kernel source. Do I need to have a more current kernel? The master repository is broken. Please see the email that I sent a few hours ago for the explanation and fix... http://linuxtv.org/pipermail/linux-dvb/2008-January/022992.html Regards, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DViCO FusionHDTV5 Express and cx23885 support
Andrew Casper wrote: (please excuse the me if this has already been asked and answer, but I'm new to the list and I did not find an answer in the message archives) I just got a new DViCO FusionHDTV5 Express - primarily based on reading that it was supported on the wiki. I have downloaded the latest tree. But when I compile the source, it doesn't make the kernel modules for cx23885 (which is the module I believe I need). What am I missing here? I'm using Fedora 8 (kernel 2.6.23.9-85). Did you update from an older tree or pull down a fresh clone? It JustWorks (tm) -- if not, maybe some dependency is screwing you up.. from the v4l-dvb tree, what does the following show you: grep 23885 v4l/.*config (no, this is NOT a typo) If VIDEO_CX23885 isnt selected, then go select it in menuconfig. You'll find it under the video section, as CX23885 - cx2388x successor. HTH, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DViCO FusionHDTV5 Express and cx23885 support
Andrew Casper wrote: On Jan 16, 2008, at 8:05 PM, Michael Krufky wrote: Andrew Casper wrote: (please excuse the me if this has already been asked and answer, but I'm new to the list and I did not find an answer in the message archives) I just got a new DViCO FusionHDTV5 Express - primarily based on reading that it was supported on the wiki. I have downloaded the latest tree. But when I compile the source, it doesn't make the kernel modules for cx23885 (which is the module I believe I need). What am I missing here? I'm using Fedora 8 (kernel 2.6.23.9-85). Did you update from an older tree or pull down a fresh clone? It JustWorks (tm) -- if not, maybe some dependency is screwing you up.. from the v4l-dvb tree, what does the following show you: grep 23885 v4l/.*config (no, this is NOT a typo) If VIDEO_CX23885 isnt selected, then go select it in menuconfig. You'll find it under the video section, as CX23885 - cx2388x successor. HTH, Mike Thanks for the speedy reply, Mike. ergh - VIDEO_CX23885 seems to be selected for build: # grep 23885 v4l/.*config v4l/.config:CONFIG_VIDEO_CX23885=m v4l/.myconfig:CONFIG_VIDEO_CX23885 := m I'm building from the public cvs that I pulled last night (and check for an update today). I had the same problem with a tarball I also pulled. mercurial. hg. no cvs. So how do I determine what dependancy is killing me? This is a pretty new build (just installed on Fedora 8 on Saturday) so there isn't too much creft. is there a v4l/cx23885.ko after you build? did you forget to do 'make install' (as root) ? -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DViCO FusionHDTV5 Express and cx23885 support
Andrew Casper wrote: On Jan 16, 2008, at 8:41 PM, Michael Krufky wrote: Andrew Casper wrote: On Jan 16, 2008, at 8:05 PM, Michael Krufky wrote: Andrew Casper wrote: (please excuse the me if this has already been asked and answer, but I'm new to the list and I did not find an answer in the message archives) I just got a new DViCO FusionHDTV5 Express - primarily based on reading that it was supported on the wiki. I have downloaded the latest tree. But when I compile the source, it doesn't make the kernel modules for cx23885 (which is the module I believe I need). What am I missing here? I'm using Fedora 8 (kernel 2.6.23.9-85). Did you update from an older tree or pull down a fresh clone? It JustWorks (tm) -- if not, maybe some dependency is screwing you up.. from the v4l-dvb tree, what does the following show you: grep 23885 v4l/.*config (no, this is NOT a typo) If VIDEO_CX23885 isnt selected, then go select it in menuconfig. You'll find it under the video section, as CX23885 - cx2388x successor. HTH, Mike Thanks for the speedy reply, Mike. ergh - VIDEO_CX23885 seems to be selected for build: # grep 23885 v4l/.*config v4l/.config:CONFIG_VIDEO_CX23885=m v4l/.myconfig:CONFIG_VIDEO_CX23885 := m I'm building from the public cvs that I pulled last night (and check for an update today). I had the same problem with a tarball I also pulled. mercurial. hg. no cvs. So how do I determine what dependancy is killing me? This is a pretty new build (just installed on Fedora 8 on Saturday) so there isn't too much creft. is there a v4l/cx23885.ko after you build? did you forget to do 'make install' (as root) ? -Mike My bad - it was mercurial. No cx23885.ko is made - just links to the src files. And I did a make install. - Andrew Reboot your machine, and enjoy your working driver. In the future, this stuff is documented at: http://linuxtv.org/repo Enjoy. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HVR-1800 checkin
On Jan 14, 2008 8:40 PM, Barry Quiel [EMAIL PROTECTED] wrote: It looks like there was a checkin a few days ago that added some support for the HVR-1800 NTSC tuner. Excuse the stupid question but what is basic preview NTSC support? by basic preview NTSC support, we mean, standard raw framegrabber support -- as opposed to mpeg encoder support, which will be added soon. You can try out the mpeg encoder support by using the tree: http://linuxtv.org/hg/~stoth/cx23885-video/ ...but I warn you -- this is a development repository that hasnt yet been merged into the master repository. If you hit any bugs, please report them. The repository will most probably be deleted when it gets merged into master. Good Luck, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Tuner drifts out of lock after tzap is exited
On Jan 2, 2008 12:14 PM, Roger James [EMAIL PROTECTED] wrote: If have been struggling for a couple of days trying to get decent NIT dumps off a local multiplex. Using tzap to tune a channel, exiting tzap and then running dvbsnoop, it seemed very variable whether I found the table before timing out. I noticed I had more success I kept retuning the frontend using tzap before each dvbsnoop run. But even then it would quite often produce nothing. I knew the driver and rf side setup was good because mtyhtv was using all the devices and multiplexes successfully. On checking the kernel logs I found I was getting a lot of cx8802_timeout messages on unsuccessful runs. So I tried a test running tzap, waiting till the frontend had lock, then exiting tzap and running femon. As I suspected, after a few seconds femon reported that the frontend had lost lock. So I a tried the dvbsnoop test with tzap left running in another session. Result, everything worked perfectly. Exactly as expected. I am running debian stable with a 2.5.19.2 kernel. Is this expected behaviour? Can anyone explain to me what is happening? Yes. The moment tzap is stopped, tuning ceases. Also, if you don't specify -r to tzap, you'll get nothing from the dvr device. In the past I had always assumed that could exit tzap after you had tuned a channel and the fe would stay locked as long as signal remained good. Nope. Always keep tzap running when performing this type of testing. Also, you sent this email to the video4linux mailing list, which only deals with analog video. cc added to linux-dvb, which is more appropriate for this topic. I hope this helps. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] AverTV Hybrid Volar HX
Steven Toth wrote: Michael Krufky wrote: Manu Abraham wrote: This device might be supported soon. Other than that, I guess the TDA18271 driver doesn't support DVB-T as of now. Actually, I have heard reports from some people that they have gotten the tda18271 to work for DVB-T in their tests. I haven't been able to successfully test that yet myself, but I welcome patches if there are any problems with the driver. Mike, Is their something Hauppauge can do to help with this? No. If there are no bug reports, then there are no bugs to be fixed. (do you like the satire?) If someone REPORTS a bug, then we can look at the problem. Let me re-phrase -- Hauppauge can help, if interested, by finding somebody to write a GPL'd driver for a DVB-T demod found on a board that also uses the tda18271 -- after that, I'll be able to test DVB-T. Until now, AFAIK, the tda18271 module works in all analog modes, ATSC / QAM, and has only been tested for use with DVB-T (and DMB-T) in a closed circuit. There are a few obvious places that need adjusting to improve the tuning quality -- I am working on improving the tuning algorithm and rf tracking filter calibration scheme. If there is any bug anywhere preventing DVB-T from working, it would be related to the std bits / IF (all found in tda18271_set_params). I believe that there may be some device-specific configuration that I've been thinking of moving into an attach-time parameter, but until I see a need for it ( bug reports ? ) I'll leave it as-is. I have not spend much time with DVB-T support on this tuner, since I don't have any devices with all known supported hardware except for the new tuner. If there were drivers available for newer demods that are usually found with this tuner on DVB-T boards, then maybe I'd have an easier time testing it. Right now, I am working on adding support for the C2 revision of this device. I already have digital mode working, tested with QAM256 so far, and I have a rock-solid signal. Analog works too, but it's really just limping for now. I have not pushed up the c2 support yet -- my tda18271c2 tree is just a staging area, and still only supports the c1 tuner. If the mystery vendor X has a C2 tuner, it _will_not_ work with the driver in my public repository. I will not merge in C2 support until after I clean up my patches here in my local sandbox, unless anybody out there is specifically interested in testing it... If so, send me an email and I'll push up today's snapshot to a test repository. Even still, I'd rather clean it up first -- should just take a few more hours of work. Manu Abraham wrote: Some of the vendors (more than one) wrote to me that the TDA18271 driver doesn't work. That was the basis of my statement. Silly vendors. Why write to _you_ about somebody else's work? If they are interested in participating in the open source community, they should file their own bug reports, and be sure that they are received by the author of said driver. -Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] AverTV Hybrid Volar HX
Manu Abraham wrote: Michael Krufky wrote: Manu Abraham wrote: Some of the vendors (more than one) wrote to me that the TDA18271 driver doesn't work. That was the basis of my statement. Silly vendors. Why write to _you_ about somebody else's work? One of the vendors cc'd me, since they did ask you and had no response from you They asked me to work on a driver from ground up or fix your driver, since you told them that you had no time. I hope some ghost didn't write the inlined mail. [quoted mail snipped] Manu, I'd appreciate it if you would NOT post private email threads to a public mailing list. (haven't we gone down this road before?) Max got the tda18271 driver working on his device -- a typo was identified that had prevented DVB-T / DMB-T tuning from working. The fix has already been applied to the master repository: # HG changeset patch # User Michael Krufky mkrufky at linuxtv dot org # Date 1198258126 18000 # Node ID 4a790ca9ee23434a466ea9003910138ed6d30165 # Parent b9f149a476dd82c2098e4864179c3765c0bb7b70 tda18271: fix typo in RF tracking filter calibration From: Michael Krufky mkrufky at linuxtv dot org We want to set bits 1 2 on easy programming byte 4, not extended byte 4. Thanks to David Wong for pointing this out. Cc: David Wong davidtlwong at gmail dot com Signed-off-by: Michael Krufky mkrufky at linuxtv dot org --- a/linux/drivers/media/dvb/frontends/tda18271-fe.c Tue Dec 18 08:42:33 2007 -0500 +++ b/linux/drivers/media/dvb/frontends/tda18271-fe.c Fri Dec 21 12:28:46 2007 -0500 @@ -414,7 +414,7 @@ static int tda18271_tune(struct dvb_fron tda18271_write_regs(fe, R_EB20, 1); /* set CAL mode to RF tracking filter calibration */ - regs[R_EB4] |= 0x03; + regs[R_EP4] |= 0x03; /* calculate CAL PLL */ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] AverTV Hybrid Volar HX
Zdenek Kabelac wrote: Hello I should start a new thread about this USB2.0 device. I'd like to get this device working - from another thread on this list it looks like it should be possible to achieve. So I'd like to get some information (and eventually some irc help/short introduction) how to make it working. I've tried simply to extend current Aver Volar Dib0700 code :) however except from the fact I get firmware loader somewhere, I'm for this moment lost (well it's been just a wild blind try what will happen ;)) I'll repeat which chips I could find in the USB device - SAA7136E,CY7C68013A,TDA18271HDC1 So how could I connect these pieces together into some usable stage (at least for DVB-T for this moment. Which tree should I select (where all these chips would be supported at the some time - from the first overview it looks like there is way too many different trees. You should base your work off the master branch. The tda18271 driver in that tree should work well enough for you. I don't know anything about the IF within the saa7136 -- I would guess it is something like a tda8290 or tda8295, which may need some work for analog support. For digital tv, you can attach the tda18271 the same way as is done in cx23885-dvb for the hvr1800, with alt_tuner=1. You'll have some work to do to get the saa7136 analog video decoder working as well... I've heard it may be compatible with the saa7134 code, but that driver currently expects to be used as a PCI bridge. Given the CY7C68013A, you probably don't want to touch any of the dib0700 code, although we still don't know what digital demod / channel decoder is used in your device. Are there any other chips inside? Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] AverTV Hybrid Volar HX
Sorry for sending this twice -- I forgot to cc the list last time. Zdenek Kabelac wrote: 2007/12/31, Michael Krufky [EMAIL PROTECTED]: You should base your work off the master branch. The tda18271 driver in that tree should work well enough for you. I don't know anything about the IF within the saa7136 -- I would guess it is something like a tda8290 or tda8295, which may need some work for analog support. For digital tv, you can attach the tda18271 the same way as is done in cx23885-dvb for the hvr1800, with alt_tuner=1. You'll have some work to do to get the saa7136 analog video decoder working as well... I've heard it may be compatible with the saa7134 code, but that driver currently expects to be used as a PCI bridge. Given the CY7C68013A, you probably don't want to touch any of the dib0700 code, although we still don't know what digital demod / channel decoder is used in your device. Are there any other chips inside? Yeah - It's been just a trial if it will do something with my device. Here is the text list of chips I could have identify. AF9013-N1 0732 HKH2Y I believe that this afatech device is what you want to start off working with, for dvb support. Unfortunately, I don't know much about those, but I think there is somebody working on it. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] AverTV Hybrid Volar HX
Manu Abraham wrote: Zdenek Kabelac wrote: 2007/12/31, Michael Krufky [EMAIL PROTECTED]: Zdenek Kabelac wrote: Hello I should start a new thread about this USB2.0 device. I'll repeat which chips I could find in the USB device - SAA7136E,CY7C68013A,TDA18271HDC1 You should base your work off the master branch. The tda18271 driver in that tree should work well enough for you. I don't know anything about the IF within the saa7136 -- I would guess it is something like a tda8290 or tda8295, which may need some work for analog support. For digital tv, you can attach the tda18271 the same way as is done in cx23885-dvb for the hvr1800, with alt_tuner=1. You'll have some work to do to get the saa7136 analog video decoder working as well... I've heard it may be compatible with the saa7134 code, but that driver currently expects to be used as a PCI bridge. Given the CY7C68013A, you probably don't want to touch any of the dib0700 code, although we still don't know what digital demod / channel decoder is used in your device. Are there any other chips inside? Yeah - It's been just a trial if it will do something with my device. This device might be supported soon. Other than that, I guess the TDA18271 driver doesn't support DVB-T as of now. Actually, I have heard reports from some people that they have gotten the tda18271 to work for DVB-T in their tests. I haven't been able to successfully test that yet myself, but I welcome patches if there are any problems with the driver. Regards, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Compiler error in tda18271.h
On Dec 12, 2007 3:11 PM, Andrea [EMAIL PROTECTED] wrote:
One of the last commits has broken this header file.
http://linuxtv.org/hg/v4l-dvb/rev/bbbc4fc359e9
diff -r d9e0f35279d4 linux/drivers/media/dvb/frontends/tda18271.h
--- a/linux/drivers/media/dvb/frontends/tda18271.h Wed Dec 12 00:40:19
2007 -0200
+++ b/linux/drivers/media/dvb/frontends/tda18271.h Wed Dec 12 20:09:20
2007 +
@@ -38,7 +38,7 @@ static inline struct dvb_frontend *tda18
static inline struct dvb_frontend *tda18271_attach(struct dvb_frontend *fe,
u8 addr,
struct i2c_adapter *i2c,
- enum tda18271_i2c_gate
gate);
+ enum tda18271_i2c_gate
gate)
{
printk(KERN_WARNING %s: driver disabled by Kconfig\n, __FUNCTION__);
return NULL;
Oops! Thanks for pointing this out. I'll fix this now :-)
Cheers,
Mike
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hvr1110 not working
Benoit Istin wrote: Hi, There are several months my hvr1110 stop working. This is very simple to fix, for my card revision at least, by setting a missing field to the hauppauge_hvr_1110_config. B.I P.S. This is my first contribution, so please forgive me if I did something wrong Please provide your sign-off, in the form: Signed-off-by: Your Name [EMAIL PROTECTED] ...and then I can have your patch applied to the repository. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Compile error from mercurial pvrusb2-sysfs.c
On Nov 30, 2007 12:15 PM, Mike Isely [EMAIL PROTECTED] wrote: On Fri, 30 Nov 2007, Dave Schile wrote: I tried to compile from mercurial last night (11/29/07) and got this error. Anyone have any ideas? CC [M] /usr/src/v4l-dvb/v4l/pvrusb2-sysfs.o /usr/src/v4l-dvb/v4l/pvrusb2-sysfs.c: In function 'class_dev_create': /usr/src/v4l-dvb/v4l/pvrusb2-sysfs.c:808: error: 'struct device' has no /member named 'class' make[3]: *** [/usr/src/v4l-dvb/v4l/pvrusb2-sysfs.o] Error 1 make[2]: *** [_module_/usr/src/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.17.8-cherry' make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/v4l-dvb/v4l' make: *** [all] Error 2 Thank you, Dave The programmatic method for doing sysfs class entries changed, starting with kernel 2.6.18. The pvrusb2 driver was recently updated to use the new method - because the old method is deprecated and not long for this world. Unfortunately (and not surprisingly) the new method fails to compile for anything older than 2.6.18. Two things you can do now: Turn off CONFIG_VIDEO_PVRUSB2_SYSFS which should disable this feature in the driver and avoid compiling the problematic code. Or build for 2.6.18 or later. Or if you don't care about the pvrusb2 driver at all and are just trying to build the repository, turn off CONFIG_VIDEO_PVRUSB2. This needs a real fix in v4l-dvb or it must at least be made harmless. I had initially ruled out a pile of ifdef's because (1) there will be quite a few, and (2) it's only going to get worse because the new method also allows for additional cleanups in this module and doing those cleanups while still retaining the old method for backwards compatibility is going to get really grim. Probably a better solution for now is just to automatically kill CONFIG_VIDEO_PVRUSB2_SYSFS for kernels older than 2.6.18 and accept that the driver's sysfs interface won't be present for older kernels. I will take another look at this issue later on this weekend. I suggest moving VIDEO_PVRUSB2_SYSFS from the [2.6.13] section of v4l/versions.txt into the [2.6.18] (or later) section. It's not exactly a FIX, persay... but it is a harmless workaround that will suffice for now. Regards, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvbloop - A virtual DVB adapter
Christian Prähauser wrote: Steven Toth wrote: Exposing an input to the kernel demux via userspace doesn't sound like a bad idea. It would certainly allow developers to build DVB/ATSC applications without having access to live feeds, instead using canned loops provided by who-ever. Any reason why this feature (not necessarily this specific patch) couldn't be part of the regular v4l-dvb tree? - Steve Hello Steve! If desired, I could provide an updated version of dvbloop (with a few bugfixes and adaptations to current kernel/v4ldvb version) during the next days. I would actually love to see such a thing merged into the kernel. Please do post your patch -- I hope that others would agree with me, and would like to see this functionality added to the kernel. :-) Cheers, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem about mt2131 tuner
kevin liu wrote: Dear: In Linux DVB framework, mt2131 works for atsc tv mode. But the problem is that can I use the same module when I want to see any NTSC tv program? mt2131 currently does not support analog television. All we need is to fill .set_analog_params, and call it from tuner-core.c, and then it can work. -Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem about mt2131 tuner
kevin liu wrote: Yeah, I did this part of code already. I design mt2131_set_tv_freq(struct i2c_client *cli, unsigned int freq) function and I compile this part of code into tuner.ko just like mt20xx code has done, static void mt2131_set_tv_freq(struct i2c_client *client, unsigned int freqency) If this is your function prototype, then you must be using much older v4l-dvb code. You'll have to use the most recent mercurial tip in order to use the new hybrid features after the recent tuner refactoring. [code snipped] ++ For mt2131, I use the same init parameters as in ATSC, and the same algorithm for frequency parameters setting. I can see the function correctly called when VIDIOC_S_FREQUENCY. But my tv card's demod just can't get a valid NTSC IF signal. So I suspect if mt2131 has different init params or different freq set algorithm for NTSC. Looks like you just copied the atsc code. I think you'll probably need to use slightly different settings in order to use NTSC instead of ATSC... Also, you probably have to handle a tda988x IF demod. Try using the latest mercurial tip and add analog support for mt2131 that way -- should be easier. Good Luck, Mike On Nov 26, 2007 1:11 PM, Michael Krufky [EMAIL PROTECTED] wrote: kevin liu wrote: Dear: In Linux DVB framework, mt2131 works for atsc tv mode. But the problem is that can I use the same module when I want to see any NTSC tv program? mt2131 currently does not support analog television. All we need is to fill .set_analog_params, and call it from tuner-core.c, and then it can work. -Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] I2C NAKs and fails to respond during init of TDA18211
On Nov 20, 2007 6:23 AM, Scott Merrilees [EMAIL PROTECTED] wrote: Since you are talking about tda182x, I have had some issues in this area, and some with the i2c setup too. I have a lifewalker usb dual digital tuner, which uses tda827x 8324 2 tda1004x 17028 2 dvb_usb_m920x 18308 1 [snip] Mike Krufky, you said you didn't have a dual dvb you could test with the tda back port. I do have one it seems, and I would like to get a working dual tuner option back into the mainline kernel. I can build and test kernels/modules, though my familiarity with the linux-dvb modules is low, it could improve with a few pointers. -- Scott Merrilees, Newcastle, Australia Scott, We were talking about the tda18271 / tda18211 silicon tuner, which has nothing to do with the older tda8275 / tda8275a tuners that you are asking about. The tda18271, like some other tuners, can be daisy-chained using a single rf input and crystal for multiple tuners. This feature is not yet supported in the linux driver, but it would be simple to add. Your dual tuner device is of an entirely different design. Also, FYI, if you try using today's mercurial repository, you will hit a NULL pointer dereference ... I've fixed this in my tree: http://linuxtv.org/hg/~mkrufky/bug-fix ...but I have to clean it up a bit before it gets merged. unrelated: Newcastle is absolutely my favorite beer, although I'm not sure if they make it in Australia or somewhere else... I can't help you with your dual tuner problem -- I am not at all familiar with your device. There is a guy on irc that you might want to ask -- his nick is elronxenu ... or something similar. Good Luck... -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] help with DTV1000S (NXP 18271 + 10048 + 7130)?
Lee Jackson wrote: Well typically I was trying to avoid the hassle with capture cards by getting a reasonably ancient DTV1000T but ended up receiving a DTV1000S *grump* I thought at £20 it was too good to be true ;) Specs are at : http://www.leadtek.com.tw/eng/tv_tuner/specification.asp?pronameid=382lineid=6act=2 Now Ive worked through the wiki and the faq, hacked away at different combinations of commands and tried to get some understanding of what I'm doing; however Ive reached the point where I could use some assistance to head in the right direction please :) Ive grabbed the latest drivers as detailed at http://www.linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers, however this card still isn't recognized so its incorrectly auto-detected. I did by accident get composite input working via modprobe saa7134 card=21 tuner=0 but I've had no luck with the dvb. I understand Mr Markus Rechberger has been working on support for the 18271 chipset but I cant seem to come up with any combination of drivers that result in the cards digital tuner being recognized. So at this point ANY help or assistance greatly appreciated. No, I wrote the tda18271 driver. There currently is no support for the TDA10048 channel decoder, so you will not yet be able to use digital mode. Unless you also have a TDA8290 or TDA8295 on that board (or a saa7131) , then you won't be able to watch analog television, either. Sorry, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DViCO Dual Digital 4 and remote
Robert Backhaus wrote: Big thanks to all the very smart people who are working on this. (Big Lartings to the manufacturers who are _NOT!!!) That's not cool. DViCO is being very helpful. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Pinnacle PCTV HD Ultimate Stick
Jeff Rosenberg wrote: I just purchase the PCTV HD Ultimate Stick. I decided upon this since it supported clear QAM and had flash space for recording to the stick in addition to the hardrive. I read that the PCTV HD Pro Stick was supported with the latest Experimental build based on the em2883 chipset. I took the risk and went with the Ultimate instead of the Pro. [snip] Any chance that there will be support for this newly released USB stick ? You wont find native support for this in any Linux Distribution's native kernel anytime soon. Your best bet, in this case, is to look at Markus' experimental repository. I don't think that he has support for this exact device yet, but he does have most of the pieces required. #1) You need em2880-dvb support, which is not yet in the master v4l-dvb development branch #2) (I think) you'll need an xc5000 driver, also not yet merged into the v4l-dvb master branch. You might be able to assemble the right pieces of code together, but I don't know where you'll find it all at this time. Given a few months (or weeks, in a perfect world) time, the situation may become clearer. Good Luck, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Pinnacle PCTV HD Ultimate Stick
Markus Rechberger wrote: On 11/15/07, Michael Krufky [EMAIL PROTECTED] wrote: Jeff Rosenberg wrote: I just purchase the PCTV HD Ultimate Stick. I decided upon this since it supported clear QAM and had flash space for recording to the stick in addition to the hardrive. I read that the PCTV HD Pro Stick was supported with the latest Experimental build based on the em2883 chipset. I took the risk and went with the Ultimate instead of the Pro. [snip] Any chance that there will be support for this newly released USB stick ? You wont find native support for this in any Linux Distribution's native kernel anytime soon. Your best bet, in this case, is to look at Markus' experimental repository. I don't think that he has support for this exact device yet, but he does have most of the pieces required. #1) You need em2880-dvb support, which is not yet in the master v4l-dvb development branch #2) (I think) you'll need an xc5000 driver, also not yet merged into the v4l-dvb master branch. You might be able to assemble the right pieces of code together, but I don't know where you'll find it all at this time. Given a few months (or weeks, in a perfect world) time, the situation may become clearer. Michael, this is no em28xx based device, I guess it's a dibcom one. Ah, OK. Thanks, Markus. In which case, bridge-wise, it may be a bit easier (or more difficult, depending) than I thought. Jeff, it might be helpful if you could crack open the device and tell us all of the chips featured inside. Hi-res digital photos are always helpful :-) If you can take photos, please post them to a website (like bttv-gallery) and post links here. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DViCO FusionHDTV DVB-T Dual Express?
[EMAIL PROTECTED] wrote: Hi dvb list, I'm in need of another dual tuner card and am currently debating between getting another DD4 or getting one of the newer PCIe cards. Can anyone confirm that the PCIe Dual Express works with linux (negative responses also helpful)? I would ideally prefer to go the PCIe path but given the amount of time I have already spent getting the DD4 working in Australia I would prefer not to have to do it again for a PCIe variant without some hope of being successful. Failing an affirmative does anybody in Australia have a card they're willing to loan me for a few weeks to see if I can get it going? DVB-T Dual Express is not yet supported. Some people have been emailing me privately about this -- too many people for me to respond to... Hopefully they'll see this message. There is a new xceive driver in the master branch, but it's lacking a dvb entry point at this time... Once that's done, it will pave the way for cx23885 + xc3028 device support. After support for the Hauppauge HVR1500 (atsc only) is added, it will be easier to add support for other cx23885 + xc3028 devices, such as the DViCO DVB-T Dual Express. A while back, I was sending out test patches that used the xc3028-fe module, from the infamous xc-bluebird.patch ... I am no longer going to bother with this method, since there finally is an xceive driver in the master development branch. Once the xceive dvb entry point is ready, I (or Chris) will re-spin the Dual Digital 4 / DVB-T Nano2 support to use the new tuner module. Things are moving along... -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] xc3028 tuner development status?
On Nov 13, 2007 11:16 AM, aldebaran [EMAIL PROTECTED] wrote: I thank you very much for your quick reply Michel, Markus and Mauro!! [snip] [ 789.484000] cx23885 driver version 0.0.1 loaded [ 789.484000] ACPI: PCI Interrupt :04:00.0[A] - GSI 17 (level, low) - IRQ 17 [ 789.484000] CORE cx23885[0]: subsystem: 0070:7717, board: Hauppauge WinTV-HVR1800lp [card=1,insmod option] [ 789.584000] cx23885[0]: i2c bus 0 registered [ 789.584000] cx23885[0]: i2c bus 1 registered [ 789.584000] cx23885[0]: i2c bus 2 registered [ 789.612000] tveeprom 0-0050: Hauppauge model 77001, rev D4C0, serial# 2335707 [ 789.612000] tveeprom 0-0050: MAC address is 00-0D-FE-23-A3-DB [ 789.612000] tveeprom 0-0050: tuner model is Xceive XC3028 (idx 120, type 71) [ 789.612000] tveeprom 0-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) [ 789.612000] tveeprom 0-0050: audio processor is CX23885 (idx 39) [ 789.612000] tveeprom 0-0050: decoder processor is CX23885 (idx 33) [ 789.612000] tveeprom 0-0050: has no radio, has no IR receiver, has no IR transmitter [ 789.612000] cx23885[0]: hauppauge eeprom: model=77001 [ 789.612000] cx23885[0]: cx23885 based dvb card [ 789.624000] cx23885[0]: frontend initialization failed [ 789.624000] cx23885_dvb_register() dvb_register failed err = -1 [ 789.624000] cx23885_dev_setup() Failed to register dvb adapters on VID_C [ 789.624000] cx23885[0]/0: found at :04:00.0, rev: 2, irq: 17, latency: 0, mmio: 0xf400 [ 789.624000] PCI: Setting latency timer of device :04:00.0 to 64 Don't worry about this -- Steve's got it covered: http://linuxtv.org/pipermail/linux-dvb/2007-November/021863.html -mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] TechniSat Air2PC-ATSC-USB devices
On Mon, 22 Oct 2007, CityK wrote: In discussion with Michael a couple of weeks ago, he mentioned that he didn't think that the older TechniSat ATSC USB devices ( http://www.linuxtv.org/wiki/index.php/TechniSat_Air2PC-ATSC-USB ) are actually supported, but suggested you might know better. Could you, or anyone else, confirm the status. On Nov 10, 2007 4:58 PM, Patrick Boettcher [EMAIL PROTECTED] wrote: I don't know anything about this device. Maybe it uses the bcm3510-demod in this case it could work with the flexcop-driver. But also this means that there is only USB1.1 support (useful bitrate less than 8MBit/s with Airstar DVB-T). I believe that this device was released around the same time as the AirStar 5000 (PCI), which used the LG-H064F NIM (LGDT3303 atsc/qam demod). It's very likely that the same NIM is used in this device, in which case it would be equally as easy to add support. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] TechniSat Air2PC-ATSC-USB devices
CityK wrote: Michael Krufky wrote: On Mon, 22 Oct 2007, CityK wrote: In discussion with Michael a couple of weeks ago, he mentioned that he didn't think that the older TechniSat ATSC USB devices ( http://www.linuxtv.org/wiki/index.php/TechniSat_Air2PC-ATSC-USB ) are actually supported, but suggested you might know better. Could you, or anyone else, confirm the status. On Nov 10, 2007 4:58 PM, Patrick Boettcher [EMAIL PROTECTED] wrote: I don't know anything about this device. Maybe it uses the bcm3510-demod in this case it could work with the flexcop-driver. But also this means that there is only USB1.1 support (useful bitrate less than 8MBit/s with Airstar DVB-T). I believe that this device was released around the same time as the AirStar 5000 (PCI), which used the LG-H064F NIM (LGDT3303 atsc/qam demod). It's very likely that the same NIM is used in this device, in which case it would be equally as easy to add support. - Mike (who has self professed on a number of occasions that he has a memory like a sieve -- and, hence, if he sometimes forgets things, its perfectly excusable) appears to have _inexcusably_ ignored the content of the earlier message and shot from the hip, and injected erroneous information (as seen above) What erroneous information? I said it uses the LG-H064f, and that's what it says on the wiki. Your comment here doesn't sound very nice :-( ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] I2C NAKs and fails to respond during init of TDA18211
MikeW wrote: Michael Krufky mkrufky at linuxtv.org writes: You might want to take a look at the tda18271 driver recently merged into the master branch, located under dvb/frontends ... Perhaps this driver might be enough to bring up the tda18211-- I don't have the spec for the 18211, so I cannot say that for sure, but I was under the impression that the tda18211 is exactly a tda18271, but DVB only. Let me know if there's anything that I can do to help you. Regards, Mike Krufky Also note in your tda18271_set_params() sgIF gets set for ATSC mode but is left at zero for OFDM mode - this is incorrect I believe, and the datasheet gives the required IFs as 3.3, 3.8 and 4.3 MHz It's not wrong -- it's just missing. I said it before -- the driver is not tested with DVB-T -- I need a test case for it first. Feel free to send in a patch, since you DO have that test case. Cheers, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] I2C NAKs and fails to respond during init of TDA18211
MikeW wrote: Michael Krufky mkrufky at linuxtv.org writes: It's not wrong -- it's just missing. I said it before -- the driver is not tested with DVB-T -- I need a test case for it first. Feel free to send in a patch, since you DO have that test case. Cheers, Mike Krufky Sadly I have not yet achieved FE_HAS_SIGNAL (TDA10048 reg 1A: FREQ_LOCK) with _any_ code, though I /have/ had FE_HAS_CARRIER, FE_HAS_SYNC FE_HAS_VITERBI. Hence do not get FE_HAS_LOCK (TDA10048 reg 1A: FEL) Possibly need to get a spectrum analyser onto the IFOUT pins to see why the 10048 is not achieving proper lock. May be a 10048 setup mismatch ... On that basis I am not willing to submit patches, until I have demonstrably working tuning ! OK, that's understandable. If you should decide to share your code as-is, I (or someone else) might be able to see a problem in it that you don't see yourself... But, I'm not pushing it. Show your code when you feel comfortable with it. :-) PS. One of the RF techies said that silicon tuners were _much_ harder work than can tuners, hence the increase in s/w needed to work them ... *very* true ;-) Good Luck, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] I2C NAKs and fails to respond during init of TDA18211
On 11/8/07, Michael Krufky wrote: If you prefer, I can arrange for a separate repository to be set up for the purposes of the tda182x1 work. Let me know what you think. I used gmail to write that message, but forgot to change the return address to linuxtv.org -- please use my linuxtv.org address, as I don't regularly check gmail. Cheers, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] I2C NAKs and fails to respond during init of TDA18211
On 11/8/07, MikeW [EMAIL PROTECTED] wrote: Michael Krufky mkrufky at linuxtv.org writes: You might want to take a look at the tda18271 driver recently merged into the master branch, located under dvb/frontends ... Perhaps this driver might be enough to bring up the tda18211-- I don't have the spec for the 18211, so I cannot say that for sure, but I was under the impression that the tda18211 is exactly a tda18271, but DVB only. Let me know if there's anything that I can do to help you. Regards, Mike Krufky Thanks. I also note in your repository code that there is no account taken of whether the chip is in Master or Slave mode - the 18211 needs different frequency setting depending on whether it is running the 16MHz crystal (Master), or whether it just has the 16MHz input (Slave). This is relevant if you have a dual-tuner configuration, increasingly common to allow PVR and viewing on different channels. In Master mode you set the required frequency on the Main PLL, in Slave mode you have to use the Cal PLL. Also set CALVCO_forLOn: EB1[2] and a few other bits ! I am aware of this, but currently do not have a dual tda18271 device to play with, so I left this feature out of the code. I'd recommend to pass such information (master / slave , etc) into the driver via a tda18271_config struct, declared inside tda18271.h and passed in by the host driver. I expect that either I would end up with a new device eventually, or somebody like yourself would have such a device and improve upon my code. This is open source -- please feel free to make changes as you see fit and send them in -- I would be happy to integrate them into the official source tree. Additionally, your earlier email mentioned that you have broken up the tune function into smaller functions. This would be an improvement, and I would also be happy to apply such a change to the current driver. So far, I have only tested it in analog mode. I've also heard that the driver works for ATSC and QAM (usa) , but it is still not tested with DVB-T. I suspect that it will be nicer to have that large function broken down to smaller functions, but I haven't had the need to do it yet myself, so I haven't spent the time. Please feel free to send in patches -- This driver has the potential to support every flavor of this chip, in all supported analog and digital video standards. If you prefer, I can arrange for a separate repository to be set up for the purposes of the tda182x1 work. Let me know what you think. Cheers, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVICO NANO Australia
Michael Krufky wrote: Collier Family wrote: I have a DVICO NANO but I am having the same troubles others had in June. It appears it is not being recognised as being cold. I have followed the instructions at http://fremnet.net/article/228/dvico-fusionhdtv-dual-digital-4-under-linux and all went well except the frontend not set. dmesg follows usb 5-8: new high speed USB device using ehci_hcd and address 9 usb 5-8: configuration #1 chosen from 1 choice dvb-usb: found a 'DViCO FusionHDTV DVB-T NANO2' in warm state. dvb-usb: bulk message failed: -22 (2/0) dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (DViCO FusionHDTV DVB-T NANO2) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (3/0) dvb-usb: bulk message failed: -110 (3/0) dvb-usb: bulk message failed: -110 (5/0) dvb-usb: no frontend was attached by 'DViCO FusionHDTV DVB-T NANO2' dvb-usb: DViCO FusionHDTV DVB-T NANO2 successfully initialized and connected. Is there any other information that may help I am running vanilla 2.6.23.1 kernel on Scientific linux 5.0 Thanks a lot for the work so far. The DVB-T NANO2 does not require the bluebird firmware -- the fx2 boots it from the eeprom. So, the device does not have a cold state. The only firmware that you need for it is the xc3028 firmware that was used in Markus' xc3028 kernel driver. However, there is alternate firmware required for the xc3028 for use in Australia. I assume that you already have that. Sorry, I forgot to add the helpful advice ;-) ...It looks like the driver is having trouble accessing the zl10353. Can you check to make sure the device works in windows? -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVICO NANO Australia
Collier Family wrote: I have a DVICO NANO but I am having the same troubles others had in June. It appears it is not being recognised as being cold. I have followed the instructions at http://fremnet.net/article/228/dvico-fusionhdtv-dual-digital-4-under-linux and all went well except the frontend not set. dmesg follows usb 5-8: new high speed USB device using ehci_hcd and address 9 usb 5-8: configuration #1 chosen from 1 choice dvb-usb: found a 'DViCO FusionHDTV DVB-T NANO2' in warm state. dvb-usb: bulk message failed: -22 (2/0) dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (DViCO FusionHDTV DVB-T NANO2) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (3/0) dvb-usb: bulk message failed: -110 (3/0) dvb-usb: bulk message failed: -110 (5/0) dvb-usb: no frontend was attached by 'DViCO FusionHDTV DVB-T NANO2' dvb-usb: DViCO FusionHDTV DVB-T NANO2 successfully initialized and connected. Is there any other information that may help I am running vanilla 2.6.23.1 kernel on Scientific linux 5.0 Thanks a lot for the work so far. The DVB-T NANO2 does not require the bluebird firmware -- the fx2 boots it from the eeprom. So, the device does not have a cold state. The only firmware that you need for it is the xc3028 firmware that was used in Markus' xc3028 kernel driver. However, there is alternate firmware required for the xc3028 for use in Australia. I assume that you already have that. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] firmware writing every second or two
Bonne Eggleston wrote: On Sat, 1 Sep 2007 04:41:27 pm victor rajewski wrote: Hi, I'm trying to debug some problems with my Dvico Dual Digital 4 card (using patches from http://fremnet.net/article/228/dvico-fusionhdtv-dual-digital-4-under-linux) and I've noticed in dmesg that the firmware seems to get written to the card every second or two. This is the repeating part of the log message: Aug 26 20:17:13 what kernel: [ 811.252000] Loading 7MHz Bandwidth settings: xc3028_DTV7_2633.i2c.fw Aug 26 20:17:14 what kernel: [ 812.536000] Loading base firmware: xc3028_8MHz_init0.i2c.fw Aug 26 20:17:15 what kernel: [ 813.80] Loading default dtv settings: xc3028_DTV8_2633.i2c.fw Aug 26 20:17:15 what kernel: [ 813.832000] xc3028-tuner.c: sending extra call for DVB-T Is this normal? Do other cards do this? Not sure, but mine does exactly the same. I'm in Australia. I'm not sure if it's a problem, but I'm sure it can't be good. It's not a problem -- it's just a crappy driver, that's all. If you dont like the messages, then disable the printk's in the xc-bluebird patch. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hvr-1800 status?
[EMAIL PROTECTED] wrote: I just picked up this card and I'm looking forward to trying it. I run Fedora 7 x86_64 2.6.23-1.10. I guess I'll try the steps as described at http://linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers and see how it goes. How close are we to getting NTSC to work? Do I need firmware for this card? Advice and pointers welcome. Funny that you should ask about analog mode NTSC just a week or two after we've confirmed that QAM works. (ATSC has always worked, QAM needed a small patch to fix). The NTSC tuner is already supported, but the cx23885 bridge driver does not yet support analog mode. I don't know how long that will take, but it shouldn't be too far off. You don't need any firmware for the hvr1800. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] I2C NAKs and fails to respond during init of TDA18211
On 11/1/07, MikeW [EMAIL PROTECTED] wrote: Using the OM5776 eval board, and using the algorithm published in the rev 1.1.0 datasheet, I find I am getting an I2C NAK, which does not go away and requires a chip reset to restore any I2C communication, after successfully writing EP4 (r06) in the 'image rejection cal pt I, wanted signal measurement' section where registers are written back. (NAK occurs on write to EP5) While in calibration mode, the bytes of sub addresses 0x03 thru 0x0f must be written in one single i2c sequence. Are you sure that you're using the exact algorithm from the datasheet? You're better off storing the values that you plan to write, then write them all at once in a single transaction. You might want to take a look at the tda18271 driver recently merged into the master branch, located under dvb/frontends ... Perhaps this driver might be enough to bring up the tda18211-- I don't have the spec for the 18211, so I cannot say that for sure, but I was under the impression that the tda18211 is exactly a tda18271, but DVB only. Let me know if there's anything that I can do to help you. Regards, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] merged tree with newer patch series
On 10/29/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: Please test and give us some feedback. Big changes like this are subject to miscellaneous issues, since we're all humans ;) I tested the merge tree with my tda8295 + tda18271 hardware, and it works as expected. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] tuner-refactor-phase-2
Mauro Carvalho Chehab wrote: Em Sex, 2007-10-26 às 12:09 +0200, Hans Verkuil escreveu: On Friday 26 October 2007 06:24, Michael Krufky wrote: Mauro Carvalho Chehab wrote: Hi Michael, Em Seg, 2007-10-22 às 16:03 -0400, [EMAIL PROTECTED] escreveu: Mauro others, After our conversation last week, I decided to move forward with tuner-refactor-phase-2, so that you can have the pathway for your tda9887 tea5767 changes to go in without clashing with my pending work. My code is now ready for review: http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-2 I expect a few troubles on merging the newer patches for 2.6.25, since there are several significant changes that are expected to happen, during this development period, like: - the newer tuner-redesign changesets; - i2c redesign; - bttv removal of V4L1 support; ^^^ These above do not conflict with each other. I suspect that bttv V4L1 removal will conflict with both changesets. I'll need to decide what's the better order for merging those 3 changes to avoid breaking bttv. NO -- the tuner changes do not touch bttv -- they are all internal to the tuner code. If you have to remove some v4l1 support from tuner-core, that will simply be the removal of a few lines, and it can be easily done by hand. OTOH, If you push in the v4l1 removal first, and it conflicts with the pending tuner changes, that _will_ cause a problem. It will require for the entire patch series to be regenerated, and this will result in holding up Hans from moving forward with his work, until I have time to regenerate the entire series. bttv has several hacks for probing i2c audio devices. Depending on the way Hans touched bttv, the conflicts will emerge. Hans did not touch anything yet -- he's waiting for the pending changes to first be merged. As I said before, Hans and I spoke about our changes with each other, and made sure that we would not create any patch conflicts. Everybody is waiting for the large changes to be merged in first before they move on to making new changes to the affected code. With the new tuner-xc2028, the tuner will only work after receiving a TUNER_SET_CONFIG, specifying the firmware driver name[2] and the audio mode (RF or MTS). [2] from what I got, it seems that different bridge chips may need different firmwares. TM6000 driver, for example, doesn't work with xc3028 version 2.7 firmware. If you are going to push in the xc2028 stuff, the core changes should go in first, then you should alter your new patch as required. I do not expect this xc2028 driver to work with the devices that I have, and I believe that you are going to create a large confusion about firmware, not to mention that you do not have any legal rights to alter or distribute the firmware. I wouldn't rush in the xc2028 stuff before the other changes. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] tuner-refactor-phase-2
Mauro Carvalho Chehab wrote: Hi Michael, Em Seg, 2007-10-22 às 16:03 -0400, [EMAIL PROTECTED] escreveu: Mauro others, After our conversation last week, I decided to move forward with tuner-refactor-phase-2, so that you can have the pathway for your tda9887 tea5767 changes to go in without clashing with my pending work. My code is now ready for review: http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-2 I expect a few troubles on merging the newer patches for 2.6.25, since there are several significant changes that are expected to happen, during this development period, like: - the newer tuner-redesign changesets; - i2c redesign; - bttv removal of V4L1 support; ^^^ These above do not conflict with each other. Hans and I have coordinated such that we will not patch clash, and the i2c conversions deal mostly with client modules... any impact on bttv, if any, will be localized in the i2c code. The pending bttv patch probably needs updating anyway, due to changes upstream. The changes above hold priority over the two below. - xc3028 old code removal; - tuner-xc2028 addition; Regardless, the xc2028 changes are unlikely to cause any conflict with the other changes. Hans is waiting for the tuner-refactor-phase-2 tree to be merged before he pushes in the i2c changes, and you should wait for those both to be merged before dealing with xc2028, in my opinion. Since those envolves several changes at core, it is likely that changesets will conflict. anything is possible, but i don't think it's likely :-) So, I intend to carefully handle the 2.6.25 changesets already finished during this weekend, hopefully. OK. I have more changes planned that depend on these... If I add changesets to the tree, i'll send you addendums to my original pull request. Cheers, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Support for newest DVICO Fusion HDTV Dual Express
Patrick Claven wrote: Hi people, I've got the latest DVICO Fusion HDTV Dual Express. From what I have gathered thus far, it has a Conexant cx23885 chipset and an xceive xc30xx chipset. I'm not sure whether it would work with the xc3028 driver, i have loaded the xc3028-fe patched module as according to steps outlined here: http://fremnet.net/article/228/dvico-fusionhdtv-dual-digital-4- under-linux but it has no effect. I actually have the dual digital 4 card referred to in that article running perfectly, but I'm not so naive as to think that my new card which is PCIe 1x will work, especially given the fact that I think it's a newer xceive chipset than that in the dual digital 4. I compiled the very latest v4l-dvb and got the cx23885 module loaded, it detects the card as an unknown type, as shown in the following dmesg output: [ 5980.021706] cx23885 driver version 0.0.1 loaded [ 5980.021770] ACPI: PCI Interrupt :03:00.0[A] - GSI 19 (level, low) - IRQ 17 [ 5980.021774] cx23885[0]: Your board isn't known (yet) to the driver. You can [ 5980.021776] cx23885[0]: try to pick one of the existing card configs via [ 5980.021777] cx23885[0]: card=n insmod option. Updating to the latest [ 5980.021778] cx23885[0]: version might help as well. [ 5980.021780] cx23885[0]: Here is a list of valid choices for the card=n insmod option: [ 5980.021782] cx23885[0]:card=0 - UNKNOWN/GENERIC [ 5980.021784] cx23885[0]:card=1 - Hauppauge WinTV-HVR1800lp [ 5980.021786] cx23885[0]:card=2 - Hauppauge WinTV-HVR1800 [ 5980.021788] cx23885[0]:card=3 - Hauppauge WinTV-HVR1250 [ 5980.021789] cx23885[0]:card=4 - DViCO FusionHDTV5 Express [ 5980.021798] CORE cx23885[0]: subsystem: 18ac:db78, board: UNKNOWN/ GENERIC [card=0,autodetected] [ 5980.120888] cx23885[0]: i2c bus 0 registered [ 5980.120905] cx23885[0]: i2c bus 1 registered [ 5980.120919] cx23885[0]: i2c bus 2 registered [ 5980.147782] cx23885[0]/0: found at :03:00.0, rev: 2, irq: 17, latency: 0, mmio: 0xfd80 [ 5980.147801] PCI: Setting latency timer of device :03:00.0 to 64 [ 6178.439162] Linux video capture interface: v2.00 [ 6178.531298] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded [ 6279.216926] usbcore: registered new interface driver dvb_usb_cxusb Okay, so if I tell it that its card number 4, it registers the dvb adapter0 in /dev/dvb/adapter0 and so forth. However it loads the LG tuner chipset that ships with the HDTV5 Express card, so we definitely know that won't work. So to cut a long story short, reading the xceive chipset on the card it appears to say xc3008ACQ. This may not mean much to anybody, it doesnt to me. So realising this card does not have support under linux yet, I primarily would like to volunteer for testing of this card for anybody brave enough to endeavour to get this working. Thanks a lot, and I hope some of this made sense. This is the first time I've posted to any mailing list. Patrick- I can post a test patch for you, within the next few days. Which demod is used on that card? Is it two zl10353's ? Can you show me the output of 'modprobe cx23885 i2c_scan=1' , after first doing 'modprobe -r cx23885' ? -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB driver for WinTV-D card
CityK wrote: Olin Atkinson wrote Has anyone done any work on getting the digital side working? I would love to help. I am an electrical engineer who has worked as a java programmer for the last 11 years. I have some free time and would like to play with this for the fun of it. Stemming from an IRC discussion, held a couple of months ago, about the FCV1236 tuner, Mike Krufky (who is also a WinTV-D owner...or at least was) and I looked at the WinTV-D, and, as far as what we could see from the archives, no work ever went in towards the digital side. It would likely not be an easy task at that -- one of the difficulties right out of the gate would be in obtaining documentation for the LG decoder -- there is none to be found via google, so other means will likely be necessary. I don't know if LG or Hauppauge would be interested in furnishing you with a data sheet (Mike had inquired with Hauppauge previously, but there apparently wasn't much interest ... but he would be able to comment better now, given a change in circumstances). I was thinking of writing a driver for the tda8960 demod, but CityK is right -- I've no idea how I will attain support for the mpeg decoder, nor am I familiar enough with those types of devices... I'm more interested in newer devices right now -- sorry. As it is now, this might be a project for a rainy day, if all other projects suddenly become boring. :-/ Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Support for newest DVICO Fusion HDTV Dual Express
Michael Krufky wrote: Patrick Claven wrote: Hi people, I've got the latest DVICO Fusion HDTV Dual Express. From what I have gathered thus far, it has a Conexant cx23885 chipset and an xceive xc30xx chipset. I'm not sure whether it would work with the xc3028 driver, i have loaded the xc3028-fe patched module as according to steps outlined here: http://fremnet.net/article/228/dvico-fusionhdtv-dual-digital-4- under-linux but it has no effect. I actually have the dual digital 4 card referred to in that article running perfectly, but I'm not so naive as to think that my new card which is PCIe 1x will work, especially given the fact that I think it's a newer xceive chipset than that in the dual digital 4. I compiled the very latest v4l-dvb and got the cx23885 module loaded, it detects the card as an unknown type, as shown in the following dmesg output: [ 5980.021706] cx23885 driver version 0.0.1 loaded [ 5980.021770] ACPI: PCI Interrupt :03:00.0[A] - GSI 19 (level, low) - IRQ 17 [ 5980.021774] cx23885[0]: Your board isn't known (yet) to the driver. You can [ 5980.021776] cx23885[0]: try to pick one of the existing card configs via [ 5980.021777] cx23885[0]: card=n insmod option. Updating to the latest [ 5980.021778] cx23885[0]: version might help as well. [ 5980.021780] cx23885[0]: Here is a list of valid choices for the card=n insmod option: [ 5980.021782] cx23885[0]:card=0 - UNKNOWN/GENERIC [ 5980.021784] cx23885[0]:card=1 - Hauppauge WinTV-HVR1800lp [ 5980.021786] cx23885[0]:card=2 - Hauppauge WinTV-HVR1800 [ 5980.021788] cx23885[0]:card=3 - Hauppauge WinTV-HVR1250 [ 5980.021789] cx23885[0]:card=4 - DViCO FusionHDTV5 Express [ 5980.021798] CORE cx23885[0]: subsystem: 18ac:db78, board: UNKNOWN/ GENERIC [card=0,autodetected] [ 5980.120888] cx23885[0]: i2c bus 0 registered [ 5980.120905] cx23885[0]: i2c bus 1 registered [ 5980.120919] cx23885[0]: i2c bus 2 registered [ 5980.147782] cx23885[0]/0: found at :03:00.0, rev: 2, irq: 17, latency: 0, mmio: 0xfd80 [ 5980.147801] PCI: Setting latency timer of device :03:00.0 to 64 [ 6178.439162] Linux video capture interface: v2.00 [ 6178.531298] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded [ 6279.216926] usbcore: registered new interface driver dvb_usb_cxusb Okay, so if I tell it that its card number 4, it registers the dvb adapter0 in /dev/dvb/adapter0 and so forth. However it loads the LG tuner chipset that ships with the HDTV5 Express card, so we definitely know that won't work. So to cut a long story short, reading the xceive chipset on the card it appears to say xc3008ACQ. This may not mean much to anybody, it doesnt to me. So realising this card does not have support under linux yet, I primarily would like to volunteer for testing of this card for anybody brave enough to endeavour to get this working. Thanks a lot, and I hope some of this made sense. This is the first time I've posted to any mailing list. Patrick- I can post a test patch for you, within the next few days. Which demod is used on that card? Is it two zl10353's ? Can you show me the output of 'modprobe cx23885 i2c_scan=1' , after first doing 'modprobe -r cx23885' ? UPDATE: Patrick has the DViCO FusionHDTV Express DVB-T Dual Pro, which uses the same configuration as the DVB-T NANO, and the DD4, but using the CX23885 PCI Bridge. It's safe to assume that it uses the zl10353 demod, although we'll be screwed if DViCO went for the newer Intel version of that part. (I've yet to see the zl10353 linux driver work for the Intel part) %Zulu885.DvbtDualPro% = Zulu885.DvbtDualPro, PCI\VEN_14F1DEV_8852SUBSYS_DB7818AC I'll work on a xc-zulu885.patch this week, which will depend on my xc-bluebird.patch, so you can test it. In the meanwhile, the i2c_scan output will be helpful, so that I can determine which i2c bus I can expect to find the tuner hardware. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] support from cx23885 driver and Xc3028 tuner for HP/Hauppauge WinTv885 mod 77001
aldebaran wrote:
Dear linux-dvb developers,
owning an HP rebranded Hauppauge Express Card shipped with several
mid-high end HP laptops I would like to give you some support in
further improving cx23885 driver for it to support those tuners.
here are my card specs:
HP Hauppauge WinTv 885
model 77001 rev d4c0 (Model 77xxx Analog/ATSC Hybrid, Xc3028)
tuner: Xceive xc3028 http://www.xceive.com/technology_XC3028.htm
audio tuner: stereo cx23885
decoder: cx23885 http://www.conexant.com/products/entry.jsp?id=393
- insmod cx23885 manages to create a /dev/dvb device folder only if
arguments card=3 or card=4 are supplied
- despite the card being recognized with such arguments I cannot
manage to use Kaffeine DVB support as although kaffeine -w recognises
the card, it cannot scan for any available channels ('scan on'
dropdown menu is empty, clicking 'Start Scan' button does not list
anything)
- also with Klear, provided a channel.conf, the program cannot tune to
any channel and outputs the same error as the scan command from
dvb-utils:
WARNING: frontend type (ATSC) is not compatible with requested tuning
type (OFDM) ERROR: initial tuning failed
- the device is not hot-plug recognized, I had to reboot before the
system can actually recognize it (however both express card specs and
windows support plungplay).
Any other help I could provide you with debugging/testing these cards
I would be pleased to, just ask.
Thank you very very much for pioneering dvb video support for
gnu/linux, I really appreciate your efforts.
It would be helpful to see the output of 'modprobe cx23885 i2c_scan=1' ,
after first doing 'modprobe -r cx23885' -- I have this card also, and
I'd like to make sure that we have the same revision.
I started working on this one, but I've been held up due to firmware
issues-- So far, the working ATSC linux drivers for the xc3028 have all
worked when coupled with an LGDT3303 demod. In your device, we have a
Samsung demodulator, instead. The xc3028 requires a different firmware
image in this case, and I haven't yet found time to work that out.
I'd expect to have the details sorted within the next month or so, but I
don't want to make any promises.
HTH,
Mike
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Anysee E30C Plus (Re: DVB-C developers interested in receiving an USB adapter for hacking?)]
Antti Palosaari wrote:
heips,
hmm, now I am a little bit confused because there is this same id as MT352
board. Maybe this is not just board id, but some other value that differs
from design to design. Could it be firmware version...
There is matrix I have now:
board id model demodtuner module PCB version
0a 01 00 E30C Plus TDA10023 DTOS403IH102A 507DC (REV 0.2) Timo
02 02 01 E30 ZL10353 ? PCB509T REV 1.61 Heikki
06 01 00 E30 Plus ZL10353 DNOS404ZH103A ?Risto
02 02 01 E30 MT352DNOS4D4ZH102A ?Mika (not sure
if 02 02 02 because sniff is from other dev)
CI board seems to be same design in both Plus models mentioned: 507_SM
BOARD (V1.2).
More reports needed.
Antti,
This wouldn't be the first time that a vendor released a device without
changing the product id, whose earlier revisions used an mt352, and later
revisions used a zl10353.
I recommend that you handle it in the following way:
static int anysee_zl35x_frontend_attach(struct dvb_usb_adapter *adap)
{
/* any device-specific stuff may go here */
if (((adap-fe = dvb_attach(mt352_attach, anysee_mt352_config,
adap-dev-i2c_adap)) != NULL) ||
((adap-fe = dvb_attach(zl10353_attach,
anysee_zl353_config,
adap-dev-i2c_adap)) != NULL))
return 0;
return -EIO;
}
The _attach functions of each module tests the id register to ensure that the
proper demod is actually present -- a few drivers are already doing this, such
as dvb-usb-cxusb and dvb-bt8xx. I think there are others as well...
HTH,
Mike
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC-final] videobuf tree
Mauro Carvalho Chehab wrote: Michael, However, cx23885 is now broken. Upon starting a DVB stream, the following OOPS is generated: I've reviewed cx23885 videobuf stuff. I noticed a problem at the conversions: It is still using the abstract videobuf constructor, instead of the pci DMA S/G one. I've just added a patch fixing this at v4l-dvb tree. Probably, this will fix the issue. Mauro, This new patch fixed the problem. CX23885 functionality is restored! :-) side note: If we had left a single header, video-buf.h, we could have avoided this problem. When we rename files like this, we run the risk of building against the wrong headers, if errors are not caught corrected quickly enough. Are you open to merging the videobuf-*.h into a single video-buf.h header file, to match the filename in previous kernel versions so that we can avoid this issue from recurring? Either that, or including the current headers into a new video-buf.h would do the same job. What do you think? -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC-final] videobuf tree
Mauro Carvalho Chehab wrote: Mauro, This new patch fixed the problem. CX23885 functionality is restored! :-) Good! If you send your reviewed-by, I'll add at the proper changesets touching videobuf. 3762b92e232a - V4L/DVB (6287) - Fix DMA Scatter/Gather constructor Reviewed-by: Michael Krufky [EMAIL PROTECTED] side note: If we had left a single header, video-buf.h, we could have avoided this problem. When we rename files like this, we run the risk of building against the wrong headers, if errors are not caught corrected quickly enough. Are you open to merging the videobuf-*.h into a single video-buf.h header file, to match the filename in previous kernel versions so that we can avoid this issue from recurring? Either that, or including the current headers into a new video-buf.h would do the same job. What do you think? I don't like to create a video-buf.h header. This will make non-pci devices dependent on PCI, or will require some additional logic for checking kernel Kconfig symbols. I also expect that other newer videobuf methods to be created. So, this header will just generate undesirable mess. This would not create dependencies of non-pci devices on pci -- a simple header inclusion is optimized by the c compiler -- only needed methods are considered and are actually included in the build. What we might do is to rename the generic abstract method to another name. This will generate compilation errors, making easier for people to realize what happened. If we rename it to video-buf.h, it would cover the issue that I have in mind. I'm not sure if this is valuable enough, since I don't know any other DMA S/G driver using videobuf being developed for their inclusion at Kernel. Maybe an out of tree driver uses it? Maybe there is an in-tree driver that still might have old methods being used but we didnt hit those bugs yet due to incomplete testing methods? Cheers, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC-final] videobuf tree
Mauro Carvalho Chehab wrote: Hi Michael, Please try the enclosed patch. It is just a hack. Please, post the dmesg, working or not. Mauro, Your patch touches code that apparently is not being executed in this case. I've enclosed dmesg anyway (see attached) Regards, Mike [0.00] Linux version 2.6.20-16-generic ([EMAIL PROTECTED]) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #2 SMP Thu Aug 30 23:16:15 UTC 2007 (Ubuntu 2.6.20-16.31-generic) [0.00] Command line: root=UUID=600107c6-8f24-4dde-8730-24743aa335ec ro quiet splash [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009ac00 (usable) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3f651c00 (usable) [0.00] BIOS-e820: 3f651c00 - 3f653c00 (ACPI NVS) [0.00] BIOS-e820: 3f655c00 - 3f657c00 (ACPI data) [0.00] BIOS-e820: 3f657c00 - 4000 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - fed00400 (reserved) [0.00] BIOS-e820: fed2 - feda (reserved) [0.00] BIOS-e820: fee0 - fef0 (reserved) [0.00] BIOS-e820: ffb0 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 154) 0 entries of 3200 used [0.00] Entering add_active_range(0, 256, 259665) 1 entries of 3200 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP (v002 DELL ) @ 0x000febf0 [0.00] ACPI: XSDT (v001 DELLB8K 0x0014 ASL 0x0061) @ 0x000fd085 [0.00] ACPI: FADT (v003 DELLB8K 0x0014 ASL 0x0061) @ 0x000fd19d [0.00] ACPI: SSDT (v001 DELLst_ex 0x1000 INTL 0x20050624) @ 0xfffdafc7 [0.00] ACPI: MADT (v001 DELLB8K 0x0014 ASL 0x0061) @ 0x000fd291 [0.00] ACPI: BOOT (v001 DELLB8K 0x0014 ASL 0x0061) @ 0x000fd323 [0.00] ACPI: MCFG (v001 DELLB8K 0x0014 ASL 0x0061) @ 0x000fd34b [0.00] ACPI: HPET (v001 DELLB8K 0x0014 ASL 0x0061) @ 0x000fd389 [0.00] ACPI: SLIC (v001 DELLB8K 0x0014 ASL 0x0061) @ 0x000fd3c1 [0.00] ACPI: DSDT (v001 DELLdt_ex 0x1000 INTL 0x20050624) @ 0x [0.00] No NUMA configuration found [0.00] Faking a node at -3f651000 [0.00] Entering add_active_range(0, 0, 154) 0 entries of 3200 used [0.00] Entering add_active_range(0, 256, 259665) 1 entries of 3200 used [0.00] Bootmem setup node 0 -3f651000 [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 - 154 [0.00] 0: 256 - 259665 [0.00] On node 0 totalpages: 259563 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1091 pages reserved [0.00] DMA zone: 2847 pages, LIFO batch:0 [0.00] DMA32 zone: 3494 pages used for memmap [0.00] DMA32 zone: 252075 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] ACPI: PM-Timer IO Port: 0x808 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [0.00] Processor #1 [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x05] disabled) [0.00] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x07] disabled) [0.00] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled) [0.00] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x01] disabled) [0.00] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled) [0.00] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] disabled) [0.00] ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1]) [0.00] ACPI: IOAPIC (id[0x08] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 8, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] ACPI: IRQ9 used by override. [0.00] Setting APIC routing to physical flat [0.00] ACPI: HPET id: 0x8086a201 base: 0xfed0 [0.00] Using ACPI (MADT) for SMP configuration information [0.00] Nosave
Re: [linux-dvb] [RFC-final] videobuf tree
On 10/3/07, Michael Krufky [EMAIL PROTECTED] wrote: On 10/3/07, Ricardo Cerqueira [EMAIL PROTECTED] wrote: I've tested this with a blackbird board (HVR-1300), both with the MPEG encoder and analog. - MPEG is working fine, even after merging in Mike Krufky's and my own blackbird patches for audio. No drops I can see. - Raw analog video is OK - Analog audio through cx88-alsa (which uses videobuf) is also fine. - Playing raw and MPEG simultaneosly works (as long as raw is started first, something that's also happening with the old videobuf) Summarizing: there's no visible performance or functional difference between the new and the old videobuf implementations on the hardware I have available to test. Reviewed-by: Ricardo Cerqueira [EMAIL PROTECTED] Ah, this is great news! I look forward to testing the new tree using cx88-blackbird, cx88-dvb and cx23885 over the upcoming weekend. I'll report whether I have the same results as soon as I can. I've tested the master branch under the following conditions: 1) cx88 raw analog video 2) cx88-blackbird encoded mpeg stream 3) cx88-dvb mpeg TS I'm pleased to report that the above three tests worked out successfully. However, cx23885 is now broken. Upon starting a DVB stream, the following OOPS is generated: [ 280.562598] Unable to handle kernel NULL pointer dereference at RIP: [ 280.562609] [881a0931] :videobuf_core:videobuf_mmap_setup+0x21/0xf0 [ 280.562637] PGD 204fc067 PUD 20504067 PMD 0 [ 280.562642] Oops: [1] SMP [ 280.562646] CPU 1 [ 280.562648] Modules linked in: binfmt_misc rfcomm l2cap bluetooth ppdev i915 drm cpufreq_userspace cpufreq_stats cpufreq_ondemand freq_table cpufreq_conse rvative cpufreq_powersave tc1100_wmi sony_acpi dev_acpi pcc_acpi sbs button ac asus_acpi backlight dock i2c_ec container battery video nls_utf8 ntfs nls_iso8 859_1 nls_cp437 vfat fat ipv6 parport_pc lp parport fuse mt2131 s5h1409 cx88_blackbird cx2341x rtc_isl1208 ir_kbd_i2c snd_seq_dummy snd_seq_oss dvb_pll lgdt3 30x snd_hda_intel snd_seq_midi tuner snd_hda_codec cx88_dvb cx88_vp3054_i2c tea5767 tda8290 tuner_simple mt20xx cx23885 cx88_alsa snd_pcm_oss snd_mixer_oss v ideobuf_dvb snd_pcm dvb_core snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd cx8800 cx8802 cx88xx soundcore pcspkr psmouse serio_raw ir_c ommon compat_ioctl32 i2c_algo_bit tveeprom i2c_core iTCO_wdt iTCO_vendor_support videodev v4l2_common v4l1_compat videobuf_dma_sg videobuf_core btcx_risc shp chp pci_hotplug snd_page_alloc intel_agp af_packet tsdev evdev ext3 jbd mbcache sg sd_mod sr_mod cdrom usbhid hid ehci_hcd ahci libata scsi_mod uhci_hcd e100 0 usbcore thermal processor fan fbcon tileblit font bitblit softcursor vesafb cfbcopyarea cfbimgblt cfbfillrect capability commoncap [ 280.562748] Pid: 8369, comm: cx23885[0] dvb Not tainted 2.6.20-16-generic #2 [ 280.562752] RIP: 0010:[881a0931] [881a0931] :videobuf_core:videobuf_mmap_setup+0x21/0xf0 [ 280.562764] RSP: 0018:81001bc21e40 EFLAGS: 00010282 [ 280.562767] RAX: RBX: 810033bc6020 RCX: 0002 [ 280.562770] RDX: 6000 RSI: 0020 RDI: 810033bc6020 [ 280.562774] RBP: 810033bc6010 R08: 81001bc2 R09: [ 280.562778] R10: 0013 R11: 80231700 R12: 81001b37db98 [ 280.562780] R13: 6000 R14: 0020 R15: 0002 [ 280.562784] FS: () GS:8100011e0ec0() knlGS: [ 280.562788] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [ 280.562790] CR2: CR3: 2057e000 CR4: 06e0 [ 280.562794] Process cx23885[0] dvb (pid: 8369, threadinfo 81001bc2, task 81001f152100) [ 280.562797] Stack: 006f 80265bbb 81001bc21f00 810033bc6020 [ 280.562805] 810033bc6010 81001b37db98 810033bc6178 810033bc6020 [ 280.562812] 810033bc6220 881a0a7b 00011bc21ed0 8028b434 [ 280.562818] Call Trace: [ 280.562831] [80265bbb] thread_return+0x0/0xf5 [ 280.562878] [881a0a7b] :videobuf_core:videobuf_read_start+0x7b/0x150 [ 280.562889] [8028b434] __wake_up_common+0x44/0x80 [ 280.562923] [882943f6] :videobuf_dvb:videobuf_dvb_thread+0x46/0x170 [ 280.562951] [882943b0] :videobuf_dvb:videobuf_dvb_thread+0x0/0x170 [ 280.562957] [802a3170] keventd_create_kthread+0x0/0x90 [ 280.562968] [80233fa9] kthread+0xd9/0x120 [ 280.563006] [80261ec8] child_rip+0xa/0x12 [ 280.563020] [802a3170] keventd_create_kthread+0x0/0x90 [ 280.563082] [80233ed0] kthread+0x0/0x120 [ 280.563091] [80261ebe] child_rip+0x0/0x12 [ 280.563112] [ 280.563114] [ 280.563114] Code: 8b 30 81 fe 03 10 26 12 74 17 ba 03 10 26 12 48 c7 c7 a0 1c [ 280.563129] RIP [881a0931] :videobuf_core:videobuf_mmap_setup+0x21
Re: [linux-dvb] [RFC-final] videobuf tree
Trent Piepho wrote: On Sat, 6 Oct 2007, Michael Krufky wrote: I've tested the master branch under the following conditions: 1) cx88 raw analog video 2) cx88-blackbird encoded mpeg stream 3) cx88-dvb mpeg TS I'm pleased to report that the above three tests worked out successfully. However, cx23885 is now broken. Upon starting a DVB stream, the following OOPS is generated: Did you get this recent patch? changeset: 6284:7dba1f554c4a user:Trent Piepho [EMAIL PROTECTED] date:Thu Oct 04 01:28:45 2007 -0700 summary: cx23885: Update to new videobuf code You can compile cx23885 with no warnings without the patch, because the kernel still provides the old video_buf_dvb include files. Yes... I cloned today's master branch, including your changeset cited above. I was sure to do 'make rminstall' in an older tree, to remove all traces of the older video_buf module before installing the new modules. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH, RFC] KWorld ATSC-115 detection
On 9/27/07, Eric Sandeen [EMAIL PROTECTED] wrote:
So, just got my shiny new Kworld ATSC-115 card in the mail.
Any desire for a patch to actually detect the new PCI ID, even
though I guess it's pretty much the same card as the ATSC 110?
Full-on pedantic patch below, I know not all of this needs to be
duplicated if it's truly identical hardware
Comments? (build load tested only, not currently near a signal
to test it but I assume it's fine, since using the card=90 module
option is reported to work)
Thanks,
-Eric
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
@@ -4123,6 +4147,12 @@ struct pci_device_id saa7134_pci_tbl[] =
.driver_data = SAA7134_BOARD_KWORLD_ATSC110,
},{
.vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133, /* SAA7135HL */
+ .subvendor= 0x17de,
+ .subdevice= 0x7352,
+ .driver_data = SAA7134_BOARD_KWORLD_ATSC115,
+ },{
+ .vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
.subvendor= 0x1461,
.subdevice= 0x7360,
Eric,
You can remove every hunk of your patch except for the one above, but
instead link that subsystem ID to SAA7134_BOARD_KWORLD_ATSC110 ...
The two cards are the same, as far as the driver is concerned.
Will you be able to test ATSC, QAM and NTSC?
Cheers,
Mike
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DViCO Dual Digital 4 and remote
Bonne Eggleston wrote: Hi All, I just got this device and was able to get the tv section working really quickly thanks to all your fine efforts. I'd like to get the remote working, so if there is anything I can do to help out I'd be glad to. I'm a fairly proficient programmer so any pointers to get me started would be a great help. I'll post a new test patch for the remote within the next few weeks -- I know how it works now, but don't have a lot of time... Stay tuned. -Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/14/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: - The hybrid tuner support, that where your requirement, when all those discussions started, were already added to the subsystem. So now, an hybrid tuner can be accessed by both DVB and V4L devices; It's far more complex as the thing which is implemented there. The only thing that has been implemented is that one moduleformat can be loaded by the v4l and by the dvb framework nothing else at the moment. I told you at the kernel summit about that and I think you knew about that before. Just to quote some text: Right now, a separate instance of the driver is used for analog / digital tuning. In order to use a single instance, we will have to store a pointer to the dvb_frontend structure on the bridge level, but there are various other prerequisites that must be dealt with before we get to that point. We _will_ get there though, eventually. Maybe it is still not perfect. Feel free to improve it. Several people from the community, including me, already offered you help to add your driver, reworking on the 5% of the stuff that aren't compatible with the V4L/DVB core API design. For clarification, Markus is quoting me, above. The idea is to eventually store a pointer to the dvb_frontend structure on the bridge level to be used as a single entry point between the analog and digital subsystems. However, we are not yet ready for this, as the refactoring process has a lot more to be done beforehand. Phase 1 of the refactoring was to implement the core changes required for a single module to be used by both v4l and dvb, and to convert the existing tuner modules to the new internal API. Phase 2, a work in progress, involves the removal of duplicated code. For example, the current code in the master branch still has tda8275 / tda8275a analog code inside of tda8290.c, where the digital tuning code is in tda827x.c ... This was resolved in this changeset: Move all tda8275/8275a tuning code from tda8290 module into tda827x module http://linuxtv.org/hg/~mkrufky/philipsNXP/rev/09c2e16a8cdd This code is working fine, and I have it pushed to linuxtv.org for the sake of testing. I have not requested merge to master because I still have some cleanups to do, and I do not want this to go to 2.6.24. (side note: basic support for TDA8295 + TDA18271 has been added to my philipsNXP tree, as well) Tuner-simple and dvb-pll will have to undergo a similar treatment, and it's not going to happen overnight. But I *am* working on it. I've outlined a basic roadmap to the refactoring plans in my original RFC: http://linuxtv.org/pipermail/linux-dvb/2007-August/019950.html What I didn't mention in that RFC, however, is the method in which I plan to remove the multiple instantiations of the tuner code for a single piece of hardware, by moving the dvb_frontend pointer to the bridge level. Since this change depends on the other refactoring to be completed first, I found it unnecessary to explain this in detail at this point. When the time comes, a new RFC will be sent out to deal with that matter. There is no reason why the Xceive driver cannot be merged into the current development tree using the hybrid tuner framework as it stands today. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem building newest DVB Drivers
Dennis Schwan wrote: Hi, i wanted to install the newest DVB-drivers but during the make i get an error (running ubuntu dapper): |CC [M] /usr/src/v4l-dvb/v4l/cx88-alsa.o /usr/src/v4l-dvb/v4l/cx88-alsa.c:42:23: error: sound/tlv.h: No such file or directory /usr/src/v4l-dvb/v4l/cx88-alsa.c:662: error: syntax error before '-' token /usr/src/v4l-dvb/v4l/cx88-alsa.c:662: warning: type defaults to 'int' in declaration of 'DECLARE_TLV_DB_SCALE' /usr/src/v4l-dvb/v4l/cx88-alsa.c:662: warning: function declaration isn't a prototype /usr/src/v4l-dvb/v4l/cx88-alsa.c:662: warning: type qualifiers ignored on function return type /usr/src/v4l-dvb/v4l/cx88-alsa.c:667: error: 'SNDRV_CTL_ELEM_ACCESS_TLV_READ' undeclared here (not in a function) /usr/src/v4l-dvb/v4l/cx88-alsa.c:672: error: unknown field 'tlv' specified in initializer /usr/src/v4l-dvb/v4l/cx88-alsa.c:672: error: 'snd_cx88_db_scale' undeclared here (not in a function) make[3]: *** [/usr/src/v4l-dvb/v4l/cx88-alsa.o] Error 1 make[2]: *** [_module_/usr/src/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.15-26-server' make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/v4l-dvb/v4l' make: *** [all] Error 2 Dennis, Kernel backwards compat has been broken in the master branch against older kernels... Until it's fixed, you can use one of my devel trees, which still builds fine against older kernels... Instead, try: http://linuxtv.org/hg/~mkrufky/dvb-pll You shouldn't have any problems there. Cheers, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] TUV1236d / dvb-pll: rf input switching via module option
David Engel wrote:
On Mon, Sep 10, 2007 at 12:12:01PM -0500, David Engel wrote:
Unfortunately, this does not allow for REVERSING the input selection --
this will only force it to use one or the other in digital mode. If
anybody has some ideas as to how to reverse the default selection in a
clean way, I am open to suggestions.
The attached patch, is completely untested (I didn't even try
compiling it), but it should be close.
Take two, with the patch.
David,
This is the same thing I did in my tree, but just didn't push it to the
repository.
This would work, but it doesn't cover all possible cases. For instance,
what if there was a tuner with three rf inputs? I don't think that such
a device exists on any supported hardware, but you never know.
This solution is fine with me, for the meanwhile... if you could test
it, would be nice :-)
-Mike
diff -r b7fa7c4598ac linux/drivers/media/dvb/frontends/dvb-pll.c
--- a/linux/drivers/media/dvb/frontends/dvb-pll.c Sun Sep 09 12:00:45
2007 -0400
+++ b/linux/drivers/media/dvb/frontends/dvb-pll.c Mon Sep 10 11:58:50
2007 -0500
@@ -49,9 +49,9 @@ module_param(debug, int, 0644);
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, enable verbose debug messages);
-static unsigned int input[DVB_PLL_MAX] = { [ 0 ... (DVB_PLL_MAX-1) ] = 0 };
+static int input[DVB_PLL_MAX] = { [ 0 ... (DVB_PLL_MAX-1) ] = 0 };
module_param_array(input, int, NULL, 0644);
-MODULE_PARM_DESC(input,specify rf input choice, 0 for autoselect
(default));
+MODULE_PARM_DESC(input,specify rf input choice, 0 for autoselect (default),
-1 for autoselect reversed);
static unsigned int id[DVB_PLL_MAX] =
{ [ 0 ... (DVB_PLL_MAX-1) ] = DVB_PLL_UNDEFINED };
@@ -399,9 +399,10 @@ static void tuv1236d_rf(struct dvb_front
const struct dvb_frontend_parameters *params)
{
struct dvb_pll_priv *priv = fe-tuner_priv;
- unsigned int new_rf = input[priv-nr];
-
- if ((new_rf == 0) || (new_rf 2)) {
+ int new_rf = input[priv-nr];
+
+ if ((new_rf = 0) || (new_rf 2)) {
+ int reverse = (new_rf == -1);
switch (params-u.vsb.modulation) {
case QAM_64:
case QAM_256:
@@ -411,6 +412,8 @@ static void tuv1236d_rf(struct dvb_front
default:
new_rf = 2;
}
+ if (reverse)
+ new_rf = 3 - new_rf;
}
switch (new_rf) {
@@ -856,6 +859,9 @@ struct dvb_frontend *dvb_pll_attach(stru
printk( %d-%04x, i2c_adapter_id(i2c), pll_addr);
printk(: tuner rf input will be );
switch (input[priv-nr]) {
+ case -1:
+ printk(autoselected reversed\n);
+ break;
case 0:
printk(autoselected\n);
break;
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] TUV1236d / dvb-pll: rf input switching via module option
Eric, Eric Sandeen wrote: Michael Krufky wrote: For now, the only thing that I'm asking you to test is whether you are able to switch the input selection using the module option. Works for me. for dvb_pll, input=1 on the ATSC-110 is the same as what I get with no options, i.e. the bottom connector. input=2 gives me the top connector. :-) Thanks for testing! Would a printk about which input is being used for each card at startup time be useful? Yes. I added it to the tree. Please pull from: http://linuxtv.org/hg/~mkrufky/dvb-pll Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] TUV1236d / dvb-pll: rf input switching via module option
Eric Sandeen wrote: Michael Krufky wrote: Please provide some feedback after testing this tree. The changes in question are: http://linuxtv.org/hg/~mkrufky/dvb-pll - dvb-pll: pass fe pointer into dvb_pll_configure() and set() functions - dvb-pll: store instance ID in dvb_pll_priv structure - dvb-pll: add module option to specify rf input - dvb-pll: add module option to force dvb-pll desc id (for debug use only) it's 1am so not doing a whole lot, but set up all modules from that repo, and my mythbox came up happy with the QAM input working on the bottom connector of my Kworld ATSC-110. I'll try the option to switch them tomorrow anything else you'd like me to test with this card? Eric, For now, the only thing that I'm asking you to test is whether you are able to switch the input selection using the module option. Thanks, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Port of em28xx and xc3028 to new hybrid tuner framework.
Aidan Thornton wrote: On 9/7/07, Michael Krufky [EMAIL PROTECTED] wrote: Please take a look at the xc3028-fe.c file in the following patch: http://www.linuxtv.org/~mkrufky/xc-bluebird.patch You can use the logic used in that patch to determine ATSC / DVB-T / etc ...we might want to change this after multiproto is merged (if that happens anytime soon), because better options may be available at that point. I was thinking of redoing that xc3028-fe module to include analog support soon, but if you're going to to work on it instead, it makes life easier for me :-) Thanks. That looks like roughly how I suspected it would work. Unfortunately, I don't currently have any (practical) way of testing DVB-T at the moment due to poor signal strength and a lack of a cable between the loft aerial and anywhere. On 9/7/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: The tm6000 has a tuner-xc2028 driver that actually works also with xc3028, for tm6000. It contains both DVB and V4L logic, although yet not ported to the hybrid driver approach. IMO, shouldn't be hard to port though. It won't be easy. Apparently, there's currently no way of sharing state between the analog portion of the driver and the digital one using the hybrid approach. (It looks like a separate instance of the driver is used for each, and communication with the analog one seems to be severely limited by the API.) Right now, a separate instance of the driver is used for analog / digital tuning. In order to use a single instance, we will have to store a pointer to the dvb_frontend structure on the bridge level, but there are various other prerequisites that must be dealt with before we get to that point. We _will_ get there though, eventually. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Port of em28xx and xc3028 to new hybrid tuner framework.
Aidan Thornton wrote: Hi, In the hope of having a driver that fits better with the v4l-dvb trunk than the currently available options, I've ported the analog parts of Markus Rechberger's em28xx and xc3028 drivers to the new hybrid tuner framework. (The analog bits are similar enough to his framework that this was fairly easy.) It hasn't been tested with anything other than the analog TV in on my HVR-900 (USB ID 2040:6500), so YMMV. The repository is at http://www.makomk.com/hg/v4l-dvb-makomk for anyone feeling brave. Digital is not supported as yet - I haven't even tried to get em2880_dvb working, and the xc3028 support is probably broken. (I'm unsure how to get the bandwidth setting in xc3028 and how to tell if the client wants DVB-T, ATSC or something else.) Any suggestions and comments are welcome. Please take a look at the xc3028-fe.c file in the following patch: http://www.linuxtv.org/~mkrufky/xc-bluebird.patch You can use the logic used in that patch to determine ATSC / DVB-T / etc ...we might want to change this after multiproto is merged (if that happens anytime soon), because better options may be available at that point. I was thinking of redoing that xc3028-fe module to include analog support soon, but if you're going to to work on it instead, it makes life easier for me :-) Cheers, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [RFC] TUV1236d / dvb-pll: rf input switching via module option
David Engel wrote: The standard driver as of Linux v2.6.21 does analog and 8VSB on the top input and QAM on the bottom input. My desired behavior is analog and QAM on one input and 8VSB on the other. No problem. It was an easy enough driver hack to make it do what I wanted. Others might be interested in this change too, so is there any willingness from the core DVB maintainers to accept a patch to make this configurable via a module parameter? If so, would you like one global setting for all cards or one setting for each card? I know I took a while with this... I was working on tuner refactoring and didn't have time. Meanwhile, if we do any kind of module option for rf input selection, it must be one setting for each card. Please test the following mercurial tree: http://linuxtv.org/hg/~mkrufky/dvb-pll After building installing the new modules, do: modinfo dvb-pll ...to view the new module options. If you have only one card in the system, you may do: modprobe dvb-pll input=1 ... then: modprobe cx88-dvb -or- modprobe saa7134-dvb After doing the above, your card will use input #1 regardless of whether you are using VSB or QAM. If, however, you have multiple cards in the system, and the ATSC11[05] / HDTV Wonder is the second DVB card, then instead do: modprobe dvb-pll input=0,2 ...to specify that the dvb-pll module should autoselect the input used for the first card, and use input #2 for the second card. Unfortunately, this does not allow for REVERSING the input selection -- this will only force it to use one or the other in digital mode. If anybody has some ideas as to how to reverse the default selection in a clean way, I am open to suggestions. If this works correctly, (and I have no doubt that it will) I can add the same option to the tuner-simple module, to allow the user to choose the rf input used for analog tv as well. Please also note: Pass debug=1 to dvb-pll, in order for dvb-pll to show you the instance ID of the tuv1236d. If you have multiple cards in the system, this will be helpful to determine the order of the input option array to pass via modprobe. debug output will look like this: [ 3023.695903] dvb-pll[0] 0-0061: id# 11 (LG TDVS-H06xF) attached, autodetected I also added a module option to force dvb-pll to use a dvb_pll_desc other than the one picked by default. This is useful in some cases, where the vendor may release an alternate revision of the hardware using a different tuner, but without changing the pci subsystem / usb device ids. This option should be used for debugging purposes, ONLY. Please provide some feedback after testing this tree. The changes in question are: http://linuxtv.org/hg/~mkrufky/dvb-pll - dvb-pll: pass fe pointer into dvb_pll_configure() and set() functions - dvb-pll: store instance ID in dvb_pll_priv structure - dvb-pll: add module option to specify rf input - dvb-pll: add module option to force dvb-pll desc id (for debug use only) dvb-pll.c | 145 +- 1 file changed, 102 insertions(+), 43 deletions(-) Cheers, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Asys P7131 Hybrid: DVB out of range
Andreas Oberritter wrote: @Manu: I am using hg anonymously and I don't even know whether I have write access or not. It would be nice if you can commit it. Everybody that had commit access to cvs also now has commit rights to hg/dvb-apps -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Patch for all tuners Beholder series 40x, 50x, 60x, M6, Columbus
Igor Kuznetsov wrote: Made support all tuners Beholder. Almost-not yet only support hardware MPEG decoders in a series of M6. Patch for all tuners Beholder series 40x, 50x, 60x, M6, and Columbus http://www.igk.ru/linux/files/v4l/v4l2-beholder-0.1.patch -- Igor Kuznetsov IgK Email: [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 6651879 Igor, First off, it looks like these devices are analog-only, so it would be more appropriate to send this to the video4linux mailing list (cc added) The patch is large, so I chopped it from the email. For those interested, please see the original email: http://linuxtv.org/pipermail/linux-dvb/2007-September/020256.html Secondly, your patch introduces broken whitespace all over. Tabs should be used for leading spacing, not a series of spaces. We prefer for new cards to be added to the end of the card array-- not dispersed randomly throughout. It looks like your large patch includes work from multiple contributors, based on the different names that I see commented within the card array additions. You did not provide a sign-off on your work. You should probably also collect sign-off's from those other developers involved in this work. For more information on sign-off, and patch submissions to the v4l/dvb projects in general, please see: http://linuxtv.org/hg/v4l-dvb/file/tip/README.patches The preferred method would be to clone the latest version of the repository from linuxtv.org, apply your patch to that tree, test it, and then generate a new diff as follows: hg diff new.patch Then, send in that new patch to the mailing lists. Again, when you send in the new patch with sign-offs , please be sure to include the video4linux mailing list: Linux and Kernel Video [EMAIL PROTECTED] Cheers, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] cx88-dvb: fix nxt200x rf input switching broke my tuner? :)
-Original Message- From: CityK [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 05, 2007 1:33 PM To: Nathan Faust Cc: linux-dvb@linuxtv.org Subject: Re: [linux-dvb] cx88-dvb: fix nxt200x rf input switching broke my tuner? :) Nathan Faust wrote: Hi, I've notice the same thing with my Kworld ATSC-110. I'm running Ubuntu 7.10, 2.6.22-10-generic, x86_64. I guess it is a change in the 2.6.22 kernel. Is there anyway to change this back so that QAM and NTSC inputs are the same? They should be the same now -- that was what the change was all about. By default now, the top RF input should be 8VSB and the bottom should be QAM analog (both ota and cable). Nathan Faust wrote: CityK, Thanks for your reply, but that is not what I'm seeing in MythTV and TVTime for /dev/video0. I'm getting signal from /dev/video0 when I use the upper input, not the lower one. I haven't trying tuning 8VSB, but as for the QAM input, that seems to be working as expected. Maybe I should look at the driver config for input select in SAA7134 or swap the input selection lines for VSB and QAM in the dvb code? After looking at the input selection code in nxt200x.c, QAM and VSB, it looks like if I switch these lines it will swap the inputs. //QAM - state-config-set_pll_input(buf+1, 1); + state-config-set_pll_input(buf+1, 0); //VSB - state-config-set_pll_input(buf+1, 0); + state-config-set_pll_input(buf+1, 1); Am I correct? I am confused as to what these lines do if (state-config-set_ts_params) state-config-set_ts_params(fe, 1); -- what the front-end parameter 0 or 1 mean. Nathan, Please do not top-quote As per your description above, you are correct... HOWEVER, now I understand your issue -- you are running old code. If you update to the latest v4l/dvb modules via linuxtv.org mercurial, you will find that functionality has been restored as per your desire. Please see http://linuxtv.org/repo ...for instructions to upgrade your v4l/dvb modules. Good Luck, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb-usb module load problem, DVB: Unable to find symbol lgdt330x_attach()
Andrew Burgess wrote: kernel: 2.6.22-rt9 I had to rmmod the dvb stuff, load lgdt330x manually, then reload dvb Then everything was fine Some more detail would be better... what do you mean, reload dvb ? Please show us exactly what commands you ran. I've booted 2.6.22 before without this problem, maybe it was different because the dvico was warm, usually I power cycle everything Can you provide a step-by-step on exactly how to reproduce this problem? Hope this is the correct list Andrew It's the correct list. :-) Sep 1 07:47:06 cichlid kernel: dvb-usb: found a 'DViCO FusionHDTV5 USB Gold' in warm state. Sep 1 07:47:06 cichlid kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Sep 1 07:47:06 cichlid kernel: DVB: registering new adapter (DViCO FusionHDTV5 USB Gold). Sep 1 07:47:07 cichlid kernel: DVB: Unable to find symbol lgdt330x_attach() Sep 1 07:47:07 cichlid kernel: dvb-usb: no frontend was attached by 'DViCO FusionHDTV5 USB Gold' Sep 1 07:47:07 cichlid kernel: input: IR-receiver inside an USB DVB receiver as /class/input/input3 Sep 1 07:47:07 cichlid kernel: dvb-usb: schedule remote query interval to 100 msecs. Sep 1 07:47:07 cichlid kernel: dvb-usb: DViCO FusionHDTV5 USB Gold successfully initialized and connected. Sep 1 07:47:07 cichlid kernel: usbcore: registered new interface driver dvb_usb_cxusb Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] add read_signal_strength function to dvb_tuner_ops
Henk wrote:
Of course from a kernel perspective it is a simple addition, but where
should we form a userspace perspective decide on which signal strength
function to use?
I don't think an extra interface should be needed here.
Henk,
This is an addition to the *internal* API -- This means no change to
userspace.
For example if a demodulator is unable to provide signal strengths on
his own there is always the possibility to request it from the tuner
(if available) and report that.
That's the point -- the addition of this function to dvb_tuner_ops will
expose this functionality of the tuner driver to the demod driver.
For example how about this alternative. In the demod driver you could use:
int demod_get_rf_strength(struct dvb_frontend *fe, u16 *strength)
{
/* No I dont support this so see if we can get something from the tuner */
if ( fe-ops.tuner_ops.get_rf_strength(fe, strength) )
return fe-ops.tuner_ops.get_rf_strength(fe, strength);
return -ENOSYS;
}
This is exactly what I was describing... The entire point, however, is
that there is no tuner_ops.get_rf_strength as of yet. I was proposing
to add this new function pointer to struct dvb_tuner_ops, an internal
structure only available *within* the kernel..
That way you can decide in the demod driver what's the best way on how
to deal with this specific hardware feature.
Thank you for agreeing with me ;-)
Henk wrote:
Sorry,
My mistake, I was under the impression that read_rf_strength was
already a tuner interface.
:-P
So in that case it would be usefull to have included in the tuner interface.
Still policy on whether it is reported to userspace should reside
within the demod driver as outlined below I think.
exactly.
As for the name I think it would cause less confusion to call it
similar to the function thats used in struct frontend
(get_signal_strength).
Manu and I together decided against that. get_rf_strength is more
appropriate, since he plans to add similar functions later on for
reading IF strength amongst other values.
Thank you for your comments.
Regards,
Mike
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] add read_signal_strength function to dvb_tuner_ops
Michael Krufky wrote: struct dvb_frontend_ops contains a function pointer for reading signal strength from the demodulator, however, it would also be useful to be able to read the signal strength from the tuner, itself. As of now, in dvb_tuner_ops, we only have the following function for status: int (*get_status)(struct dvb_frontend *fe, u32 *status); The usability of this function is rather limited, and currently only provides a mechanism for reading a limited amount of bits. The current status bits are as follows: #define TUNER_STATUS_LOCKED 1 #define TUNER_STATUS_STEREO 2 ...this doesn't really lend itself for a useful signal strength reading. I can cite two examples of how this would be useful in the current codebase: 1) Some demodulators do not directly provide signal strength readings. For example, lgdt330x. In order to provide some sort of measurement, other values are used to arrive at an estimated reading. If we had a read_signal_strength function available from the tuner driver, such demodulator drivers that are otherwise unable to provide this functionality directly would be able to read the signal strength from the tuner driver, and either pass on that value, or use it in its calculation of status readings. 2) The analog tuner system accesses the tuner modules directly, and would benefit greatly from having such functionality available to be able to read signal strength from the tuner. Manu and I spoke about this on irc today, and we decided that it would be better to name this function, get_rf_strength ... So, the change would be as follows: --- v4l-dvb.orig/linux/drivers/media/dvb/dvb-core/dvb_frontend.h +++ v4l-dvb/linux/drivers/media/dvb/dvb-core/dvb_frontend.h @@ -92,6 +92,7 @@ #define TUNER_STATUS_LOCKED 1 #define TUNER_STATUS_STEREO 2 int (*get_status)(struct dvb_frontend *fe, u32 *status); + int (*get_rf_strength)(struct dvb_frontend *fe, u16 *strength); /** These are provided seperately from set_params in order to facilitate silicon * tuners which require sophisticated tuning loops, controlling each parameter seperately. */ This is a rather trivial addition, so I doubt there will be any debate on this matter. I plan to move forward with this tonight, unless anybody is opposed. Any acks would still be appreciated, of course :-) Regards, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [RFC] add read_signal_strength function to dvb_tuner_ops
struct dvb_frontend_ops contains a function pointer for reading signal strength from the demodulator, however, it would also be useful to be able to read the signal strength from the tuner, itself. As of now, in dvb_tuner_ops, we only have the following function for status: int (*get_status)(struct dvb_frontend *fe, u32 *status); The usability of this function is rather limited, and currently only provides a mechanism for reading a limited amount of bits. The current status bits are as follows: #define TUNER_STATUS_LOCKED 1 #define TUNER_STATUS_STEREO 2 ...this doesn't really lend itself for a useful signal strength reading. I can cite two examples of how this would be useful in the current codebase: 1) Some demodulators do not directly provide signal strength readings. For example, lgdt330x. In order to provide some sort of measurement, other values are used to arrive at an estimated reading. If we had a read_signal_strength function available from the tuner driver, such demodulator drivers that are otherwise unable to provide this functionality directly would be able to read the signal strength from the tuner driver, and either pass on that value, or use it in its calculation of status readings. 2) The analog tuner system accesses the tuner modules directly, and would benefit greatly from having such functionality available to be able to read signal strength from the tuner. I propose the following addition to the internal API. Please respond with an ack, and / or any comments that you may have: [PATCH] add read_signal_strength function to dvb_tuner_ops Signed-off-by: Michael Krufky [EMAIL PROTECTED] --- linux/drivers/media/dvb/dvb-core/dvb_frontend.h |1 + 1 file changed, 1 insertion(+) --- v4l-dvb.orig/linux/drivers/media/dvb/dvb-core/dvb_frontend.h +++ v4l-dvb/linux/drivers/media/dvb/dvb-core/dvb_frontend.h @@ -92,6 +92,7 @@ #define TUNER_STATUS_LOCKED 1 #define TUNER_STATUS_STEREO 2 int (*get_status)(struct dvb_frontend *fe, u32 *status); + int (*read_signal_strength)(struct dvb_frontend* fe, u16* strength); /** These are provided seperately from set_params in order to facilitate silicon * tuners which require sophisticated tuning loops, controlling each parameter seperately. */ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1
Mauro Carvalho Chehab wrote: Hi Michael, Em Seg, 2007-08-27 às 10:02 -0300, Mauro Carvalho Chehab escreveu: I should review the source code later today. Ok. Almost everything looked fine to my eyes. I have just one comment, about the changesets that added the MODULE_DESCRIPTION and MODULE_LICENSE macros, like on this changeset: http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-1/rev/ff52de4a4da1 This is required at the moment those files will be converted to modules. However, as, currently, they are still part of tuner, you shouldn't add those lines. Actually, the driver is split into separate modules as of the changeset entitled, tuner: alter build to produce separate modules I could have made those MODULE_DESCRIPTION and MODULE_LICENSE changes later on, but it has the same outcome, either way. On a future changeset where those drivers will be splat, you should also add MODULE_AUTHOR macro. Will add this right now. So, I have some comments about that future patch: For tea5767 and tea5761, please add: MODULE_AUTHOR(Mauro Carvalho Chehab [EMAIL PROTECTED]) OK. For tuner-simple, mt20xx and tda8290, I did some research. Those files started when Gerd split tuner into smaller drivers, removing tuner.c file, at -hg changeset 1578: http://linuxtv.org/hg/v4l-dvb/file/c9083c80e2f0/linux/drivers/media/video/mt20xx.c Unfortunately, -hg migration didn't preserved the full history (the tuner.c removal changeset is not there). However, we can see the other side of the history at CVS: http://linuxtv.org/cgi-bin/viewcvs.cgi/video4linux/Attic/tuner.c?root=v4lview=markup The original module author for tuner.c is marked there as: MODULE_AUTHOR(Ralph Metzler, Gerd Knorr, Gunther Mayer); This authorship line were preserved at tuner-core.c. The splitting work, however, were done by Gerd. So, IANAL, but, to respect GPL, I can see some ways: a) Preserve the original tuner.c author at the splat drivers; b) Add just Gerd Knorr to the splat drivers, and adding a comment, at the header, stating that mt20xx and tuner-simple are splat drivers originated from tuner.c, originally written by Ralph Metzler, Gerd Knorr, Gunther Mayer. c) Ask the authors for their wishes (as both Gerd and Ralph are likely subscribed at the ML, probably they'll let us know if they opt for an specific way. I'm not sure if Gunther is subscribed). For tda8290, maybe Hartmut should also be added, since he reworked some major parts of the driver logic: http://linuxtv.org/hg/v4l-dvb/rev/399222ddb2d9 OK -- I have taken care of the above, and pushed the changesets into my tree, along with the warning of obsolete i2c address usage. I will issue a pull request tomorrow. Thanks for your review and testing. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1
Mauro Carvalho Chehab wrote: You say, there weren't any log messages from tea5767 driver. -- This is because the tuner_info line was disabled -- I've re-enabled it just now, and push up the changeset. Please update your tree and test again -- I believe that the only issue here is the missing message from the tea5767 driver -- If you actually test radio, I believe that it will work. Please test again and get back to me. I tested it earlier today. All seems fine: the logs and the radio itself worked as expected. I should review the source code later today. I'm very glad to hear this! Thank you for testing, Mauro :-) Please let me know if you have any questions. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] (temp. solution) modprobe mantis stalls/hangs/freezes (Twinhan VP-1034 and ivtv)
Michel Verbraak wrote:
Hans Verkuil schreef:
On Sunday 26 August 2007 11:18:56 Michel Verbraak wrote:
Manu Abraham schreef:
Michel Verbraak wrote:
I have a Twinhan VP-1034 and I use the the latest hg, today, and
http://jusst.de/manu/mantis-v4l-dvb.tar.bz2 with kernel 2.6.22.1.
When I do a 'modprobe mantis' my prompt never returns. The machine
still is working.
Aug 26 11:08:32 recorder kernel: ivtv0: Autodetected Hauppauge WinTV
PVR-350 Aug 26 11:08:32 recorder kernel: tuner 2-0061: chip found @
0xc2 (ivtv i2c driver #0)
Aug 26 11:08:32 recorder kernel: ivtv0 i2c: i2c client attach
Aug 26 11:08:32 recorder kernel: mantis_i2c_write:
Address=[0x25] W[ ]
Aug 26 11:08:32 recorder kernel: mantis_i2c_write:
Address=[0x25] W[ 00 00 ]
Aug 26 11:08:32 recorder kernel: mantis_i2c_write:
Address=[0x25] W[ 00 ]
Aug 26 11:08:32 recorder kernel: mantis_i2c_read:
Address=[0x25] R[ 00 ]
Aug 26 11:08:32 recorder kernel: mantis_i2c_write:
Address=[0x25] W[ 00 01 === Interrupts[0001/0001]= [* I2C DONE *]
Ah, ivtv is probing for the saa7115 device. The saa7115 driver probes
among others i2c address 0x25, which is also used by the mantis.
And what's changed is that in kernel 2.6.21 the following change was
made to the saa7115.c driver:
static int saa711x_probe(struct i2c_adapter *adapter)
{
if (adapter-class I2C_CLASS_TV_ANALOG || adapter-class
I2C_CLASS_TV_DIGITAL)
return i2c_probe(adapter, addr_data, saa711x_attach);
return 0;
}
The TV_DIGITAL check was added, so now it is also suddenly used by the
mantis. Apparently added to support the Nexus CA.
The only solution at this time is to add the following module option
to saa7115: ignore=-1,0x25
This should ensure it that it ignores i2c address 0x25. Work is being
done to make probing unnecessary or at least much smarter, but that
will be quite a long transition period, most likely. For the time
being this is probably your only solution.
Regards,
Hans
Hans and Manu,
The mantis and ivtv module loaded ok with the following options for
saa7115 in /etc/modprobe.conf:
options saa7115 ignore=-1,0x25,-1,0x24,-1,0x21,-1,0x20
^^
Just change the -1 to the i2c bus ID of the mantis device, to prevent saa7115
from probing on the mantis bus. This way, it would not prevent successful
attachment to the ivtv i2c bus, and you wouldn't have to do the hack described
below.
Regards,
Mike
But ivtv is not working anymore and I get the following when I try to
watch live tv with mythtv:
ivtv0: i2c addr 0x21 not found for command 0xc0445624
ivtv0: i2c addr 0x21 not found for command 0xc008561c
ivtv1: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
ivtv1: Encoder revision: 0x02060039
cx25840 3-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
ivtv0: i2c addr 0x21 not found for command 0xc0445624
ivtv0: i2c addr 0x21 not found for command 0xc008561c
ivtv0: i2c addr 0x21 not found for command 0xc0445624
ivtv0: i2c addr 0x21 not found for command 0xc008561c
ivtv0: i2c addr 0x21 not found for command 0xc0445624
ivtv0: i2c addr 0x21 not found for command 0xc008561c
ivtv0: i2c addr 0x21 not found for command 0xc0cc5605
ivtv0: i2c addr 0x21 not found for command 0x40045613
ivtv0: i2c addr 0x21 not found for command 0x40045612
ivtv0: i2c addr 0x21 not found for command 0xc0cc5605
ivtv0: i2c addr 0x21 not found for command 0x40045613
ivtv0: i2c addr 0x21 not found for command 0x40045612
ivtv0: i2c addr 0x21 not found for command 0xc0cc5605
ivtv0: i2c addr 0x21 not found for command 0x40045613
ivtv0: i2c addr 0x21 not found for command 0x40045612
ivtv0: i2c addr 0x21 not found for command 0xc0cc5605
ivtv0: i2c addr 0x21 not found for command 0x40045613
ivtv0: i2c addr 0x21 not found for command 0x40045612
ivtv0: i2c addr 0x21 not found for command 0xc0cc5605
ivtv0: i2c addr 0x21 not found for command 0x40045613
ivtv0: i2c addr 0x21 not found for command 0x40045612
Probably because saa7115 is ignoring 0x21.
The vp-1034 is working allright.
What I did to get it working is removing the saa7115 module options.
Change the probe function in saa7115.c to:
static int saa711x_probe(struct i2c_adapter *adapter)
{
#ifdef I2C_CLASS_TV_ANALOG
if (adapter-class I2C_CLASS_TV_ANALOG)
#else
if (adapter-id == I2C_HW_B_BT848)
#endif
return i2c_probe(adapter, addr_data, saa711x_attach);
return 0;
}
Recompiled and both modules load without problems now and al is working
again. I know this is not the right work around for everybody but it
works for me.
Regards,
Michel.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
