On Wed, Feb 3, 2010 at 8:51 PM, Andy Walls <awalls@xxxxxxxxx> wrote: > With all that said, if you have a baseband Luma or Chroma signal with > strong spurious high frequency components (crappy source, or you're > overdriving the front end and getting intermods), then keep the > anti-alias filter turned on as the assumption of a bandlimited input > signal is violated in this case. In this case, I'm seeing it with both the analog signal generator (which one might consider a fairly pristine source), as well coming off the s-video output of a DirectTV box (in which case the signal is being generated only a few feet away from the saa7113). > In the SAA7113 the anti-alias filter introduces a delay of 50 ns. At > 13.5 Mpixels/sec, or 74.1 ns/pixel, that's less than 1 pixel time of > delay. > > Just turn it on in and leave it on in the SAA7113 to handle the > unexpected input signal case. This would be my vote (assuming we try it with the other parts and confirm no regressions are introduced). My only concern is the way the code is currently written, the saa7113 initialization block actually does enable it by default, and then some code for the saa7115 tramples the register, turning it off (see saa7115_init_misc at saa7115.c:600). I think the decision we have to make is which of the following paths to take: 1. Enable it in the saa7115_init_misc, thereby enabling it for the 7113, 7114, and 7115. 2. Exclude the saa7115_init_misc block from being run at all against the 7113 3. Let the saa7115_init_misc block get run, and then flip the bit back for the 7113. My thinking at this point is that the AA filter should probably be on by default regardless of the chip, in which case we would just need to make the one line change to enable it in the saa7115_init_misc block. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
