Re: Terratec Grabby hwrev 2

[Timo Teras <timo.teras@iki.fi>]

On Wed, 1 May 2013 19:11:53 +0200
Jon Arne Jørgensen <jonarne@jonarne.no> wrote:

> On Thu, Mar 28, 2013 at 04:54:59PM +0200, Timo Teras wrote:
> > On Thu, 28 Mar 2013 15:35:56 +0200
> > Timo Teras <timo.teras@iki.fi> wrote:
> > 
> > > On Thu, 28 Mar 2013 09:40:52 -0300
> > > Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> > > 
> > > > Em Thu, 28 Mar 2013 10:52:01 +0200
> > > > Timo Teras <timo.teras@iki.fi> escreveu:
> > > > 
> > > > > On Wed, 27 Mar 2013 16:10:49 +0200
> > > > > Timo Teras <timo.teras@iki.fi> wrote:
> > > > > 
> > > > > > On Tue, 26 Mar 2013 10:20:56 +0200
> > > > > > Timo Teras <timo.teras@iki.fi> wrote:
> > > > > > 
> > > > > > > I did manage to get decent traces with USBlyzer evaluation
> > > > > > > version.
> > > > > > 
> > > > > > Nothing _that_ exciting there. Though, there's quite a bit
> > > > > > of differences on certain register writes. I tried copying
> > > > > > the changed parts, but did not really help.
> > > > > > 
> > > > > > Turning on saa7115 debug gave:
> > > > > > 
> > > > > > saa7115 1-0025: chip found @ 0x4a (ID 000000000000000) does
> > > > > > not match a known saa711x chip.
> > > > > 
> > > > > Well, I just made saa7115.c ignore this ID check, and
> > > > > defeault to saa7113 which is apparently the chip used.
> > > > > 
> > > > > And now it looks like things start to work a lot better.
> > > > > 
> > > > > Weird that the saa7113 chip is missing the ID string. Will
> > > > > continue testing.
> > > > 
> > > > That could happen if saa7113 is behind some I2C bridge and when
> > > > saa7113 is not found when the detection code is called.
> > > 
> > > Smells to me that they replaced the saa7113 with cheaper clone
> > > that does not support the ID string.
> > > 
> > > Sounds like the same issue as:
> > > http://www.spinics.net/lists/linux-media/msg57926.html
> > > 
> > > Additionally noted that something is not initialized right:
> > > 
> > > With PAL signal:
> > > - there's some junk pixel in beginning of each line (looks like
> > > pixes from previous lines end), sync issue?
> > > - some junk lines at the end
> > > - distorted colors when white and black change between pixels
> > 
> > Still have not figured out this one. Could be probably related to
> > the saa7113 differences.
> > 
> > > With NTSC signal:
> > > - unable to get a lock, and the whole picture looks garbled
> > 
> > NTSC started working after I removed all the saa711x writes to
> > following registers:
> >  R_14_ANAL_ADC_COMPAT_CNTL
> >  R_15_VGATE_START_FID_CHG
> >  R_16_VGATE_STOP
> >  R_17_MISC_VGATE_CONF_AND_MSB
> > 
> 
> This is the exact same behavior as i see on the gm7113c chip
> in the stk1160, and the smi2021 devices.
> 
> See here:
> http://www.spinics.net/lists/linux-media/msg63163.html

Thanks. I tested the patch and it detects it properly, and I get
picture. However, there's problems synchronizing to my PAL signal. The
picture "jumps" once in a while.

I guess the problem is in the init sequence. The W7 driver had
following differences sequence changes compared to saa7113_init:
-	R_02_INPUT_CNTL_1, 0xc2,
+	R_02_INPUT_CNTL_1, 0xc0,
-	R_04_INPUT_CNTL_3, 0x00,
-	R_05_INPUT_CNTL_4, 0x00,
-	R_06_H_SYNC_START, 0x89,
+	R_06_H_SYNC_START, 0xeb,
-	R_12_RT_SIGNAL_CNTL, 0x07,
+	R_12_RT_SIGNAL_CNTL, 0xe7,
-	R_14_ANAL_ADC_COMPAT_CNTL, 0x00,
-	R_15_VGATE_START_FID_CHG, 0x00,
-	R_16_VGATE_STOP, 0x00,
-	R_17_MISC_VGATE_CONF_AND_MSB, 0x00,

Seems that R_14 is filtered in your patch, but other changes are not
taken into account.

Otherwise, the patchset looks good.

- Timo