On Fri, 2009-12-11 at 08:23 -0500, Robert wrote:
> On Fri, 11 Dec 2009 04:13:17 -0500 Andy wrote:
> AW> > [ 15.759167] cx25840 1-0044: firmware: requesting
> v4l-cx23885-avcore-01.fw
> AW> > [ 15.976478] cx25840 1-0044: firmware load i2c failure
> AW> > [ 19.814867] cx25840 0-0044: loaded v4l-cx23885-avcore-01.fw firmware
> (16382
> AW> > bytes)
> AW>
> AW> Yes. This is further confirmation that communications with the second
> AW> CX25843 chip isn' working. The cx25840 module is misdetecting it as a
> AW> CX23885 A/V core - a fallback position.
>
> hmm... but it's loading that same firmware for the first tuner...
You've got an older version of the cx25840 module that has a bug where
it would switch firmware name strings in a system with a mixed set of
cards having CX2584[0123], CX2388[578], and CX2310[012] chips.
The latest v4l-dvb repository has that fixed:
http://linuxtv.org/hg/v4l-dvb/tip.tar.gz
But getting a patched up cx25840 module isn't going to help. I know the
card has 2 CX25843 chips, and we know one is being misdetected as a
CX23885 because attempts to read the the ID register ove the I2C bus are
returning 0. For a CX25843, the ID register should return 843
(surprise).
> AW> So try
> AW>
> AW> # modprobe ivtv cardtype=0,-1
> AW>
> AW> to autodetect the first unit on the PVR-500 and to ignore the second
> AW> unit.
>
> ok... here's the dmesg with that modprobe option set:
>
>
> [145922.152823] ivtv: Start initialization, version 1.4.1
> ... snip ...
> [145922.282296] ivtv0: Initialized card: WinTV PVR 500 (unit #1)
> [145922.283236] ivtv1: Initializing card 1
> [145922.283239] ivtv1: Ignore card (detected cx23416 based chip)
> [145922.283242] ivtv1: Error -19 on initialization
> [145922.283338] ivtv: End initialization
> ... snip ...
> [145922.910048] ivtv0: info: Loading encoder image
> [145922.910058] ivtv 0000:05:08.0: firmware: requesting v4l-cx2341x-enc.fw
> [145922.977920] ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
> [145923.170164] ivtv0: info: Getting firmware version..
> [145923.170265] ivtv0: Encoder revision: 0x02060039
> [145923.189903] cx25840 0-0044: firmware: requesting v4l-cx23885-avcore-01.fw
>
> so it ignores the 2nd tuner... but the avcore firmware is loaded for tuner 1
> with no problem.
Not exactly. From your previous post:
> [ 15.759140] cx25840 0-0044: firmware: requesting v4l-cx25840.fw
> [ 15.759167] cx25840 1-0044: firmware: requesting v4l-cx23885-avcore-01.fw
> [ 15.976478] cx25840 1-0044: firmware load i2c failure
> [ 19.814867] cx25840 0-0044: loaded v4l-cx23885-avcore-01.fw firmware
> (16382 bytes)
>
It probably loaded the the "v4l-cx25840.fw", but by the time it reports
back to you, the filename has swapped around due to the aforementioned
cx25840 module bug.
None the less, you should probably unload both the ivtv and cx25840
module when performing tests when you reload modules, until you have a
fixed cx25840 module.
> AW> You should try an test the board in a Windows machine. The I2C
> AW> subsystem debug messages are compiled out of the kernel by most distro's
> AW> by default. It's hard to see what is going on the i2c buses without
> AW> recompiling the kernel. :(
>
> I'd rather rebuild a kernel than run a windows machine. :-) Just tell me what
> I need to enable in the kernel...
In
linux/drivers/i2c/algos/i2c-algo-bit.c
detailed debugging is is #ifdef'ed out by the 'DEBUG' define. The
i2c_algo_bit module parameters of interest are "bit_test" which may be
compiled into your kernel by default. Set it to one to have the bit
banging algorithm try and test for a stuck bus. Also "i2c_debug", which
can be set to a value of 0 to 3 for various levels of debugging
verbosity.
In the ivtv module, I would recommend turning on at least the i2c debug
flag and the high volume debug flag in the debug module option.
The ivtv module also has 2 i2c bus master implementations to choose
from:
newi2c=0 forces the i2c_algo_bit algorithm
newi2c=1 forces an ivtv internal algorithm
On newer versions of the ivtv module from the main v4l-dvb repository
there is also an i2c_clock_period module parameter you can twiddle to
slow down the I2C bus when using the i2c_algo_bit algorithm.
In the cx25840 module, the debug=1 option will provide some insight into
the detection process used by that module.
In reality, all of the above is going to help you collect alot of
information on when and where exactly the I2C bus transactions are
failing. That does not mean it will necessarily provide any insight as
to why the CX23416 and CX25843 fail to communicate with each other over
the I2C bus.
Regards,
Andy
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
