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.
> 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
