[ivtv-devel] cx18: Figuring out what's wrong with the I2C bus for some HVR-1600 users

Sigmund Augdal sigmund at snap.tv
Tue Apr 8 15:36:36 CEST 2008


tir, 08.04.2008 kl. 07.23 -0400, skrev Andy Walls:
> 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?

I have seen issues caused by similar conditions, but on other devices.
That is, using several cards in the same bus, some cards might run out
of buffer before being able to offload their data to the system. In my
experience the ivtv cards is among the worst cards in this respect. We
often have to use different computers for analog capture using ivtv and
digital capture using various dvb cards for this reason. Video cards,
mass storage controllers and ethernet cards are big hogs, but these are
not normally found on the pci bus anymore. Video cards usually sit on
agp or pci-e. Storage controllers and network cards integrated on the
mother board usually have dedicated buses for them etc. 'lspci -t -v'
will usually give some good clues about which devies share a bus.

R.
Sigmund


> 
> 
> 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
> ivtv-devel at ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
> 




More information about the ivtv-devel mailing list