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