Problem with cx25840 and Terratec Grabster AV400

Problem with cx25840 and Terratec Grabster AV400

[Sven Barth]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

Hello together!

I'm the owner of a Terratec Grabster AV400, which is supported by the 
pvrusb2 (currently standalone version only). Video works well, but I 
have a problem with audio, when I use an unmodified v4l-dvb: the audio 
is too slow, as if the bitrate is set to low.

The device contains a cx25837-3 (according to dmesg) and audio routing 
has to be set to CX25840_AUDIO_SERIAL.

The problem now is, that this audio route setting is never applied, 
because there are (at least) two locations in cx25840-core.c where a 
check with is_cx2583x is done.
Locally I've simply disabled that checks (see attached patch) and the 
AV400 works as expected now. Of course this can't be the correct 
solution for the official v4l. Also I have to apply that patch after 
every kernel update (which happens rather often with ArchLinux ^^).

Thus I ask how this situation might be solved so that I can use the 
AV400 without patching around in the source of v4l.

Attached:
* dmesg output with unpatched cx25840 module
* my "quick & dirty" patch for cx25840-core.c

Regards,
Sven

[-- Attachment #2: dmesg-log.txt --]
[-- Type: text/plain, Size: 1963 bytes --]

usb 1-5: new high speed USB device using ehci_hcd and address 9
pvrusb2: Hardware description: Terratec Grabster AV400
cx25840 4-0044: cx25837-3 found @ 0x88 (pvrusb2_a)
pvrusb2: Attached sub-driver cx25840
pvrusb2: Supported video standard(s) reported available in hardware: PAL-B/B1/D/D1/G/H/I/K/M/N/Nc/60;NTSC-M/
pvrusb2: Mapping standards mask=0xffffff (PAL-B/B1/D/D1/G/H/I/K/M/N/Nc/60;NTSC-M/Mj/443/Mk;SECAM-B/D/G/H/K/K1/L/LC)
pvrusb2: Setting up 28 unique standard(s)
pvrusb2: Set up standard idx=0 name=PAL-B/G
pvrusb2: Set up standard idx=1 name=PAL-D/K
pvrusb2: Set up standard idx=2 name=SECAM-B/G
pvrusb2: Set up standard idx=3 name=SECAM-D/K
pvrusb2: Set up standard idx=4 name=NTSC-M
pvrusb2: Set up standard idx=5 name=NTSC-Mj
pvrusb2: Set up standard idx=6 name=NTSC-443
pvrusb2: Set up standard idx=7 name=NTSC-Mk
pvrusb2: Set up standard idx=8 name=PAL-B
pvrusb2: Set up standard idx=9 name=PAL-B1
pvrusb2: Set up standard idx=10 name=PAL-G
pvrusb2: Set up standard idx=11 name=PAL-H
pvrusb2: Set up standard idx=12 name=PAL-I
pvrusb2: Set up standard idx=13 name=PAL-D
pvrusb2: Set up standard idx=14 name=PAL-D1
pvrusb2: Set up standard idx=15 name=PAL-K
pvrusb2: Set up standard idx=16 name=PAL-M
pvrusb2: Set up standard idx=17 name=PAL-N
pvrusb2: Set up standard idx=18 name=PAL-Nc
pvrusb2: Set up standard idx=19 name=PAL-60
pvrusb2: Set up standard idx=20 name=SECAM-B
pvrusb2: Set up standard idx=21 name=SECAM-D
pvrusb2: Set up standard idx=22 name=SECAM-G
pvrusb2: Set up standard idx=23 name=SECAM-H
pvrusb2: Set up standard idx=24 name=SECAM-K
pvrusb2: Set up standard idx=25 name=SECAM-K1
pvrusb2: Set up standard idx=26 name=SECAM-L
pvrusb2: Set up standard idx=27 name=SECAM-LC
pvrusb2: Initial video standard auto-selected to PAL-B/G
pvrusb2: Device initialization completed successfully.
usb 1-5: firmware: requesting v4l-cx2341x-enc.fw
pvrusb2: registered device video0 [mpeg]
cx25840 4-0044: 0x0000 is not a valid video input!

[-- Attachment #3: cx25840-core.patch --]
[-- Type: text/plain, Size: 758 bytes --]

--- v4l-src/linux/drivers/media/video/cx25840/cx25840-core.c	2010-04-24 10:48:56.392367351 +0200
+++ v4l-build/linux/drivers/media/video/cx25840/cx25840-core.c	2010-04-24 14:54:08.797561848 +0200
@@ -849,10 +849,10 @@
 
 	state->vid_input = vid_input;
 	state->aud_input = aud_input;
-	if (!is_cx2583x(state)) {
+//	if (!is_cx2583x(state)) {
 		cx25840_audio_set_path(client);
 		input_change(client);
-	}
+//	}
 
 	if (is_cx2388x(state)) {
 		/* Audio channel 1 src : Parallel 1 */
@@ -1504,8 +1504,8 @@
 	struct cx25840_state *state = to_state(sd);
 	struct i2c_client *client = v4l2_get_subdevdata(sd);
 
-	if (is_cx2583x(state))
-		return -EINVAL;
+/*	if (is_cx2583x(state))
+		return -EINVAL;*/
 	return set_input(client, state->vid_input, input);
 }
 

Re: Problem with cx25840 and Terratec Grabster AV400

[Mike Isely]

Actually the support in the pvrusb2 driver was never really completed.  
But since I don't have a sample of the hardware here I went on ahead and 
merged what was there so that it could get exposure and the remaining 
problems sorted out.

  -Mike


On Sat, 24 Apr 2010, Sven Barth wrote:

> Hello together!
> 
> I'm the owner of a Terratec Grabster AV400, which is supported by the pvrusb2
> (currently standalone version only). Video works well, but I have a problem
> with audio, when I use an unmodified v4l-dvb: the audio is too slow, as if the
> bitrate is set to low.
> 
> The device contains a cx25837-3 (according to dmesg) and audio routing has to
> be set to CX25840_AUDIO_SERIAL.
> 
> The problem now is, that this audio route setting is never applied, because
> there are (at least) two locations in cx25840-core.c where a check with
> is_cx2583x is done.
> Locally I've simply disabled that checks (see attached patch) and the AV400
> works as expected now. Of course this can't be the correct solution for the
> official v4l. Also I have to apply that patch after every kernel update (which
> happens rather often with ArchLinux ^^).
> 
> Thus I ask how this situation might be solved so that I can use the AV400
> without patching around in the source of v4l.
> 
> Attached:
> * dmesg output with unpatched cx25840 module
> * my "quick & dirty" patch for cx25840-core.c
> 
> Regards,
> Sven
> 

-- 

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

Re: Problem with cx25840 and Terratec Grabster AV400

[Sven Barth]

On 24.04.2010 19:13, Mike Isely wrote:
>
> Actually the support in the pvrusb2 driver was never really completed.
> But since I don't have a sample of the hardware here I went on ahead and
> merged what was there so that it could get exposure and the remaining
> problems sorted out.
>
>    -Mike
>

Hi!

Although you never really completed that support for the AV400 it runs 
pretty well once you've touched the cx25840 source. I'm using it for 
months now and it runs better than it did with Windows (I sometimes had 
troubles with audio there which led to an "out of sync" audio track).

I wrote the last mail, because I want to sort out why the cx25837 chip 
in my device is behaving differently than expected by the corresponding 
driver and to remove the need to patch the v4l sources manually.
Once I don't need to fear that the next system update breaks the device 
again (because cx25840.ko is overwritten), I'm more then willed to help 
you to complete the support for my device in your driver (feature 
testing, etc).

Regards,
Sven

PS: Did you read my mail from last December? 
http://www.isely.net/pipermail/pvrusb2/2009-December/002716.html

Re: Problem with cx25840 and Terratec Grabster AV400

[Mike Isely]

On Sat, 24 Apr 2010, Sven Barth wrote:

> On 24.04.2010 19:13, Mike Isely wrote:
> > 
> > Actually the support in the pvrusb2 driver was never really completed.
> > But since I don't have a sample of the hardware here I went on ahead and
> > merged what was there so that it could get exposure and the remaining
> > problems sorted out.
> > 
> >    -Mike
> > 
> 
> Hi!
> 
> Although you never really completed that support for the AV400 it runs pretty
> well once you've touched the cx25840 source. I'm using it for months now and
> it runs better than it did with Windows (I sometimes had troubles with audio
> there which led to an "out of sync" audio track).

Unfortunately I can't really "say" it is supported in the pvrusb2 driver 
until it actually works well enough that a user doesn't have to hack 
driver source (pvrusb2 or otherwise).  Otherwise I'm just going to get 
inundated with help requests for this.  Not having a sample of the 
device here I'm handicapped from debugging such issues.

I've just made a change to the pvrusb2 driver to allow for the ability 
to mark a piece of hardware (such as this device) as "experimental".  
Such devices will generate a warning in the kernel log upon 
initialization.  The experimental marker doesn't impact the ability to 
use the device; it just triggers the warning message.  Once we know the 
device is working acceptably well enough, the marker can be turned off.  
This should help avoid misleading others about whether or not the 
pvrusb2 driver fully supports a particular piece of hardware.


> 
> I wrote the last mail, because I want to sort out why the cx25837 chip in my
> device is behaving differently than expected by the corresponding driver and
> to remove the need to patch the v4l sources manually.
> Once I don't need to fear that the next system update breaks the device again
> (because cx25840.ko is overwritten), I'm more then willed to help you to
> complete the support for my device in your driver (feature testing, etc).

We definitely need to do this.


> 
> Regards,
> Sven
> 
> PS: Did you read my mail from last December?
> http://www.isely.net/pipermail/pvrusb2/2009-December/002716.html

Yeah, I saw it back then, and then I probably got distracted away :-(

The key issue is that your hardware doesn't seem to work until you make 
those two changes to the v4l-dvb cx25840 driver.  Obviously one can't 
just make those changes without understanding the implications for other 
users of the driver.  I (or someone expert at the cx25840 module) needs 
to study that patch and understand what is best to do for the driver.

  -Mike


-- 

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

Re: Problem with cx25840 and Terratec Grabster AV400

[Sven Barth]

Hi!

On 24.04.2010 22:24, Mike Isely wrote:
> On Sat, 24 Apr 2010, Sven Barth wrote:
>>
>> Hi!
>>
>> Although you never really completed that support for the AV400 it runs pretty
>> well once you've touched the cx25840 source. I'm using it for months now and
>> it runs better than it did with Windows (I sometimes had troubles with audio
>> there which led to an "out of sync" audio track).
>
> Unfortunately I can't really "say" it is supported in the pvrusb2 driver
> until it actually works well enough that a user doesn't have to hack
> driver source (pvrusb2 or otherwise).  Otherwise I'm just going to get
> inundated with help requests for this.  Not having a sample of the
> device here I'm handicapped from debugging such issues.
>

I don't want to have this hacking as much as you do. But currently it's 
the only way that works for me (I'm really glad that it has come that 
far ^^)...
I'll try to help here as good as I can (and time permits) to solve this 
issue.

> I've just made a change to the pvrusb2 driver to allow for the ability
> to mark a piece of hardware (such as this device) as "experimental".
> Such devices will generate a warning in the kernel log upon
> initialization.  The experimental marker doesn't impact the ability to
> use the device; it just triggers the warning message.  Once we know the
> device is working acceptably well enough, the marker can be turned off.
> This should help avoid misleading others about whether or not the
> pvrusb2 driver fully supports a particular piece of hardware.
>

No offense intended, but do you really think that people will read that? 
Normal users (using Ubuntu, etc) don't really care whether their device 
is marked as experimental or not... they just want it to work and thus 
can go to great lengths to "disturb" the developers working on their 
driver...

>> PS: Did you read my mail from last December?
>> http://www.isely.net/pipermail/pvrusb2/2009-December/002716.html
>
> Yeah, I saw it back then, and then I probably got distracted away :-(

I know that problem pretty well. ^^ I was only curious.

>
> The key issue is that your hardware doesn't seem to work until you make
> those two changes to the v4l-dvb cx25840 driver.  Obviously one can't
> just make those changes without understanding the implications for other
> users of the driver.  I (or someone expert at the cx25840 module) needs
> to study that patch and understand what is best to do for the driver.
>
>    -Mike
>
>

It would be interesting to know why the v4l devs disabled the audio 
routing for cx2583x chips and whether it was intended that a cx25837 
chip gets the same treatment as a e.g. cx25836.
And those "implications" you're talking about is the reason why I wrote 
here: I want to check whether there is a better or more correct way than 
to disable those checks (it works here, because I have only that one 
device that contains a cx2583x chip...).

Just a thought: can it be that my chip's audio routing isn't set to the 
correct value after initialization and thus it needs to be set at least 
once, while all other chips default to a working routing after 
initialization? Could be a design mistake done by Terratec...

Regards,
Sven

Re: Problem with cx25840 and Terratec Grabster AV400

[Mike Isely]

On Sat, 24 Apr 2010, Sven Barth wrote:

> Hi!
> 
> On 24.04.2010 22:24, Mike Isely wrote:
> > On Sat, 24 Apr 2010, Sven Barth wrote:
> > > 
> > > Hi!
> > > 
> > > Although you never really completed that support for the AV400 it runs
> > > pretty
> > > well once you've touched the cx25840 source. I'm using it for months now
> > > and
> > > it runs better than it did with Windows (I sometimes had troubles with
> > > audio
> > > there which led to an "out of sync" audio track).
> > 
> > Unfortunately I can't really "say" it is supported in the pvrusb2 driver
> > until it actually works well enough that a user doesn't have to hack
> > driver source (pvrusb2 or otherwise).  Otherwise I'm just going to get
> > inundated with help requests for this.  Not having a sample of the
> > device here I'm handicapped from debugging such issues.
> > 
> 
> I don't want to have this hacking as much as you do. But currently it's the
> only way that works for me (I'm really glad that it has come that far ^^)...
> I'll try to help here as good as I can (and time permits) to solve this issue.

I understand.


> 
> > I've just made a change to the pvrusb2 driver to allow for the ability
> > to mark a piece of hardware (such as this device) as "experimental".
> > Such devices will generate a warning in the kernel log upon
> > initialization.  The experimental marker doesn't impact the ability to
> > use the device; it just triggers the warning message.  Once we know the
> > device is working acceptably well enough, the marker can be turned off.
> > This should help avoid misleading others about whether or not the
> > pvrusb2 driver fully supports a particular piece of hardware.
> > 
> 
> No offense intended, but do you really think that people will read that?
> Normal users (using Ubuntu, etc) don't really care whether their device is
> marked as experimental or not... they just want it to work and thus can go to
> great lengths to "disturb" the developers working on their driver...

No offense taken.  Not a problem.  But I felt it was at least important 
enough for the driver to document this fact.  For those who use the 
device who are capable of attempting some hacking - those people WILL 
see the message and hopefully that will encourage such folks to contact 
the author (me) for assistance in further stabilizing the device.

The intent wasn't for the flag to be any excuse not to work on it - I 
just want to leave a marker indicating that the driver is not expected 
to be fully working (or "supported") at this time.


> 
> > > PS: Did you read my mail from last December?
> > > http://www.isely.net/pipermail/pvrusb2/2009-December/002716.html
> > 
> > Yeah, I saw it back then, and then I probably got distracted away :-(
> 
> I know that problem pretty well. ^^ I was only curious.

Spending a lot of time today catching up on stuff like this.  Just 
smoked out two kernel oopses in the driver today as well.


> 
> > 
> > The key issue is that your hardware doesn't seem to work until you make
> > those two changes to the v4l-dvb cx25840 driver.  Obviously one can't
> > just make those changes without understanding the implications for other
> > users of the driver.  I (or someone expert at the cx25840 module) needs
> > to study that patch and understand what is best to do for the driver.
> > 
> >    -Mike
> > 
> > 
> 

> It would be interesting to know why the v4l devs disabled the audio routing
> for cx2583x chips and whether it was intended that a cx25837 chip gets the
> same treatment as a e.g. cx25836.

I wish I could provide specific information about that :-(


> And those "implications" you're talking about is the reason why I wrote here:
> I want to check whether there is a better or more correct way than to disable
> those checks (it works here, because I have only that one device that contains
> a cx2583x chip...).

> Just a thought: can it be that my chip's audio routing isn't set to the
> correct value after initialization and thus it needs to be set at least once,
> while all other chips default to a working routing after initialization? Could
> be a design mistake done by Terratec...

There is no one "correct" audio routing.  And by "audio routing" I mean 
the wiring between the chip and the various audio inputs that feed it.  
The choice for how to route all this is up to the vendor of the device.  
In many cases there is a common reference design that the vendor starts 
from, in which case such routing will be more common across devices.  
But that's just luck really.  The cx25840 driver provides an API to 
things like the pvrusb2 driver to select the proper routing based on 
that bridge driver's knowledge of the surrounding hardware.  This is one 
of the areas that have to be worked on when porting to a new device.  
The PVR2_ROUTING_SCHEME_xxxx enumeration in the pvrusb2 driver is part 
of this.

With that all said I haven't looked closely enough at your patch to the 
cx25840 module so I'm only assuming that we're talking about the same 
thing here.  I have a funny feeling that you're hitting on something 
else however.  I need to look at this more closely.

  -Mike


-- 

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

Re: Problem with cx25840 and Terratec Grabster AV400

[Andy Walls]

On Sat, 2010-04-24 at 22:54 +0200, Sven Barth wrote:

> 
> It would be interesting to know why the v4l devs disabled the audio 
> routing for cx2583x chips and whether it was intended that a cx25837 
> chip gets the same treatment as a e.g. cx25836.
> And those "implications" you're talking about is the reason why I wrote 
> here: I want to check whether there is a better or more correct way than 
> to disable those checks (it works here, because I have only that one 
> device that contains a cx2583x chip...).

The CX25836 and CX25837 do not have any audio functions.  They are video
only chips.

The only difference between the chips is that the CX25837 comes in two
different packages and has a version that is pin compatible with the
CX2584[0123] chips.

The public data sheet is here:

http://www.conexant.com/products/entry.jsp?id=77


Note that the CX2583x chip do have an AUX_PLL which can be output from
the chip as an audio clock.


> Just a thought: can it be that my chip's audio routing isn't set to the 
> correct value after initialization and thus it needs to be set at least 
> once, while all other chips default to a working routing after 
> initialization? Could be a design mistake done by Terratec...

No chip defaults are what they are, most people don't design a board to
match up with them.

I does look like Terratec saved themselves an external oscillator by
using the AUX_PLL in the CX2583x as an audio clock.


As for your changes.  They are wrong, but in a benign way I think.
There is no real penalty for writing to the "Merlin" audio core
registers that don't exist in this chip (0x800-0x9ff), as long as the
chip is decoding all the address bits properly and not wrapping them
back down to the "Thresher" video core registers at 0x000-0x1ff.  


As for your first change:

        @@ -849,10 +849,10 @@
         
                state->vid_input = vid_input;
                state->aud_input = aud_input;
        -       if (!is_cx2583x(state)) {
        +//     if (!is_cx2583x(state)) {
                        cx25840_audio_set_path(client);
                        input_change(client);
        -       }
        +//     }
         
                if (is_cx2388x(state)) {
                        /* Audio channel 1 src : Parallel 1 */

This is incomplete.  Along with removing the check, you need to "push
down" the is_cx2583x() check into input_change() and
cx25840_audio_set_path().  What you likely also need to do for a CX2583x
is:

a. Modify input_change() to add is_cx2583x() checks to avoid the
operations on registers in the 0x800-0x9ff range, but still let the
operations to registers in the 0x400-0x4ff range be performed.  These
are Chroma processing settings that may have some effect on your video.

b. Modify cx25840_audio_set_path() to add is_cx2583x() checks to avoid
the operations on registers in the 0x800-0x9ff range, but still let the
call to set_audclk_freq() go through.  From there
cx25836_set_audclk_freq() and cx25840_set_audclk_freq() will set up the
PLLs while avoiding writes to registers in the 0x800-0x9ff range for the
CX2583x chips.


Let's look at your second change:

        @@ -1504,8 +1504,8 @@
                struct cx25840_state *state = to_state(sd);
                struct i2c_client *client = v4l2_get_subdevdata(sd);
         
        -       if (is_cx2583x(state))
        -               return -EINVAL;
        +/*     if (is_cx2583x(state))
        +               return -EINVAL;*/
                return set_input(client, state->vid_input, input);
         }

If you made the proper changes to

	set_input()
		cx25840_audio_set_path()
			set_audclk_freq()
				cx25836_set_audclk_freq()
					cx25840_set_audclk_freq()
		input_change()

then you have already pushed this check down to several places and
allowed AUX_PLL reconfiguration to take place.  Thus it is then correct
to remove the check from here.




Well, that's my guess anyway.  Did it all make sense?

Regards,
Andy

Re: Problem with cx25840 and Terratec Grabster AV400

[Sven Barth]

[-- Attachment #1: Type: text/plain, Size: 4638 bytes --]

Hi!

On 25.04.2010 02:59, Andy Walls wrote:
> On Sat, 2010-04-24 at 22:54 +0200, Sven Barth wrote:
>
>>
>> It would be interesting to know why the v4l devs disabled the audio
>> routing for cx2583x chips and whether it was intended that a cx25837
>> chip gets the same treatment as a e.g. cx25836.
>> And those "implications" you're talking about is the reason why I wrote
>> here: I want to check whether there is a better or more correct way than
>> to disable those checks (it works here, because I have only that one
>> device that contains a cx2583x chip...).
>
> The CX25836 and CX25837 do not have any audio functions.  They are video
> only chips.
>
> The only difference between the chips is that the CX25837 comes in two
> different packages and has a version that is pin compatible with the
> CX2584[0123] chips.
>
> The public data sheet is here:
>
> http://www.conexant.com/products/entry.jsp?id=77
>
>
> Note that the CX2583x chip do have an AUX_PLL which can be output from
> the chip as an audio clock.
>

Well... that explains the is_cx2583x checks ^^

>
>> Just a thought: can it be that my chip's audio routing isn't set to the
>> correct value after initialization and thus it needs to be set at least
>> once, while all other chips default to a working routing after
>> initialization? Could be a design mistake done by Terratec...
>
> No chip defaults are what they are, most people don't design a board to
> match up with them.
>
> I does look like Terratec saved themselves an external oscillator by
> using the AUX_PLL in the CX2583x as an audio clock.
>

It seems as if that is the case...

>
> As for your changes.  They are wrong, but in a benign way I think.
> There is no real penalty for writing to the "Merlin" audio core
> registers that don't exist in this chip (0x800-0x9ff), as long as the
> chip is decoding all the address bits properly and not wrapping them
> back down to the "Thresher" video core registers at 0x000-0x1ff.
>

I never thought of those changes as a real solution, but merely as a 
work around or a first step for finding the real issue. ^^

>
> As for your first change:
>
>          @@ -849,10 +849,10 @@
>
>                  state->vid_input = vid_input;
>                  state->aud_input = aud_input;
>          -       if (!is_cx2583x(state)) {
>          +//     if (!is_cx2583x(state)) {
>                          cx25840_audio_set_path(client);
>                          input_change(client);
>          -       }
>          +//     }
>
>                  if (is_cx2388x(state)) {
>                          /* Audio channel 1 src : Parallel 1 */
>
> This is incomplete.  Along with removing the check, you need to "push
> down" the is_cx2583x() check into input_change() and
> cx25840_audio_set_path().  What you likely also need to do for a CX2583x
> is:
>
> a. Modify input_change() to add is_cx2583x() checks to avoid the
> operations on registers in the 0x800-0x9ff range, but still let the
> operations to registers in the 0x400-0x4ff range be performed.  These
> are Chroma processing settings that may have some effect on your video.
>
> b. Modify cx25840_audio_set_path() to add is_cx2583x() checks to avoid
> the operations on registers in the 0x800-0x9ff range, but still let the
> call to set_audclk_freq() go through.  From there
> cx25836_set_audclk_freq() and cx25840_set_audclk_freq() will set up the
> PLLs while avoiding writes to registers in the 0x800-0x9ff range for the
> CX2583x chips.
>
>
> Let's look at your second change:
>
>          @@ -1504,8 +1504,8 @@
>                  struct cx25840_state *state = to_state(sd);
>                  struct i2c_client *client = v4l2_get_subdevdata(sd);
>
>          -       if (is_cx2583x(state))
>          -               return -EINVAL;
>          +/*     if (is_cx2583x(state))
>          +               return -EINVAL;*/
>                  return set_input(client, state->vid_input, input);
>           }
>
> If you made the proper changes to
>
> 	set_input()
> 		cx25840_audio_set_path()
> 			set_audclk_freq()
> 				cx25836_set_audclk_freq()
> 					cx25840_set_audclk_freq()
> 		input_change()
>
> then you have already pushed this check down to several places and
> allowed AUX_PLL reconfiguration to take place.  Thus it is then correct
> to remove the check from here.
>
>

Ok... I've done those changes, so that only set_audclk_freq is called on 
cx2583x chips and guess what: it works! :D (see attached patch)

>
>
> Well, that's my guess anyway.  Did it all make sense?
>
> Regards,
> Andy
>

Well... your guess was right. And it made sense (so much, that it even 
works ^^).

Regards,
Sven

[-- Attachment #2: cx25840.patch --]
[-- Type: text/plain, Size: 4739 bytes --]

diff -aur v4l-src/linux/drivers/media/video/cx25840//cx25840-audio.c v4l-build/linux/drivers/media/video/cx25840//cx25840-audio.c
--- v4l-src/linux/drivers/media/video/cx25840//cx25840-audio.c	2009-10-18 21:08:26.497700904 +0200
+++ v4l-build/linux/drivers/media/video/cx25840//cx25840-audio.c	2010-04-25 17:16:00.205619872 +0200
@@ -438,41 +438,45 @@
 {
 	struct cx25840_state *state = to_state(i2c_get_clientdata(client));
 
-	/* assert soft reset */
-	cx25840_and_or(client, 0x810, ~0x1, 0x01);
-
-	/* stop microcontroller */
-	cx25840_and_or(client, 0x803, ~0x10, 0);
-
-	/* Mute everything to prevent the PFFT! */
-	cx25840_write(client, 0x8d3, 0x1f);
-
-	if (state->aud_input == CX25840_AUDIO_SERIAL) {
-		/* Set Path1 to Serial Audio Input */
-		cx25840_write4(client, 0x8d0, 0x01011012);
-
-		/* The microcontroller should not be started for the
-		 * non-tuner inputs: autodetection is specific for
-		 * TV audio. */
-	} else {
-		/* Set Path1 to Analog Demod Main Channel */
-		cx25840_write4(client, 0x8d0, 0x1f063870);
-	}
+        if (!is_cx2583x(state)) {
+		/* assert soft reset */
+		cx25840_and_or(client, 0x810, ~0x1, 0x01);
+
+		/* stop microcontroller */
+		cx25840_and_or(client, 0x803, ~0x10, 0);
+
+		/* Mute everything to prevent the PFFT! */
+		cx25840_write(client, 0x8d3, 0x1f);
+
+		if (state->aud_input == CX25840_AUDIO_SERIAL) {
+			/* Set Path1 to Serial Audio Input */
+			cx25840_write4(client, 0x8d0, 0x01011012);
+
+			/* The microcontroller should not be started for the
+			 * non-tuner inputs: autodetection is specific for
+			 * TV audio. */
+		} else {
+			/* Set Path1 to Analog Demod Main Channel */
+			cx25840_write4(client, 0x8d0, 0x1f063870);
+		}
+        }
 
 	set_audclk_freq(client, state->audclk_freq);
 
-	if (state->aud_input != CX25840_AUDIO_SERIAL) {
-		/* When the microcontroller detects the
-		 * audio format, it will unmute the lines */
-		cx25840_and_or(client, 0x803, ~0x10, 0x10);
-	}
-
-	/* deassert soft reset */
-	cx25840_and_or(client, 0x810, ~0x1, 0x00);
-
-	/* Ensure the controller is running when we exit */
-	if (is_cx2388x(state) || is_cx231xx(state))
-		cx25840_and_or(client, 0x803, ~0x10, 0x10);
+        if (!is_cx2583x(state)) {
+		if (state->aud_input != CX25840_AUDIO_SERIAL) {
+			/* When the microcontroller detects the
+			 * audio format, it will unmute the lines */
+			cx25840_and_or(client, 0x803, ~0x10, 0x10);
+		}
+
+		/* deassert soft reset */
+		cx25840_and_or(client, 0x810, ~0x1, 0x00);
+
+		/* Ensure the controller is running when we exit */
+		if (is_cx2388x(state) || is_cx231xx(state))
+			cx25840_and_or(client, 0x803, ~0x10, 0x10);
+        }
 }
 
 static int get_volume(struct i2c_client *client)
Nur in v4l-build/linux/drivers/media/video/cx25840/: cx25840-audio.c.bak.
diff -aur v4l-src/linux/drivers/media/video/cx25840//cx25840-core.c v4l-build/linux/drivers/media/video/cx25840//cx25840-core.c
--- v4l-src/linux/drivers/media/video/cx25840//cx25840-core.c	2010-04-24 10:48:56.392367351 +0200
+++ v4l-build/linux/drivers/media/video/cx25840//cx25840-core.c	2010-04-25 17:12:37.448983292 +0200
@@ -691,6 +691,11 @@
 	}
 	cx25840_and_or(client, 0x401, ~0x60, 0);
 	cx25840_and_or(client, 0x401, ~0x60, 0x60);
+
+        /* Don't write into audio registers on cx2583x chips */
+        if (is_cx2583x(state))
+        	return;
+
 	cx25840_and_or(client, 0x810, ~0x01, 1);
 
 	if (state->radio) {
@@ -704,8 +709,7 @@
 		   To be precise: it affects cards with tuner models
 		   85, 99 and 112 (model numbers from tveeprom). */
 		int hw_fix = state->pvr150_workaround;
-
-		if (std == V4L2_STD_NTSC_M_JP) {
+			if (std == V4L2_STD_NTSC_M_JP) {
 			/* Japan uses EIAJ audio standard */
 			cx25840_write(client, 0x808, hw_fix ? 0x2f : 0xf7);
 		} else if (std == V4L2_STD_NTSC_M_KR) {
@@ -742,7 +746,6 @@
 			cx25840_write(client, 0x80b, 0x10);
 	       }
 	}
-
 	cx25840_and_or(client, 0x810, ~0x01, 0);
 }
 
@@ -849,10 +852,8 @@
 
 	state->vid_input = vid_input;
 	state->aud_input = aud_input;
-	if (!is_cx2583x(state)) {
-		cx25840_audio_set_path(client);
-		input_change(client);
-	}
+	cx25840_audio_set_path(client);
+	input_change(client);
 
 	if (is_cx2388x(state)) {
 		/* Audio channel 1 src : Parallel 1 */
@@ -1504,8 +1505,6 @@
 	struct cx25840_state *state = to_state(sd);
 	struct i2c_client *client = v4l2_get_subdevdata(sd);
 
-	if (is_cx2583x(state))
-		return -EINVAL;
 	return set_input(client, state->vid_input, input);
 }
 
@@ -1514,8 +1513,7 @@
 	struct cx25840_state *state = to_state(sd);
 	struct i2c_client *client = v4l2_get_subdevdata(sd);
 
-	if (!is_cx2583x(state))
-		input_change(client);
+	input_change(client);
 	return 0;
 }
 
Nur in v4l-build/linux/drivers/media/video/cx25840/: cx25840-core.c.bak.