> > > Michael, > > > > > > I have attached a patch that performs more aggressive i2c bus > > > initialization for the i2c buses controlled by the cx23418. The patch > > > cuases the cx18 driver on modprobe to initialize both i2c buses by > > > clocking ten bits and a stop marker to no particular device, and then > > > send an EEPROM reset sequence on the i2c buses as described in the ATMEL > > > serial EEPROM datasheet. > > > > > > This patch depends on the previous patch you have applied, so you should > > > not back out the previous patch before applying this one. > > > > > > If the patch works, your EEPROM will be recognized properly every time, > > > without you needing to specify any special module options. > > > > > > -Andy > > > > > > > > So, I applied both of the patches, and compiled. Heres a dmesg (this did > appear twice): > > > > cx18: Start initialization, version 1.0.0 > > cx18-0: Initializing card #0 > > cx18-0: Autodetected Hauppauge card > > cx18-0: cx23418 revision 01010000 (B) > > tveeprom 0-0050: Encountered bad packet header [00]. Corrupt or not a > Hauppauge eeprom. > > cx18-0: Invalid EEPROM > > cx18-0: VBI is not yet supported > > cs5345 0-004c: chip found @ 0x98 (cx18 i2c driver #0-0) > > cx18-0: Disabled encoder IDX device > > videodev: "" has no release callback. Please fix your driver for proper > > sysfs > support, see http://lwn.net/Articles/36850/ > > cx18-0: Registered device video0 for encoder MPEG (2 MB) > > DVB: registering new adapter (cx18). > > MXL5005S: Attached at address 0x63 > > DVB: registering frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)... > > cx18-0: DVB Frontend registered > > videodev: "" has no release callback. Please fix your driver for proper > > sysfs > support, see http://lwn.net/Articles/36850/ > > cx18-0: Registered device video32 for encoder YUV (2 MB) > > videodev: "" has no release callback. Please fix your driver for proper > > sysfs > support, see http://lwn.net/Articles/36850/ > > cx18-0: Registered device video24 for encoder PCM audio (1 MB) > > videodev: "" has no release callback. Please fix your driver for proper > > sysfs > support, see http://lwn.net/Articles/36850/ > > cx18-0: Registered device radio-64 for encoder radio > > cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes) > > cx18-0: loaded v4l-cx23418-cpu.fw firmware (174716 bytes) > > cx18-0: loaded v4l-cx23418-dig.fw firmware (16382 bytes) > > cx18-0: Initialized card #0: Hauppauge HVR-1600 > > cx18: End initialization > > Rats. :( > > > However, using KMPlayer, it still doesn't seem to recognize it. > > I doubt kmplayer or mplayer will work until the EEPROM is recognized > properly. The driver doesn't know what type of tuner to use for the > analog side. > > You may wish to try capturing from SVIDEO or Composite input just to > see. > > $ v4l2-ctl -d /dev/video0 -i1 Still isn't recognized. > for SVIDEO assuming the device shows up as /dev/video0. It is on video0. > I can't recall if these SVIDEO or Composite will work or not without the > EEPROM being readable, but it's something you can try. > > You may also want to try the digital (ATSC) part of the card. To scan > for over the air ATSC terrestrial broadcasts (8VSB signals), on my > fedora 7 system, I used: > > scandvb -A 1 -v -a 0 /usr/share/dvb-apps/atsc/us-ATSC-center-frequencies-8VSB > > > > And lastly, would be of any benefit for me to run the test below this? > > I would like to help diagnose this problem as much as possible, so > > others won't have the same issue, but I believe the patch targeted the > > below issues. > > Yes, with the patches, I really do need to see the verbose cx18 > debugging to get a clue as to what is going on. If you can i2c-algo-bit > to spit out debug as well, it'll make my life easier. I've been > considering the following failure modes: > > 1. PCI bus aborts - I these are ruled for your system > > 2. EEPROM not properly resetting on power up - I though could have been > your card's problem. > > 3. Some other I2C slave holding the I2C bus low - again I though your > card may have had the problem. > > 4. Marginal board or device performance - in which case slowing down the > clock may have helped. > > 5. Improper CX23418 I2C or GPIO setup by the cx18 driver - still a > potential problem, but I may not have the information to fix things. > > If it boils down to #5 being the failure mode, I suppose I can boot over > to Windows and run regspy (once I install all the drivers and Dscaler) > and try and see what the Windows driver does. > > > > > Once again, I would like to apologize for the slow response, I've just been > extremely busy. > > Don't apologize, I usually have more than enough to do myself. In fact, > I'll be unavailable for anything else until Friday evening. > > > Regards, > Andy > > > > > > > > > > For you, if you desire: > > > > > > 1. A few unloads and reloads of the cx18 module, to see if there is > any > > > > > > correlation between a "glitch" showing up early in the log and the > > > > > > EEPROM read working properly or not. The problem is the output is too big for the konsole to fit all of it. Heres most of it (external link, couldn't seem to attach it, and it's fairly long) that I can see, with the standard 200 i2c clock period.
http://h1.ripway.com/hendrick/dmesg.txt Thanks again. > > > > > > 2. Try slowing down the i2c bus clock for the cx18 driver. The > patched > > > > > > module you have built has a new option: i2c_clock_period. Slowing > down > > > > > > the i2c bus clock may mitigate the problem. The default is a 10 > > > > > > usec > > > > > > clock period. The maximum can be very long, but much more than 4500 > > > > > > usec caused a serious kernel hang on my machine. > > > > > > > > > > > > So maybe you can try: > > > > > > > > > > > > # modprobe -r cx18 i2c-algo-bit > > > > > > # modprobe i2c-algo-bit debug=1 > > > > > > # modprobe cx18 debug=323 i2c_clock_period=200 > > > > > > > > > > > > You can try longer clock periods if you like, but beware your > > > > > > machine > > > > > > could hang badly, requiring a hard shutdown. > > > > > > > > > > > > > > > > > > > > > > When I run the test, do you want me to do another logger test, or > > > > > attach > > > > anything? > > > > > > > > Only one log sequence, no matter how things turn out. > > > > > > > > 1. If you can reliably have the EEPROM recognized, over several trials, > > > > by simply increasing the clock period, then I'd also like to know what > > > > the smallest i2c_clock_period is that works reliably for you. At this > > > > point though, you'll have 1 known good workaround. (I'm not optimistic > > > > that this will be the case though.) > > > > > > > > 2. If you still can't get the EEPROM to be recognized reliably, just > > > > sned the log when you use the default clock period of 10 usec. I'd like > > > > to see what i2c_algo_bit gripes about in the log, so hopefully, it's > > > > built with DEBUG in your kernel. (If it isn't, don't worry about it - > > > > the solution is probably the same whether I have debug logging from > > > > i2c_algo_bit or not.) > > > > > > > > > > > > Again, I owe you a patch, that I have high confidence will fix your > > > > problem. So you don't have to go through the above, if you don't want > > > > to. I'll probably be able to get a patch to you tomorrow. > > > > > > > > -Andy> http://ivtvdriver.org/mailman/listinfo/ivtv-users _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
