First off, I would like to apologize for the slow response this past week. I've been extremely busy, and hopefully this upcoming week will be the last of it. > On Thu, 2008-05-15 at 20:23 -0400, Andy Walls wrote: > > On Thu, 2008-05-15 at 12:28 -0700, Michael wrote: > > > > > > > > > Ok. So at first glance, you don't have the same I2C bus problems that > > > > other users seem to have. Other users appear to have PCI bus problems > > > > which I think causes the cx18 driver to mess up I2C control registers > > > > and hence I2C transactions. > > > > > > > > Your log file, on the other hand, indicates that there are no PCI bus > > > > problems AFAICT, but that initial communications on the i2c bus with the > > > > EEPROM is returning all 0 bits. > > > > > > > > In examining the log there is a "glitch" in the log file that looks like > > > > this: > > > > > > > > May 13 15:14:29 localhost kernel: cx180 i2c: cx18_getscl: read > CX18_REG_I2C_1_RD > > > > = 0x4 > > > > May 13 15:14:29 localhost kernel: cx180 i2c: cx18_setscl: On entry > > > > CX18_REG_I2C_1_WR = 0x21c09 > > > > May 13 15:14:29 localhost kernel: cx180 i2c: cx18_setscl: Wrote > > > > CX18_REG_I2_REG_I2C_1_WR = 0x21c0a <------ > > > > May 13 15:14:29 localhost kernel: cx180 i2c: cx18_setscl: Wrote > > > > CX18_REG_I2C_1_WR = 0x21c0b > > > > May 13 15:14:29 localhost kernel: cx180 i2c: cx18_setscl: Readback > > > > CX18_REG_I2C_1_WR = 0x21c0b > > > > May 13 15:14:29 localhost kernel: cx180 i2c: cx18_getscl: read > CX18_REG_I2C_1_RD > > > > = 0x4 > > > > > > > > Normally these sorts of misprints don't bother me with verbose logging, > > > > since it usually simply means the log facility couldn't keep up at the > > > > moment. However, it is the *only* such glitch in the log, and it > > > > happens during the sequence where the EEPROM's final address bits are > > > > being put out on the I2C bus. > > > > > > > > Thus, I can't say for sure that you have a stuck device on the I2C bus, > > > > or if some kernel bug is causing a problem in addressing the EERPOM. > > > > > > > > In the log, subsequent transactions to another device on the same I2C > > > > work just fine. > > > > > > > > > > > > > > > > So for courses of action: > > > > > > > > For me to do: > > > > 1. Provide an I2C bus startup normalization sequence patch, to hopefully > > > > cause the I2C bus and devices to get "unstuck" on module load. (And > > > > also turn any initial "glitch" or kernel bug into a don't care > > > > condition). > > 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 However, using KMPlayer, it still doesn't seem to recognize it. 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. Once again, I would like to apologize for the slow response, I've just been extremely busy. > > > > > > 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. > > > > > > > > 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 _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
