On Sunday 18 January 2009 22:20:30 CityK wrote: > Hans Verkuil wrote: > > On Sunday 18 January 2009 19:10:16 CityK wrote: > > > >> merging Hans' code eliminates the usability of Mike's "hack/workaround" ... in essence, analog TV > >> function has now been completely killed with these boards. > >> > > > > I've made a new tree http://linuxtv.org/hg/~hverkuil/v4l-dvb-kworld/ > > that calls 'enables the tuner' before loading the module. See if that > > works. > > > > ... > > > > I suspect that this might fix the bug. > > Hans, > > Between the time of my last message and now, your title has made a turn > for the better. I proclaim that you are no longer "Hans-the-Destroyer", > rather you should be upheld as "Hans-the-Enabler" !! :-) > In other words, it works !! (across reboots etc etc). > > The output of dmesg is interesting (two times tuner simple initiating): > > > saa7130/34: v4l2 driver version 0.2.14 loaded > > ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 19 (level, low) -> IRQ 19 > > saa7133[0]: found at 0000:00:09.0, rev: 240, irq: 19, latency: 32, > > mmio: 0xfa021000 > > saa7133[0]: subsystem: 17de:7350, board: Kworld ATSC110/115 > > [card=90,autodetected] > > saa7133[0]: board init: gpio is 100 > > saa7133[0]: i2c eeprom 00: de 17 50 73 ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > tuner 1-0061: chip found @ 0xc2 (saa7133[0]) > > tuner-simple 1-0061: creating new instance > > tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in) > > saa7133[0]: registered device video0 [v4l2] > > saa7133[0]: registered device vbi0 > > ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22 > > ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [ALKC] -> GSI 22 (level, > > low) -> IRQ 22 > > PCI: Setting latency timer of device 0000:00:11.5 to 64 > > dvb_init() allocating 1 frontend > > nxt200x: NXT2004 Detected > > tuner-simple 1-0061: attaching existing instance > > tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in) > > DVB: registering new adapter (saa7133[0]) > > DVB: registering adapter 0 frontend 0 (Nextwave NXT200X VSB/QAM > > frontend)... > > nxt2004: Waiting for firmware upload (dvb-fe-nxt2004.fw)... > > nxt2004: Waiting for firmware upload(2)... > > nxt2004: Firmware upload complete Shouldn't there be a tda9887 as well? It's what the card config says, but I'm not sure whether that is correct. > Would you like to see the results of after enabling 12c_scan to see what > is going on, or is this the behaviour you expected? It seems to be OK, although I find it a bit peculiar that the tuner type is set twice. Or does that have to do with it being a hybrid tuner, perhaps? > Some Other Miscellanea: > 1) Before this gets merged, can I ask you to also make one small change > to tuner-simple; specifically, swap the contents of lines 301 and 304. > This will change the driver's default behaviour in regards to the > selection of which RF input to use for digital cable and digital > over-the-air. Currently, the driver is set to use digital OTA on the > top RF input and digital cable on the lower RF input spigot. However, > IMO, a more logical/convenient configuration is to have the digital > cable input be handled by the top RF input spigot, as this is the same > one that the analog cable is also drawn from by default. Mike had made > this change, on my request, previously, but it appears that it got > reverted after the tuner re-factoring. I'm not going to merge this, it's just a quick hack for this card. This is something for Mike or Hermann to fix. Someone with a better knowledge of this driver and these tuners should review the saa7134_board_init2() function and move the opening of tuner gate/muxes to a separate function. > Note: users have reported different default configurations in the past > (e.g. http://www.mythtv.org/wiki/Kworld_ATSC_110), but I actually doubt > that there has been any manufacturing difference with the TUV1236D. > Rather, I suspect that the user experiences being reported are just > reflecting a combination of the different states of how our driver > behaved in the past and differences in driver version that they may have > been using (i.e. that version provided by/within their distro or by our > Hg). After all, this configuration setting has gone from being handled > by saa7134-dvb.c to dvb-pll.c to tuner-simple.c, with changes in the > behaviour implemented along the way. > > 2) This is likely related to the discussion about the gate -- after > closing the analog TV app, the audio from the last channel being viewed > can still be heard if one turns up the volume on their system. This > leakage has always been present. But given that we are addressing this > issue now, it strikes me that the gate is being kept open on the audio > line after application closing/release occurs. > > 3) there is an issue about having two of these cards in the same system > --- IIRC, only one card will get /dev/video .... Mauro touched upon this > very briefly in one of the earlier messages; recall: > > Mauro wrote: > > This generated lots of issues in the past, like machines with two boards > > doesn't work anymore. With two boards, and a tuner module, the first board > > probes tuner after opening the demod gateway. However, the second board will > > try to probe tuner before opening the i2c gateway. So, tuner is not found. > > Now, I can't test for this myself, but I do know of several users on > AVSforums who have two such cards and can test if that issue is now > resolved .... do you suspect that the changes you have implemented to > date will have eliminated this bug too? That should have been fixed as well now that the automatic probing has been removed. Hopefully the work I did on saa7134 can be ported to other drivers as well, since this clearly fixes a lot of tricky bugs. -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
