Re: [linux-dvb] NXP 18211HDC1 tuner
Michael Krufky wrote: 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:TRAN SMISSION_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. 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 ___ 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 Thu, Mar 13, 2008 at 7:54 AM, Michael Krufky [EMAIL PROTECTED] wrote: 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 $ tzap -a 2 TEN Digital using '/dev/dvb/adapter2/frontend0' and '/dev/dvb/adapter2/demux0' tuning to 21950 Hz video pid 0x0200, audio pid 0x028a status 01 | signal | snr | ber | unc | $ femon -a 2 using '/dev/dvb/adapter2/frontend0' FE: Afatech AF9013 DVB-T (TERRESTRIAL) status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 01 | signal | snr | ber | unc | The status 00 lines were from before I started tzap, after I started tzap it did nothing for half a minute, then printed the status 01 line, then sat there for another half a minute, and I killed it at that point. My computer was also taking quite a few seconds to respond to me pressing the keyboard for the whole time I was tuning it. Jarryd. What shows in dmesg during the above? -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 Thu, Mar 13, 2008 at 8:09 AM, [EMAIL PROTECTED] wrote: Jarryd Beck wrote: On Thu, Mar 13, 2008 at 7:54 AM, Michael Krufky [EMAIL PROTECTED] wrote: 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 $ tzap -a 2 TEN Digital using '/dev/dvb/adapter2/frontend0' and '/dev/dvb/adapter2/demux0' tuning to 21950 Hz video pid 0x0200, audio pid 0x028a status 01 | signal | snr | ber | unc | $ femon -a 2 using '/dev/dvb/adapter2/frontend0' FE: Afatech AF9013 DVB-T (TERRESTRIAL) status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 01 | signal | snr | ber | unc | The status 00 lines were from before I started tzap, after I started tzap it did nothing for half a minute, then printed the status 01 line, then sat there for another half a minute, and I killed it at that point. My computer was also taking quite a few seconds to respond to me pressing the keyboard for the whole time I was tuning it. Jarryd. What shows in dmesg during the above? -Mike nothing new Jarryd. Then, please turn ON debug, repeat your tests, and post again with dmesg. I am not familiar with the af9015 driver, but for tda18271, set debug=1. (you must unload all modules first -- do 'make unload' in the v4l-dvb dir, then replug your device) -Mike
Re: [linux-dvb] NXP 18211HDC1 tuner
Jarryd Beck wrote: On Thu, Mar 13, 2008 at 8:14 AM, [EMAIL PROTECTED] wrote: Then, please turn ON debug, repeat your tests, and post again with dmesg. I am not familiar with the af9015 driver, but for tda18271, set debug=1. (you must unload all modules first -- do 'make unload' in the v4l-dvb dir, then replug your device) Sorry I'm unsure where to set debug. You have two options. option 1) after unloading all modules, load the given module with the debug insmod option. To see the available insmod options, use modinfo. For instance, 'modinfo tda18271' will show you the tuner drivers available options. Load the driver using the option, modprobe tda18271 debug=1 ... then plug in the stick. ... option 2) set the insmod option in your boot script. I run Ubuntu... to enable debug for my tuner. i edit /etc/modprobe.d/options and add the following line: options tda18271 debug=1 ...then unload all modules, and replug the stick... or reboot your machine, then replug the stick. regards, 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 Mon, 18 Feb 2008 23:44:33 -0500 Michael Krufky [EMAIL PROTECTED] wrote: 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 Michael, 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. The point is not saving memory. The point is that tuner-xc2028 requires just one callback. The callback should work properly for DTV, Analog and Radio. It makes no sense to have such generic callback inside cx88-dvb. It should be at cx88xx module, instead. I agree that there should be in a single callback. The appropriate place for this callback should be inside cx88-cards.c , and you'll have to include a prototype
Re: [linux-dvb] [v4l-dvb-maintainer] PULL request for a bunch of DiBcom-based changes
Nicolas Will wrote: On Fri, 2008-01-25 at 11:36 +0100, Patrick Boettcher wrote: Hi Mauro, Can you please pull from http://linuxtv.org/hg/~pb/v4l-dvb/ for a bunch of changes for DiBcom-based hardware. Mauro, Could you tell me once this is pulles, I'll clean-up the wiki. It was merged ~ 1 hour ago -- the repository is viewable at http://linuxtv.org/hg/v4l-dvb for all to see. -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: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 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HVR-1800 checkin
Barry Quiel wrote: Michael Krufky wrote: 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 I'd like to help test the analog portion of this card, but I have one concern. Are the code changes from the current trunk merged into this branch? I really don't want to lose the ATSC functionality. I'm not asking for a guarantee but a I'm pretty sure ATSC should be unaffected will do. Barry, #1 Please don't top quote. #2 Please don't drop cc's to a mailing list if that is where the mail originated, unless you have a question that is private in nature -- if you're asking a question that somebody else might also want the answer to, then you are dooming me to write more emails than are necessary... (cc added back to linux-dvb) Anyway, regardless of what code you're testing, so long as you keep the tree that worked for you last time somewhere on the side, you can always revert back to that tree. Analog video support added for the HVR1800 does _NOT_ break Digital video support. You can use digital and analog simultaneously. Be advised, however, that the cx23885 driver currently does not support DMA audio for analog preview, but audio does work for mpeg encoder mode. However, don't use the master branch today -- the build system is broken right now. Instead, use: http://linuxtv.org/hg/~mkrufky/build-fix Please send future correspondence to the mailing list. you may feel free to cc me, but remember the mailing list is most important. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] never do symbol_put(tunerfoo_attach);
Mauro and Michel, This changeset is wrong: http://linuxtv.org/hg/~mchehab/tm6000/rev/79f9210425e2 You should not symbol_put(xc3028_attach); , because you don't always know that we're dealing with that tuner. Instead, just do dvb_frontend_detach(fe) -- that will detach both tuner and frontend, and also lnb (for satellite devices). Cheers, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] never do symbol_put(tunerfoo_attach);
Michel Ludwig wrote: Hi Mike, On Fri 16 Nov 2007, [EMAIL PROTECTED] wrote: Mauro and Michel, This changeset is wrong: http://linuxtv.org/hg/~mchehab/tm6000/rev/79f9210425e2 You should not symbol_put(xc3028_attach); , because you don't always know that we're dealing with that tuner. We know that because it's the only tuner that I've ever seen on tm6000 devices :-) We like to make linuxtv drivers modular and forward compatible. There _are_ devices out there that use other tuners, and if you hardcode xc3028 into this driver, it prevents future developers from adding support for other devices without having to change existing code. But anyway, how would dvb_frontend_detach(fe) release the xc3028_attach symbol, which is requested by dvb_attach? The answer is self-explanatory. Take a look at the other drivers, and take a look at dvb_frontend_detach. (dvb_frontend.c , lines 1204 thru 1221) Better to use the established methods, and have uniform codingstyle across the tree -- don't reinvent the wheel ;-) -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] never do symbol_put(tunerfoo_attach);
Mauro Carvalho Chehab wrote: Em Sex, 2007-11-16 às 18:37 -0500, [EMAIL PROTECTED] escreveu: Michel Ludwig wrote: Hi Mike, On Fri 16 Nov 2007, [EMAIL PROTECTED] wrote: Mauro and Michel, This changeset is wrong: http://linuxtv.org/hg/~mchehab/tm6000/rev/79f9210425e2 You should not symbol_put(xc3028_attach); , because you don't always know that we're dealing with that tuner. We know that because it's the only tuner that I've ever seen on tm6000 devices :-) We like to make linuxtv drivers modular and forward compatible. There _are_ devices out there that use other tuners, and if you hardcode xc3028 into this driver, it prevents future developers from adding support for other devices without having to change existing code. But anyway, how would dvb_frontend_detach(fe) release the xc3028_attach symbol, which is requested by dvb_attach? The answer is self-explanatory. Take a look at the other drivers, and take a look at dvb_frontend_detach. (dvb_frontend.c , lines 1204 thru 1221) Better to use the established methods, and have uniform codingstyle across the tree -- don't reinvent the wheel ;-) Mike, there are some that calls symbol_put directly, like dst. -Mike DST is a special case -- it is an ASIC. Certain hacks were done there to make it look like a frontend, but it is not. Manu has explained this repeatedly. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] never do symbol_put(tunerfoo_attach);
Michel Ludwig wrote:
On Fri 16 Nov 2007, you wrote:
We like to make linuxtv drivers modular and forward compatible. There
_are_ devices out there that use other tuners, and if you hardcode
xc3028 into this driver, it prevents future developers from adding
support for other devices without having to change existing code.
Sure, but no one said that tm6000-dvb is ready to go into the main tree...
I saw an issue and I felt it was appropriate for me to point it out
immediately.
Better to fix a problem when it is noticed, no?
But anyway, how would dvb_frontend_detach(fe) release the xc3028_attach
symbol, which is requested by dvb_attach?
The answer is self-explanatory. Take a look at the other drivers, and
take a look at dvb_frontend_detach. (dvb_frontend.c , lines 1204 thru
1221)
Of course, I have done that, but it is still not clear to me. Here are the
two
macros:
#define dvb_attach(FUNCTION, ARGS...) ({ \
void *__r = NULL; \
typeof(FUNCTION) __a = symbol_request(FUNCTION); \
if (__a) { \
__r = (void *) __a(ARGS); \
if (__r == NULL) \
symbol_put(FUNCTION); \
} else { \
printk(KERN_ERR DVB: Unable to find symbol
#FUNCTION()\n); \
} \
__r; \
})
void dvb_frontend_detach(struct dvb_frontend* fe)
{
void *ptr;
if (fe-ops.release_sec) {
fe-ops.release_sec(fe);
symbol_put_addr(fe-ops.release_sec);
}
if (fe-ops.tuner_ops.release) {
fe-ops.tuner_ops.release(fe);
symbol_put_addr(fe-ops.tuner_ops.release);
}
ptr = (void*)fe-ops.release;
if (ptr) {
fe-ops.release(fe);
symbol_put_addr(ptr);
}
}
dvb_attach is called with xc2028_attach, hence it will request
xc2028_attach.
But dvb_frontend_detach will release xc2028_dvb_release.
It's the same module.
I can try this out tomorrow, but if I have to reboot my machine after that
to
unload tuner-xc2028, then there is definitely a flaw in this approach...
:-)
This is the accepted and proven method used across the entire dvb tree.
If it doesnt work for you, then something is wrong in your code. I
don't think it will cause any problem.
Hey, I was just trying to point out a flaw in your patch -- Nobody is an
expert, and there is always something to be learned.
-Mike
P.S. Why are you guys dropping cc's? I cc'd linux-dvb mailing list
because this is a development issue. It is important for such
discussions to be documented, because it is the only way for future
developers to learn from our mistakes. To conduct all emails in private
will not lead to any progression. This is a community, and we should
all be willing to give and accept advice from each other.
___
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: I think that's not really necessary, my one is already open (I could take a foto if not already available) although I think Patrick already has a driver for it? The usb device includes a hub and shows up 2 more usbids on the host, one is a storage device, the other one is the dibcom tuner as far as I remember. Interesting... In which case, then I'm probably wrong, and it's not an xc5000. Do you know WHICH dibcom tuner? Is it a 7070? -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: The Pinnacle PCTV HD Ultimate stick just came out (a couple of weeks ago). I looked in the Windoze .inf files and it appears that the drivers used are the same for the PCTV HD Pro and PCTV HD Ultimate. I looked in the developmental build of DVB and saw that in the file em288x-cards.c there was the correct USB_DEVICE # of 0x2304 but the next value was not 0x0233. I changed it and recompiled. When the driver loads it now has the following message in the kernel buffer log: FIXME:em28xx_i2c_send_bytes(c2): write failed: Any ideas ? I am pretty sure the correct driver is the em28xx. As both Patrick and Markus explained, this device is not empia hardware, and the code that supports it is located inside dib0700_devices.c -- you'll want to edit dvb-usb-ids.h Also, please do not top-post. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [RFC] tuner-refactor-phase-2
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 - Move all tda8275/8275a tuning code from tda8290 module into tda827x module - tda827x: fix GPL export on attach function - tda8290: add support for NXP TDA18271 tuner and TDA8295 analog demod - tuner: move analog_tuner_ops into dvb_frontend_ops - tuner: clear analog_demod_ops on release - tuner: move analog_demod_priv into struct dvb_frontend - dvb_frontend: codingstyle cleanups - tuner: convert analog tuner demod sub-modules to dvb_frontend interface - tuner: clean up ops checking in tuner_status function - move std if setting from tda8290 to tda827x - make tda9887 build selectable via Kconfig b/linux/drivers/media/dvb/frontends/tda18271.c | 1062 b/linux/drivers/media/dvb/frontends/tda18271.h | 40 b/linux/drivers/media/video/tda9887.h | 33 linux/Documentation/video4linux/CARDLIST.tuner |1 linux/drivers/media/Kconfig | 14 linux/drivers/media/dvb/dvb-core/dvb_frontend.h | 22 linux/drivers/media/dvb/frontends/Kconfig |7 linux/drivers/media/dvb/frontends/Makefile |1 linux/drivers/media/dvb/frontends/tda827x.c | 370 ++ linux/drivers/media/dvb/frontends/tda827x.h | 13 linux/drivers/media/video/Makefile |3 linux/drivers/media/video/tda8290.c | 1297 -- linux/drivers/media/video/tda8290.h | 40 linux/drivers/media/video/tda9887.c | 161 - linux/drivers/media/video/tuner-core.c | 248 + linux/drivers/media/video/tuner-driver.h| 25 linux/drivers/media/video/tuner-types.c |3 linux/drivers/media/video/tveeprom.c|2 linux/include/media/tuner.h |2 v4l/versions.txt|2 20 files changed, 2424 insertions(+), 922 deletions(-) The four major changes are: 1) move all tda827x tuning code from tda8290.c into tda827x.c 2) addition of tda8295 + tda18271 tuner + analog demod combo support. 3) conversion of tda9887 to a separate module 4) addition of analog_demod_ops analog_demod_priv to struct dvb_frontend After this is merged, the analog demods will be accessible via the dvb_frontend interface. For the sake of simplicity, I've kept the analog_tuner_ops untouched, and using this structure for the demodulators within the dvb_frontend_ops structures. We can improve on this in the future, if necessary. I've implemented this as a forward reference, so we can make any changes to the analog_tuner_ops structure as we see fit, without having any impact on dvb-only users of the dvb_frontend. This started off as a private email, but I believe that I've covered all bases. Since I tend to be lazy with emails in general, I am just going to cc the mailing lists and consider this an RFC. I've taken into account the concerns mentioned in the phase-1 RFC thread -- I believe that all will be happy with the way that I've done this. Please let me know if you have any questions or comments. Cheers, Mike Krufky ___ 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
Hans Verkuil wrote:
On Monday 22 October 2007 22:03:03 [EMAIL PROTECTED] wrote:
http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-2
Hi Mike,
Looks good!
Hans,
Thank you for the review!
Just some nitpick things:
1)
tuner-core.c: things like:
- if (t-ops.tuner_status)
- t-ops.tuner_status(t);
+ if ((ops) (ops-tuner_status))
+ ops-tuner_status(t);
A bit too many parenthesis, 'if (ops ops-tuner_status)' works just
as well and is more readable IMHO.
Good point -- I've cleaned that up.
2)
Please comment who IS responsible for freeing analog_demod_priv,
also 'kfree(t-fe.' should be 'kfree(fe-' to keep the comment in sync
with the code changes.
+static void fe_release(struct dvb_frontend *fe)
+{
+ if (fe-ops.tuner_ops.release)
+ fe-ops.tuner_ops.release(fe);
+
+ fe-ops.analog_demod_ops = NULL;
+ /* DO NOT kfree(t-fe.analog_demod_priv) */
+ fe-analog_demod_priv = NULL;
+}
Done. I realize that this could be confusing. This should be clearer
with the new comments / better explanation.
3)
Personally I don't see the need for changeset 6214 (clean up ops
checking in tuner_status function): I thought the original was easier
to read. Just remove the '{' '}' checkpatch complains about and it's
fine.
I disagree with you here. In reality, either way should be OK... The
way it is right now simplifies matters by checking (ops) once. If it is
NULL, then neither .has_signal nor .is_stereo will be checked. I'd
prefer to keep it this way.
Reviewed-by: Hans Verkuil [EMAIL PROTECTED]
Thanks. I will add your reviewed-by tag to all changesets EXCEPT for
#6214 as mentioned in (3). I'm going to give it a few hours first, to
see if anybody else has any comments.
Regards,
Hans
Thanks again for the review at such short notice.
Regards,
Mike Krufky
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] RE : Re: support from cx23885 driver and Xc3028 t uner for HP/Hauppauge WinTv885 mod 77001
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. aldebaran wrote: Dear Devs, Dear Mike, as you requested here below is the output of 'modprobe cx23885 i2c_scan=1' I'm not going to make any pressure on you, however please consider I'm available for any beta testing work or any other help that could ease your work. I did a little googling for the tuning chip xc3028 and found George Kiagiadakis (Gkiagia) has already started working on it http://mcentral.de/wiki/index.php/Xc3028 (http://mcentral.de/firmware/firmware_v4.tgz I tried copying these firmwares inside /lib/firmware/linux-blahblah/ but Kaffeine is still not able to scan for channels) maybe I should try with the experimental trunk, so far I used a mercurial snapshot of http://linuxtv.org/hg/v4l-dvb trunk. Don't even bother trying to get this device up running with any repositories out there right now -- it is not going to work. I have all the code written for this device already -- it's now just a matter of firmware. I have the device, too. Once I get it working, you'll see it in my cx23885 tree. I will not post the patch until I resolve the firmware issue. If you need any more information please do not hesitate to send me an email! In the meantime I thank you for your efforts and wish you a good work. Don't worry about it -- I have all the info that I need for this one. 192000] cx23885 driver version 0.0.1 loaded 192000] ACPI: PCI Interrupt :04:00.0[A] - GSI 17 (level, low) - IRQ 17 192000] CORE cx23885[0]: subsystem: 0070:7717, board: UNKNOWN/GENERIC [card=0,autodetected] 292000] cx23885[0]: i2c bus 0 registered 304000] cx23885[0]: i2c scan: found device @ 0xa0 [eeprom] 312000] cx23885[0]: i2c bus 1 registered 328000] cx23885[0]: i2c bus 2 registered 332000] cx23885[0]: i2c scan: found device @ 0x66 [???] 332000] cx23885[0]: i2c scan: found device @ 0x88 [cx25837] 332000] cx23885[0]: i2c scan: found device @ 0x98 [???] 364000] cx23885[0]/0: found at :04:00.0, rev: 2, irq: 17, latency: 0, mmio: 0xf400 Hmm... I should have realized that you'd be sending this kind of output... You'll need my patch in order to enable the right GPIO's to bring up the tuner / demod ic's . Tuner is on bus 1, demod on bus 0. Don't worry about this for now. Stay tuned for more information. If you dont hear from me within eight weeks, ping me again. 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-final] videobuf tree
Mauro Carvalho Chehab wrote:
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.
Wrong. This has nothing to do with c optimizer. Try this:
Create this as header.h:
struct foo {
struct some_pci_struct foo;
};
Create this as main.c:
#include header.h
int main (void)
{
return 0;
}
You will got the following error:
/tmp/header.h:2: error: field ‘foo’ has incomplete type
If we use your approach, a non-pci videobuf driver will work only at the
architectures where you have a PCI bus (since the pci structs won't
exist on that architecture).
OK, I wasn't thinking clearly when I had written that at first... We
would have to use some #ifdef logic within video-buf.h in order to avoid
this, but that's ugly, and more trouble than it's worth.
You've proven your point.
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.
It is much more clear to include videobuf-vmalloc or videobuf-dma-sg,
depending on the proper videobuf module that will be needed by a driver.
Creating a video-buf.h that just includes the two will be unused by the
drivers. So, what's the sense of creating a header file at the kernel
that aren't used inside kernel?
It would just be nice to have errors when a module calls a function
defined in the old header, rather than the new one.
This is a concern, but a minor one, as this is only an issue during the
transitional kernels. If we've fixed all instances, then there should
be nothing to worry about.
In general, I just don't like modules building against the wrong headers
and not reporting any errors... I guess we'll just have to live with it
this way for now.
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?
Although there's no intention to make life harder for out-of-tree
drivers, they shouldn't be considered on changes made at kernel
internals. The proper place for a kernel driver is in-kernel, not
outside.
Anyway, a compilation with a driver including video-buf.h currently will
generate an error, indicating that something has changed at v4l
infrastructure. By creating a header like you're proposing won't fix
this.
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?
The only in-kernel drivers that use videobuf infrastructure are:
cx88, saa7134, bttv, saa7146 and, now, cx23885.
After the patch, all of they are already converted.
grep videobuf_queue_pci_init *.c
bttv-driver.c: videobuf_queue_pci_init(fh-cap, bttv_video_qops,
bttv-driver.c: videobuf_queue_pci_init(fh-vbi, bttv_vbi_qops,
cx23885-dvb.c: videobuf_queue_pci_init(port-dvb.dvbq, dvb_qops,
dev-pci, port-slock,
cx88-blackbird.c: videobuf_queue_pci_init(fh-mpegq,
blackbird_qops,
cx88-dvb.c: videobuf_queue_pci_init(dev-dvb.dvbq, dvb_qops,
cx88-video.c: videobuf_queue_pci_init(fh-vidq, cx8800_video_qops,
cx88-video.c: videobuf_queue_pci_init(fh-vbiq, cx8800_vbi_qops,
saa7134-dvb.c: videobuf_queue_pci_init(dev-dvb.dvbq,
saa7134_ts_qops,
saa7134-empress.c: videobuf_queue_pci_init(dev-empress_tsq,
saa7134_ts_qops,
saa7134-video.c:videobuf_queue_pci_init(fh-cap, video_qops,
saa7134-video.c:videobuf_queue_pci_init(fh-vbi,
saa7134_vbi_qops,
saa7146_vbi.c: videobuf_queue_pci_init(fh-vbi_q, vbi_qops,
saa7146_video.c:videobuf_queue_pci_init(fh-video_q,
video_qops,
videobuf-dma-sg.c:void videobuf_queue_pci_init(struct videobuf_queue* q,
There's no other driver using the abstract videobuf_queue_init.
OK, we should be fine, then.
A final point for your consideration:
videobuf_queue_init is the only function that had its meaning changed
without changing its parameters (currently, it is just an abstract
method. In the past, this were the function that were used to initialize
a videobuf queue).
The changes you're proposing won't solve the target you've addressed in
the first place, since it will still compile without warning, if you
forget to rename it to videobuf_queue_pci_init.
The proper change is simply doing something like:
Re: [linux-dvb] [v4l-dvb-maintainer] modpost errors ( Re: 2.6.23-rc6-mm1)
Sam Ravnborg wrote: Please cc: relevant people. On Tue, Sep 18, 2007 at 05:43:35PM +0200, Gabriel C wrote: Hi, I get modpost errors here : ... ERROR: dvb_dmx_init [drivers/media/video/video-buf-dvb.ko] undefined! ERROR: dvb_unregister_adapter [drivers/media/video/video-buf-dvb.ko] undefined! ERROR: dvb_register_frontend [drivers/media/video/video-buf-dvb.ko] undefined! ERROR: dvb_unregister_frontend [drivers/media/video/video-buf-dvb.ko] undefined! ERROR: dvb_net_release [drivers/media/video/video-buf-dvb.ko] undefined! ERROR: dvb_frontend_detach [drivers/media/video/video-buf-dvb.ko] undefined! ERROR: dvb_dmxdev_release [drivers/media/video/video-buf-dvb.ko] undefined! ERROR: dvb_dmx_swfilter [drivers/media/video/video-buf-dvb.ko] undefined! ERROR: dvb_net_init [drivers/media/video/video-buf-dvb.ko] undefined! ERROR: dvb_dmx_release [drivers/media/video/video-buf-dvb.ko] undefined! ERROR: dvb_register_adapter [drivers/media/video/video-buf-dvb.ko] undefined! ERROR: dvb_dmxdev_init [drivers/media/video/video-buf-dvb.ko] undefined! dvb issue so dvb added. ERROR: mt2131_attach [drivers/media/video/cx23885/cx23885.ko] undefined! ERROR: s5h1409_attach [drivers/media/video/cx23885/cx23885.ko] undefined! Was not sure who maintain this stuff.. It's not in the git-tree I had around. Sam, This stuff is in -mm only right now. It was a dependency problem, where a new driver (cx23885) is missing the dependency on DVB_CORE. The fix is in this changeset: http://linuxtv.org/hg/~mkrufky/build-fix/rev/67acaa106a99 Mauro, Please pull from: http://linuxtv.org/hg/~mkrufky/build-fix for: - VIDEO_CX23885 depends on DVB_CORE Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Regards, Mike Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
