On Tue, 2008-08-05 at 21:47 -0400, Andy Walls wrote: > > Andy Walls wrote: > > > Quite a few HVR-1600 users have reported cx18 driver I2C related > > > problems usually with the following errors present: > > > > > > tveeprom 1-0050: Huh, no eeprom present (err=-121)? > > > tveeprom 1-0050: Encountered bad packet header [ff]. Corrupt or not a Hauppauge eeprom. > > > > > > s5h1409_readreg: readreg error (ret == -121) > > > cx18: frontend initialization failed > > > cx18-0: DVB failed to register > > > > > > and an unusable HVR-1600/CX23418 under linux. > > > > > > > > > On the surface the problem appeared to be related to the devices on the > > > I2C buses of the HVR-1600. [...] The I2C bus errors appear to be > > > just a symptom of a larger underlying problem. To all the users of CX23418 based cards that currently don't seem to work, showing some of the above symptoms, please test my latest changes at: http://linuxtv.org/hg/~awalls/v4l-dvb If your card still doesn't work with the default module options, then try upping the "mmio_ndelay" module parameter by multiples of about 30.3 ns until the card does work: For example, if the default "mmio_ndelay=31" doesn't work for you, then use: # /sbin/modprobe cx18 mmio_ndelay=61 or 91, or 121, or 152, etc. until your card does work. If you have multiple cx18 cards, and the default doesn't work, then you will have to specify a value for each card. For example: # /sbin/modprobe cx18 mmio_ndelay=61,61,61 for a three card setup. As always feedback is appreciated. In this case, I'd especially like to hear about digital captures, simultaneous analog & digital capture, and the (in)correctness of the cx18_memcpy_fromio() and cx18_memset_io() routines. This patch works for me to get my HVR-1600 and my Raptor PAL/SECAM card working in my older machine with an Intel 82810E Northbridge and 82801AA Southbridge. I have only been able to test analog capture from the analog tuner and composite 1 input in this setup using 'cat /dev/video0 >foo.mpg' and playing the mpg file on another machine. (The machine has no keyboard nor monitor nor apps like mplayer and mythtv). Things appear to be working properly. > To all the cx18 users who > have patiently provided data at my request on this problem so far, thank > you. Thanks, again for helping me resolve this problem. <hypothesis> The underlying cause appears to be that the CX23418 can't handle very rapid memory mapped IO accesses to differing locations under certain (unknown) conditions. In the Linux cx18 driver, these rapid MMIO accesses apparently happened quite often. In certain modern motherboard configurations, the PCI bridges apparently were slowing things down or adding retries so that the CX23418 would actually work for some people. </hypothesis> These patches work by adding a short delay (a 10's of ns busy wait) after *every* access to CX23418 mmio addresses. If your card already works fine and these busy waits bother you, then you can get approximately the previous behavior by setting "mmio_ndelay=0" which will skip all the calls to ndelay(). Regards, Andy _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
