[pvrusb2] Terratec Grabster AV400

[Mike Isely]

On Fri, 15 May 2009, Sven Barth wrote:

> Hello again!
> 
> I managed to wrap the cs5345 (at least I hope that I did so... I just copied
> the cs53l32a and replaced everything...) and included it everywhere the
> cs53l32a is included. I also added the cs5435 to the av400 in devattr.c. The
> driver still compiles and works as before, but that's it...
> 
> I need some help from you:
> 
> - Where or how can I check the i2c address of the cs5345 (I copied \x11 from
> cs53l32a for now)?

The value \x11 is actually 0x11 of course, which would be the expected 
I2C address for the cs53l32a (for an OnAir device).  You would need to 
replace that value with the correct one.

> dmesg prints this:
> cs5345 2-0011: chip found @ 0x22 (pvrusb2_a)
> pvrusb2: Attached sub-driver cs5345

Odds are pretty good that the correct value is 0x22.

We're in the midst of a change in how v4l-dvb binds client drivers to 
I2C addresses so it probably worked itself out but in the future we need 
to make sure that value is correct.


> 
> - How do I disable the audio routing of the cx2584x? Or is that what I hear
> the cs5345 initialized with default values? If so, how can I check if I can
> control the chip now? Changing the audio bitrate?

You don't want to disable audio routing of the cx2584x.  Audio is likely 
still going through this part; but that other chip is probably doing the 
A/D conversion and feeding that result to the cx2584x.  At least that's 
the way it has worked in every other device I've seen.


> 
> Btw: what does this message in dmesg mean: cx25840 2-0044: 0x0000 is not a
> valid video input!
> It occurs after loading the firmware.

This is probably happening because the cx25840 is being fed an input 
choice that is invalid.

On hybrid devices this can happen when we're in digital mode; in that 
case the driver is just feeding junk to this chip but that's OK because 
when in digital mode this chip is not used.

In your case there of course is no digital mode, but if I understand 
that part correctly it lacks an RF tuner.  The routing scheme set up for 
the cx2584x in this case doesn't define a setting for "TV" mode.  The 
driver also should not be selecting the TV input (it is disabled in the 
device's entry in pvrusb2-devattr.c), but there might be a problem where 
it is at least momentarily trying to select a TV input right at 
initialization.

Assuming that we've got the right A/D module here, one thing you're 
going to have to do is figure out how to program its routing scheme.  
That's the routing_schemeX array in the source file.  What was there for 
the cs53l32a is almost certainly not correct for the cs5345.  Providing 
that routing information to the module in fact is pretty much the whole 
reason for that wrapper module - unlike most commands given to all the 
modules which are not module-specific, routing information is a very 
chip-specific thing.  Unfortunately I can't tell you what is correct 
here.  What I usually do is some combination of the following:

1. Find a datasheet for the chip, read it and figure out what kinds of 
inputs it has.

2. Look at the source for the corresponding v4l-dvb module and examine 
what it does with any routing information provided.

3. Start taking guesses at it based on (1) and (2) until I get 
reasonable results.  This part is kind of blind because part of this 
answer is probably going to depend on how the board has been wired, i.e. 
which inputs are actually wired up and what they are wired to.

In your case there's really only one physical audio input so (3) might 
be easier to guess.

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8