Hans Verkuil wrote: > Hi Andy, > > On Sunday 30 March 2008 04:28:37 Andy Walls wrote: > > Since a number of users have been experiencing tveeprom "Huh no > > eeprom present" messages, I've been trying to learn about the i2c > bus > > on the HVR-1600. > > I've looked into this in the past but I've been unable to figure out > why > it works for some people, but not for others. It's really weird. It > obviously works for me but other people with exactly the same model > as > far as I can tell have no luck with the i2c bus. > > It is not just the eeprom, the whole i2c bus seems to be not working.
Right, if the EEPROM read doesn't work, nothing else usually works either. I have another hypothesis as to why this might be happening. I really need to do more research on the PCI bus, but since someone new on the users list is having problems I'll toss out this half thought out idea: An I2C clock running at a maximum of 100 kHz has a minimum clock period, and minimum time between data bit changes, of 10 usec (neglecting STOP and START conditions). An quoting from the PCI latency howto: http://www.reric.net/linux/pci_latency.html "If the latency timer is set too low, PCI devices will interrupt their transfers unnecessarily often, hurting performance. If it's set too high, devices that require frequent bus access may overflow their buffers, losing data." So, if the total PCI latency that can be experienced in the system is 10 usec of greater (330 bus clocks at 33 MHz), the driver won't be able to react in time to read the I2C registers. Being forced to wait 330 clock cycles is probably highly unlikely when the driver is polling trying to read the registers (like ivtv newi2c=1). However, letting 330 bus cycles elapse may be more common, if the driver is in a busy wait loop for about 10 usec and then trying to poll the I2C register on the CX2341x, as it may not get immediate access to the PCI bus. Am I way off here? If not, how would one test this hypothesis or or troubleshoot? What would the probable PCI bus hogs: high end video cards? High end mass storage controllers? R, Andy > > First, the Serial EEPROM chip on my HVR-1600 is U3 in the upper > > corner of the card. It appears to be an ATMEL 24C02BN. > > > > The ATMEL 24C02 2 kbit (256 * 8) Serial EEPROM datasheet is here: > > > > http://www.atmel.com/dyn/resources/prod_documents/doc5126.pdf > > > > > > Also, the latest I2C spec, with a page or two of NXP (Phillips) > > marketing tacked to the front, is here: > > > > http://www.nxp.com/acrobat/usermanuals/UM10204_3.pdf > > > > > > > > The HVR's EEPROM is wired up with all the lower address bits > > grounded, so its I2C address is 1010000 (0x50 or 0xA0 depending on > > your perspective). The SDA and SCL line on pins 5 & 6 go to test > > points TP10 & TP11 on the card and then clearly over to SDA & SCL > > pins 1 & 2 of the CS5345, which is also on the same I2C bus. > > > > > > I note that the cx18 driver relies on i2c-algo-bit to get things > > done. It seems to use delays to meet the bits on the bus when they > > should be there. The cx18-i2c.c file claims to set the cx23418's > I2C > > master clock to 100 kHz, the .udelay specified is 10 microseconds or > > one cycle of a 100 kHz clock, and the .timeout for slow devices is > > specified as 200 jiffies. > > > > > > I have never (knock on wood) had apparent I2C problems with my > > HVR-1600 in my setup. So can anyone with tveeprom "Huh, ...?" > > problems do any of the following: > > > > 1. Put a capturing oscilloscope or logic analyzer on the HVR's TP10 > > (data) and TP11 clock to record what's going on on the I2C bus. > (All > > four pins on the left side of the U3 EEPROM should be tied to ground > > for a known ground point.) > > > > 2. Compile the i2c-algo-bit module with DEBUG enabled and set the > > module option for i2c-algo-bit i2c-debug=3, to view what phase of > the > > I2C transaction causes i2c-algo-bit to fail with -EREMOTEIO (-121). > > > > 3. Remove the conditional reset of the I2C block in the CX23418 by > > changing the cx18-i2c.c:init_cx18_i2c() to force the code inside > this > > if statement to always be executed: > > > > if (read_reg(CX18_REG_I2C_2_WR) != 0x0003c02f) { > > /* Reset/Unreset I2C hardware block */ > > write_reg(0x10000000, 0xc71004); /* Clock select > > 220MHz */ write_reg(0x10001000, 0xc71024); /* Clock Enable */ } > > > > > > > > > > > > I was also thinking that porting forward, to cx18, the ivtv "newi2c" > > customized i2c bit banging algorithm, that polls for SDA/SCL state > > changes instead of using delays, may help. > > Another test would be to try the card in another computer with a > different mainboard. > > > Any thoughts/comments? I can't test any ideas to fix the problem, > > since I can't reproduce it. > > Regards, > > Hans > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
