On Wed, 1 May 2013 19:11:53 +0200 Jon Arne Jørgensen <jonarne@xxxxxxxxxx> 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@xxxxxx> wrote: > > > > > On Thu, 28 Mar 2013 09:40:52 -0300 > > > Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > > > > > > > Em Thu, 28 Mar 2013 10:52:01 +0200 > > > > Timo Teras <timo.teras@xxxxxx> escreveu: > > > > > > > > > On Wed, 27 Mar 2013 16:10:49 +0200 > > > > > Timo Teras <timo.teras@xxxxxx> wrote: > > > > > > > > > > > On Tue, 26 Mar 2013 10:20:56 +0200 > > > > > > Timo Teras <timo.teras@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
