By Date: <-- -->
By Thread: <-- -->

bttv msp3400 2.6.15.6 - > 2.6.16 stereo stop working

On Tuesday 28 March 2006 22:54, Roland Scheidegger wrote:
> Hans Verkuil wrote:
> > I'm sorry, I'm getting confused. Now there suddenly are three
> > problems with 2.6.16:
> >
> > 1) xawtv thinks channels are mono even though they are stereo.
> > 2) after a reboot the msp3400c fails to work (is this interpreted
> > correctly? I'm not sure that I completely understood the problem.)
> > 3) the msp3400c doesn't mute.
> >
> > 1) is caused by waiting not long enough in xawtv to get a reliable
> > reading from msp3400, this should be solved in the latest v4l-dvb
> > tree (please confirm this!)
> >
> > 2) does this also happen with the latest v4l-dvb? Does this also
> > happen with 2.6.15? I don't think I made any changes to the reset
> > code.
> >
> > 3) this apparently never worked. Can you test this again in the
> > latest v4l_dvb? If you go to the msp3400c_init_data table and
> > adjust the 0x00d0 value to 0x0ed0 and try it? I'm interested in
> > hearing the results. What TV-audio standard is used where you live?
>
> Sorry for the confusion. No, only problems 1 and 3 are present in
> 2.6.16. Problem 2 is only in current v4l-dvb tree, and it's a bit
> different. After loading the msp3400 module (it only seems to depend
> on this module, not the rest of the modules) from the v4l-dvb tree
> the i2c errors will appear, sound will go off and the chip will never
> work again - if you unload bttv, msp3400 and reload them it will not
> even be detected (with either driver from 2.6.16 or v4l-dvb tree),
> even if you reboot, only power off / on will help (due to the chip
> not getting resetted otherwise - I don't think there's anything you
> can do about it, except preventing sending it the control bits which
> cause it to stop working...).
> So, since problem 2) means the msp3400 doesn't work at all with
> v4l-dvb tree I don't know if problem 1) (though it probably is) or
> problem 3) (I can't see why it should be) are fixed with the v4l-dvb
> tree.

Please apply the attached patch to msp3400-driver.c from v4l-dvb and try 
again. I think this is the cause of the msp3400 crash. Logical too, 
since demodulator register 0x40 doesn't exist in the msp3400c.

Please let me know the results. This change will go into v4l-dvb anyhow 
as it's definitely wrong.

	Hans

>
> For problem 3, I've tried 0x02d0 (with 2.6.16) which did absolutely
> nothing during channel switch, but muted some channels completely
> after the switch was complete... I'll try 0x0ed0 but frankly I don't
> have any hope this will help, I think you'd really need to mute it
> while the chip is getting switched around to am for detection,
> reswitched to fm and probably somewhat longer till it has locked to
> the carriers. tv standard is pal b/g, sound standard fm stereo (the
> msp3400 datasheet calls this "b/g stereo").
>
> Roland
>
> --
> video4linux-list mailing list
> Unsubscribe
> mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list

diff -r 388da79ac33b linux/drivers/media/video/msp3400-driver.c
--- a/linux/drivers/media/video/msp3400-driver.c	Tue Mar 28 14:54:46 2006 -0300
+++ b/linux/drivers/media/video/msp3400-driver.c	Tue Mar 28 23:11:38 2006 +0200
 (at)  (at)  -298,7 +298,8  (at)  (at)  void msp_set_scart(struct i2c_client *cl
 	msp_write_dsp(client, 0x13, state->acb);
 
 	/* Sets I2S speed 0 = 1.024 Mbps, 1 = 2.048 Mbps */
-	msp_write_dem(client, 0x40, state->i2s_mode);
+	if (state->has_i2s_conf)
+		msp_write_dem(client, 0x40, state->i2s_mode);
 }
 
 void msp_set_mute(struct i2c_client *client)

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list