On Tue, 2008-06-10 at 20:43 -0400, Andy Walls wrote:
> On Tue, 2008-06-10 at 18:36 -0500, [EMAIL PROTECTED] wrote:
> > Greetings,
> > 
> > First off I'd like to thank the developers very much for putting forth the
> > effort in developing the CX18 driver for the Hauppage HVR cards. I happen
> > to have a PCI interface HVR-1600, installed in an Intel i845 motherboard.
> > 
> > I'm having trouble getting past the initial stages of getting things
> > going. I've followed the steps outlined in the Cx18 wiki article
> > (http://www.ivtvdriver.org/index.php/Cx18), including downloading the
> > firmware and copying it to the correct location in /lib/firmware.
> > 
> > When I load the CX18 driver, I get the following messages in dmesg:
> > 
> > [72062.445907] cx18:  Start initialization, version 1.0.0
> > [72062.446390] cx18-0: Initializing card #0
> > [72062.446398] cx18-0: Autodetected Hauppauge card
> > [72062.446599] cx18-0: cx23418 revision 01010000 (B)
> > [72062.600091] tveeprom 3-0050: Huh, no eeprom present (err=-121)?
> 
> -121 => -EREMOTEIO  You have the I2C bus problem that other are
> experiencing.
> 
> > [72062.600103] tveeprom 3-0050: Encountered bad packet header [00].
> 
> The all 0 byte means that one of the I2C bus slaves is stuck holding the
> I2C data line low on the same bus as the EEPROM.  Michael on the
> ivtv-users list in the "What's next?" thread has posted positive results
> by applying the attached cx18-i2c-gpio-reset3.patch (not made against
> the latest - so may not apply cleanly).
> 
> But Michael had also increased the delays in the patch to 100 ms.  He
> also increased the mdelays() in cx18-i2c.c to 100 ms as well.  100 ms is
> probably overly long, but we haven't worked down empirically what are
> the smallest numbers to use.
> 
> > Corrupt or not a Hauppauge eeprom.
> > [72062.600107] cx18-0: Invalid EEPROM
> > [72062.600111] cx18-0: VBI is not yet supported
> > [72062.954362] tuner 4-0043: chip found @ 0x86 (cx18 i2c driver #0-1)
> > [72063.073754] tda9887 4-0043: creating new instance
> > [72063.073764] tda9887 4-0043: tda988[5/6/7] found
> > [72063.284032] tuner 4-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
> > [72063.284444] cs5345 3-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
> > [72063.420184] cx18-0: Disabled encoder IDX device
> > [72063.437246] cx18-0: Registered device video0 for encoder MPEG (2 MB)
> > [72063.437723] DVB: registering new adapter (cx18)
> > [72063.465382] cx18-0: Mismatch at offset 10
> > [72063.465404] cx18-0: Retry loading firmware
> > [72063.483676] cx18-0: Mismatch at offset 10

Oopsie, I missed this on the first reply.  You might want to try
changing the "#if 0" to #if 1" in cx18-firmware.c.  Although I'm not
quite sure this will help you, we'd be relying on the first or second
retry to get the firmware loaded, knowing the first attempt will fail.


> > [72063.483698] cx18-0: Failed to initialize on minor 0
> > [72063.505208] s5h1409_readreg: readreg error (ret == -121)
> > [72063.505294] cx18-0: frontend initialization failed
> > [72063.519591] cx18-0: DVB failed to register
> > [72063.522134] cx18-0: Registered device video32 for encoder YUV (2 MB)
> > [72063.522517] cx18-0: Registered device video24 for encoder PCM audio (1 
> > MB)
> > [72063.522797] cx18-0: Registered device radio0 for encoder radio
> > [72063.523245] cx18-0: Error -12 registering devices
> > [72063.523873] tda9887 4-0043: destroying instance
> > [72063.525311] cx18-0: Error -12 on initialization
> > [72063.525541] cx18: probe of 0000:02:0a.0 failed with error -12
> 
> -12  is -ENOMEM

This might not be a vmalloc problem.  You might actually be short on
memory available for the driver buffers.  When you modprobe the module,
you may want to try to make the mpg buffer smaller and zero out all the
others:

# modprobe cx18 enc_ts_buffers=0 enc_yuv_buffers=0 enc_vbi_buffers=0 \
         enc_pcm_buffers=0  enc_mpg_buffers=1

That will minimize the amount of memory required by the cx18 driver for
the sake of testing, until you figure out how ot get more memory
available to the driver.


> You're out of vmalloc space.  You need a little more than 64M just to
> accommodate 1 CX23418 chip since modules use vmalloc address space, and
> the 64M of CX23418 register space also uses vmalloc space.
> 
> Brian Hope has reported adding a 'vmalloc=256M' option to his kernel
> command line made the problem go away for his machine with 2 CX23418
> chips in it.
> 
> > [72063.525786] cx18:  End initialization
> > 
> > I'm not exactly certain what that means but the crux of the problem seems
> > to be that it's not identifying the eeprom correctly.
> 
> One of the I2C devices is holding the bus stuck low and hence the EEPROM
> data can't be read.  Somewhere down the line, that device gets unstuck
> and you can start configuring the other I2C slaves like the cs5345, but
> by then, it's too late for autoconfiguration. :(
> 
> Manual configuration with "modprobe cardtype=xx  tuner=yy" options
> should get you operational without a readable EEPROM with the right xx
> and yy (I think).
> 
> 
> Regards,
> Andy
> 
> >  The card is brand
> > new so I don't think it's a bad eeprom, though I will admit that I have
> > not installed the card in a windows PC to verify that it's working.
> > 
> > For reference, the output of lspci -v for my HVR-1600 is:
> > 
> > 02:0a.0 Multimedia video controller: Conexant CX23418 Single-Chip MPEG-2
> > Encoder with Integrated Analog Video/Broadcast Audio Decoder
> >     Subsystem: Hauppauge computer works Inc. Unknown device 7444
> >     Flags: bus master, medium devsel, latency 64, IRQ 20
> >     Memory at f8000000 (32-bit, non-prefetchable) [size=64M]
> >     Capabilities: [44] Vital Product Data
> >     Capabilities: [4c] Power Management version 2
> > 
> > The system in question is mythbuntu running with the latest versions of
> > everything in their repository, and I snagged the latest version of the
> > v4l-dvb drivers right before writing this email.
> > 
> > Please let me know what I can do to assist with testing/developting the
> > CX18 driver. I'm not a programmer, but I've got hardware to test with and
> > am pleased to assist with development.
> > 
> > Of course, I'd also like to watch some HDTV :) so I'd appreciate any
> > advice on where to go next with getting the driver into a working state -
> > as I've seen other posts from users who have gotten further than this.
> > 
> >  - Nick Bright
> 
> 
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel


_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Reply via email to