[pvrusb2] PARTIAL SUCCESS Re: terratec grabster av400.. short report..

[Mike Isely]

On Wed, 9 Jan 2008, Andrea Venturi wrote:

> Mike Isely wrote:

   [...]

> 
> during my many "input swapping trials" for the s-video to work, i made 
> some mistakes on the correct sequence to replace the (newly recompiled) 
> pvrusb2 module without shutting down the device and i had a couple of 
> lockups on the usb bus and some ops in dmesg related to the pvrusb2 
> module (lsusb didn't come back, for example..)
> 
> when i did a correct sequence (like closing applications using the 
> device, shutting down the device, removing the pvrusb2 module, removing 
> the cable), i didn't get anymore module panic and usb lockups
> 
> so it seems there's something to be done WRT reliability on "corner 
> cases". if i'll have more info about this topic i'll keep you posted.

Yes, definitely.  In fact, what would REALLY be helpful is if you can 
document a specific sequence of actions that leads to an oops.  Then I 
can try to repeat it here and hopefully shortly afterwards find the root 
cause.


   [...]

> 
> it just seems that, on signal absence, you are just printing on the 
> device info report, some NTSC default.
> 
> could it be?

Actually *I* don't print this.  The cx2341x module is generating this 
info.  Quite likely this is harmless as the encoder configuration data 
is really only important when the encoder is actually in use.  The 
cx25840 module's printout can be similarly confusing (e.g. printing info 
that isn't useful at the time because streaming isn't actually 
underway).  One thing that aggravates this slightly is the the pvrusb2 
driver at the end of its initialization right now deliberately triggers 
a request to various modules to dump their state to the system log - and 
that's a point in time when there isn't any streaming going on.  However 
I've found this is still useful because it can tell us if the other 
modules have been loaded properly or (in the case of cx25840) if the 
chip's firmware had not been properly loaded.

   [...]

> 
> on the back of the motherboard there is the "culprit": the AD converter 
> Cirrus CS5340
> 
>    http://www.cirrus.com/en/pubs/proDatasheet/CS5340_F1.pdf
> 
> i don't get it if it's programmable so maybe it's a matter of xtal on 
> the board. i can see three: the freq. seems 24.00, 27.00 and 28.6363
> 
> but, anyway, i really don't know how i can control this little beast to 
> get good audio quality (i.e. the right sampling rate..)

I will examine that datasheet.  Given the behavior you've observed so 
far, it seems like there is *something* we still must do to configure it 
correctly.  There's another device that the pvrusb2 driver can operate 
which has a different Cirrus Logic ADC on it - that chip needed some 
configuration over I2C but all I had to do was ensure that the already 
existing V4L chip-level driver for got loaded and then it magically went 
off and fixed everything with virtually zero additional help.

   [...]

> 
> Luma2 should be the right one for luminance, because i can see black and 
> white only. (of course the composite input is empty on the device..
> 
> i tried to define other chroma input like CHROMA1 CHROMA2 and CHROMA3
> 
> but, if i use them i get on the dmesg log this message:
> 
> [15041.657615] cx25840 0-0044: 0x0220 is not a valid video input!
> ...
> [............] cx25840 0-0044: 0x0320 is not a valid video input!
> ...
> [............] cx25840 0-0044: 0x0120 is not a valid video input!
> 
> maybe it's only a guard inside the linux driver. i really don't know how 
> it's working this cx25840.. i need to look to a datasheet

You *definitely* need to look at the cx25840 datasheet.  The cx25840 
module has a bunch of enum values defined to control these settings.  A 
few enums cover common cases, but as I am sure you can tell from looking 
at the pvrusb2 code for this that there's already one case I know of 
which is not "common".  If you study the datasheet (specifically with 
regards to how its inputs are laid how and the registers which set them 
up), then the enums will probably make more sense and then you can learn 
how to set up combinations that are legal for the driver.


> 
> but maybe i can give a thorough look to the .inf file in the windows 
> driver? tomorrow i'll try!

Certainly possible but I can't really know from here.  Your best bet 
might be to contact the vendor for the magic info.  It's possible they 
provide that information directly (in another case that's how we solved 
it).  It's possible that vendors outside the USA (and not so entangled 
with / married to / enamored with Microsoft's, uh, "product") might be 
more forthcoming.

  -Mike

-- 
                        |         Mike Isely          |     PGP fingerprint
     Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                        |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                        |                             |