[pvrusb2] Terratec Grabster AV400

[Mike Isely]

On Sat, 16 May 2009, Sven Barth wrote:

> Hi again!
> 
> I checked your cx25840 code and realized that you issue two calls to the
> module, one for video and one for audio. But in the debug output is only one
> "set" message. Swaping the two calls made no difference so I checked the
> cx25840-core.c code again and the problem hit me like a lightning strike:
> 
> static int cx25840_s_audio_routing(struct v4l2_subdev *sd, const struct
> v4l2_routing *route)
> {
>        struct cx25840_state *state = to_state(sd);
>        struct i2c_client *client = v4l2_get_subdevdata(sd);
> 
>    // WE ARE BLOCKED HERE!!!!!!
>      if (state->is_cx25836)
>                return -EINVAL;
>        return set_input(client, state->vid_input, route->input);
> }
> 
> 
> So I commented that if-statement and I now I get two "set" messages in dmesg,
> BUT it doesn't solve the problem... :( only the changed default value does.
> 
> If the cx25836 (or cx25837 in my case, according to dmesg) does not support
> audio routing (like the if-statement is suggesting) would it be useful to ask
> the v4l-devs to initialize the device with AUDIO_SERIAL? I will investigate
> this module a bit more to check its initialization...
> 
> But I won't do this today. It is getting late here (nearly midnight) ^^

Sounds like you've hit some interesting clues.  So the cx25840 module 
might be reacting incorrectly to the particular variant chip that's on 
your device.  Keep going.

You might want to carefully trace the flow through the cx25840 module in 
how it handles the default value.  That will probably yield some key 
clues.

  -Mike

-- 

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