Warren Sturm wrote: > On Fri, 2008-03-28 at 22:18 -0400, Andy Walls wrote: > > Doug Chalmers wrote: > > > Yes Andy, it is a Canadian card. I see nothing about tveeprom, in either > > > dmesg, or syslog. > > > > > I have the same model (1181) and I have not experienced the problem that > Doug has. I am wondering if it may not be doa.
I would only make a DOA declaration, if it didn't work under Windows. A beta Linux driver isn't a real good test suite. ;) Also a few people are experiencing the I2C problems with the HVR-1600 (see last month's list archives for users and devel) with the "Huh, no eeprom present ... -121)" being a common symptom. This points to the cx18 driver IMO. My hypothesis is that the i2c-algo-bit.ko implementation may not suitable for these devices under all kernel configurations. When you drive an I2C bus SDA & SCL from the host, there are 2 deterministic ways you can do things: use interrupts (like Hans alludes to in cx18-irq.c) or actively poll (like ivtv does in ivtv-i2c.c). i2c_algo_bit.ko doesn't seem to do either: it takes actions, looks away for a udelay() and then polls expecting the right bit to be there - I think therein lies the problem. Another possible problem source area could include the set up of the I2C hardware block inside the cx23418. I also notice in init_cx18_i2c() at the end of the setup, an inadvertent "start" condition may be getting detected by other devices on the bus since SDA is raised after SCL is raised. Although the timing on the bus should be close to simultaneous, it would be better to raise SDA first I think. I wonder if kernel timing resolution matters since the udelay() function i2c_algo_bit.ko calls depend on the kernel "HZ" parameter (timer interrupts per second or jiffies per second) and the measurement of "loops_per_jiffy" (CPU TSC ticks per timer interrupt or CPU TSC ticks per jiffy)? My system appears to be using a "HZ" of 1000 since: # grep timer /proc/interrupts; cat /proc/uptime 0: 30750089 2693973 local-APIC-edge timer 33429.77 32375.65 # echo "(30750089 + 2693973)/33429.77" | bc 1000 And my system appears to be using a loops_per_jiffy = 995490, since # grep bogomips /proc/cpuinfo bogomips : 1990.98 bogomips : 1990.98 and bogomips * 500000/"HZ" = loops_per_jiffy (I think) -Andy _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
