On Thu, 2008-05-15 at 12:28 -0700, Michael wrote: > > ----- Original Message ---- > > From: Andy Walls <[EMAIL PROTECTED]> > > To: User discussion about IVTV <[email protected]> > > Sent: Tuesday, May 13, 2008 11:37:48 PM > > Subject: Re: [ivtv-users] CX18: What Next? > > > > On Tue, 2008-05-13 at 13:46 -0700, Michael wrote: > > > > > I'm > > > > > > working under the assumption you're using the latest driver from : > > > > > > http://www.linuxtv.org/hg/v4l-dvb > > > > > > > > > > > > What I think I can help with, or more accurately you can help me > > > > > > with is > > > > > > investigating your intermittent EEPROM error. The attached patch > > > > > > enables adds a lot of debugging to gain some insight into what's > > > > > > going > > > > > > on with the i2c bus while the operations like reading the EEPROM are > > > > > > taking place. I also have some other code in there to try to > > > > > > recover > > > > > > from any PCI bus induced i2c errors if they occur. > > > > > > > > > > > > If you'd like to help, here's how to test the patch: > > > > > > > > > > > > $ cd (path-to-source-code)/v4l-dvb > > > > > > $ patch -p1 < (path-to-patch)/cx18-i2c-debugging2.patch > > > > > > $ make > > > > > > > > > > I can't seem to be able to run the make command. I get a whole bunch > > > > > of > > > > errors, ending with this error: > > > > > > > > > > make[3]: *** > > [/home/michael/Programs/v4l-dvb-d87638488880/v4l/tuner-xc2028.o] > > > > Error 1 > > > > > make[2]: *** > > > > > [_module_/home/michael/Programs/v4l-dvb-d87638488880/v4l] > > Error 2 > > > > > make[2]: Leaving directory `/usr/src/linux-2.6.22.17.tex2' > > > > > make[1]: *** [default] Error 2 > > > > > make[1]: Leaving directory > > `/home/michael/Programs/v4l-dvb-d87638488880/v4l' > > > > > make: *** [all] Error 2 > > > > > > > > > > > > Michael, > > > > > > > > Let me ask: > > > > > > > > 1. Initially were you using a prebuilt cx18 driver that came with your > > > > distribution, so that this is the first time you're compiling v4l-dvb & > > > > the cx18 driver yourself? If so, what distro are you using? > > > > > > > I'm using PCLinuxOS 2007, but I built it myself. > > > > Oh. If you have the module i2c-algo-bit.ko built with debugging > > enabled, you can modprobe that with debugging turned on, before the cx18 > > module, to see what it is intending to do as well. (i2c-algo-bit > > implements a bit banging algorithm that the cx18 driver uses.) > > > > > > > > > > 2. If you have compiled the v4l-dvb tree successfully before with your > > > > distro, then if you back out the patch by using: > > > > > > > > $ cd /home/michael/Programs/v4l-dvb-d87638488880 > > > > $ patch --reverse -p1 < (path-to-patch)/cx18-i2c-debugging2.patch > > > > > > > > or just remove the patched source code tree and restore it from the > > > > tar.bz2 archive, does the make then work without my patch? > > > > > > > > > > Well, I tried that, and the same errors appeared. I decided to reinstall > > > the > > > kernel and the source. Upon restarting, it "make"s with your patch. > > > (Really > > > weird, no clue on why I decided to try it, or why it works, but I guess > > > that > > > really doesn't matter.) > > > > Weird. Oh well. > > > > > > > The info in the messages file is really... really long, > > > so I'm just going to link to it, as it will be outside the 40kb size > > > limit of > > these emails. > > > > 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). > > > > 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 > > > > > > > Thanks again. > > > > Thank you for working with me to find the root cause. It takes patience > > and persistence at times. > > > > -Andy > > > > > http://h1.ripway.com/hendrick/testOne.txt > > > > > > > > -Andy > > > > > > > > > > > > > > > $ su - root > > > > > > # cd (path-to-source-code)/v4l-dvb > > > > > > # make unload > > > > > > # make install > > > > > > # logger START TEST 1 > > > > > > # modprobe cx18 debug=323 > > > > > > # logger END TEST 1 > > > > > > > > > > > > Then look in /var/log/messages for the lines between "START TEST 1" > > > > > > and > > > > > > "END TEST 1", dmesg will have filled up and wrpped around with the > > > > > > amount of messages written. > > > > > > > > > > > > _______________________________________________ > > ivtv-users mailing list > > [email protected] > > http://ivtvdriver.org/mailman/listinfo/ivtv-users > > > > > > _______________________________________________ > ivtv-users mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-users > _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
