> > > > 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.
>
>
Hey Andy
I hate to be the first to report this, but I'm still obtaining the
eeprom error. I'm currently away from the computer (I tested this last
night, but was too tired to write up the email yet...), but when I do
get a chance, would a dmesg be of any help, or what would you like?
Anyways, you said if it doesn't work, run "/sbin/modprobe
cx18 mmio_ndelay=61". I've gotten up to 152, yet it still doesn't
work. Should I keep going, to see if it'll eventually catch it? How high?
I really appericate your help on this.
-Michael
>
> 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.
>
>
> 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.
>
>
> 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
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
