[pvrusb2] New driver snapshot: pvrusb2-mci-20080210

[Mark Goldberg]

On Sun, Mar 9, 2008 at 11:57 AM, Mike Isely <isely at isely.net> wrote:
>  As for being able to trace the cx25840 module, there are some hackish
>  things we can do in the pvrusb2 driver to snoop the I2C traffic between
>  the cx25840 module and the part it is controlling.  I've had to do that
>  in the past in order to debug other problems (usually with stuck
>  hardware).  But a more fruitful strategy might be to turn on debugging
>  within the cx2540 module itself.  All these modules generally have a
>  "debug" parameter you can set.  Depending on the module, that will help
>  show what is going on.  However I have to warn you that for the sort of
>  thing you are looking for, you will likely want to have the chip's
>  datasheet in front of you when you do this, and this is not a simple
>  part :-( The PDF I have for it is 289 pages.
>
>  Does this help with understanding things or have I muddied it up?

I'm actually a hardware engineer and have messed with the saa7134 module to add
more controls to set additional registers so I could try to improve the capture.

Besides, you can't let the smoke out any more from your monitor if you
send it the wrong
sync signals. I assume you can't physically break the pvrusb2 by
sending wrong stuff to
the registers.

I can tell you that from /var/log/messages, it gets intitialized
differently. The newer module has:

Feb 11 06:08:01 localhost kernel: cx25840 3-0044: Specified standard:
     automatic detection
Feb 11 06:08:01 localhost kernel: cx25840 3-0044: Specified audioclock
freq: 44100 Hz

while the older one that works correctly has:

Feb 11 06:26:44 localhost kernel: cx25840 4-0044: Specified standard:
     NTSC-M
Feb 11 06:26:44 localhost kernel: cx25840 4-0044: Specified audioclock
freq: 48000 Hz

I'll turn on debug for the xcx25840 and see what I can see.

Mark