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

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

Reply via email to