From 6fe7d2c4660174110c6872cacc4fc2acb6e00acf Mon Sep 17 00:00:00 2001 From: Mike Isely Date: Sun, 28 Jan 2007 15:42:56 -0300 Subject: [PATCH] V4L/DVB (5174): Pvrusb2: video corruption fixes Tweak the encoder setup in order to stop it from corrupting the video data when there is a disruption in the data flow (e.g. a channel change). Signed-off-by: Mike Isely Signed-off-by: Mauro Carvalho Chehab --- drivers/media/video/pvrusb2/pvrusb2-encoder.c | 69 +++++++++++++++++++ 1 file changed, 69 insertions(+) diff --git a/drivers/media/video/pvrusb2/pvrusb2-encoder.c b/drivers/media/video/pvrusb2/pvrusb2-encoder.c index 7cd95e9f914..5fe17c0344b 100644 --- a/drivers/media/video/pvrusb2/pvrusb2-encoder.c +++ b/drivers/media/video/pvrusb2/pvrusb2-encoder.c @@ -321,6 +321,73 @@ static int pvr2_encoder_vcmd(struct pvr2_hdw *hdw, int cmd, return pvr2_encoder_cmd(hdw,cmd,args,0,data); } + +/* This implements some extra setup for the encoder that seems to be + specific to the PVR USB2 hardware. */ +int pvr2_encoder_prep_config(struct pvr2_hdw *hdw) +{ + int ret = 0; + int encMisc3Arg = 0; + +#if 0 + /* This inexplicable bit happens in the Hauppage windows + driver (for both 24xxx and 29xxx devices). However I + currently see no difference in behavior with or without + this stuff. Leave this here as a note of its existence, + but don't use it. */ + LOCK_TAKE(hdw->ctl_lock); do { + u32 dat[1]; + dat[0] = 0x80000640; + pvr2_encoder_write_words(hdw,0x01fe,dat,1); + pvr2_encoder_write_words(hdw,0x023e,dat,1); + } while(0); LOCK_GIVE(hdw->ctl_lock); +#endif + + /* Mike Isely 26-Jan-2006 The windows driver + sends the following list of ENC_MISC commands (for both + 24xxx and 29xxx devices). Meanings are not entirely clear, + however without the ENC_MISC(3,1) command then we risk + random perpetual video corruption whenever the video input + breaks up for a moment (like when switching channels). */ + + +#if 0 + /* This ENC_MISC(5,0) command seems to hurt 29xxx sync + performance on channel changes, but is not a problem on + 24xxx devices. */ + ret |= pvr2_encoder_vcmd(hdw, CX2341X_ENC_MISC,4, 5,0,0,0); +#endif + + /* This ENC_MISC(3,encMisc3Arg) command is critical - without + it there will eventually be video corruption. Also, the + 29xxx case is strange - the Windows driver is passing 1 + regardless of device type but if we have 1 for 29xxx device + the video turns sluggish. */ + switch (hdw->hdw_type) { + case PVR2_HDW_TYPE_24XXX: encMisc3Arg = 1; break; + case PVR2_HDW_TYPE_29XXX: encMisc3Arg = 0; break; + default: break; + } + ret |= pvr2_encoder_vcmd(hdw, CX2341X_ENC_MISC,4, 3, + encMisc3Arg,0,0); + + ret |= pvr2_encoder_vcmd(hdw, CX2341X_ENC_MISC,4, 8,0,0,0); + +#if 0 + /* This ENC_MISC(4,1) command is poisonous, so it is commented + out. But I'm leaving it here anyway to document its + existence in the Windows driver. The effect of this + command is that apps displaying the stream become sluggish + with stuttering video. */ + ret |= pvr2_encoder_vcmd(hdw, CX2341X_ENC_MISC,4, 4,1,0,0); +#endif + + ret |= pvr2_encoder_vcmd(hdw, CX2341X_ENC_MISC,4, 0,3,0,0); + ret |= pvr2_encoder_vcmd(hdw, CX2341X_ENC_MISC,4,15,0,0,0); + + return ret; +} + int pvr2_encoder_configure(struct pvr2_hdw *hdw) { int ret; @@ -335,6 +402,8 @@ int pvr2_encoder_configure(struct pvr2_hdw *hdw) ret = 0; + ret |= pvr2_encoder_prep_config(hdw); + if (!ret) ret = pvr2_encoder_vcmd( hdw,CX2341X_ENC_SET_NUM_VSYNC_LINES, 2, 0xf0, 0xf0); -- 2.41.0