Any saa711x users out there?
Hello all, I am doing some quality improvements for a couple of the em28xx/saa7113 designs, and I found a pretty serious problem which appears to have been there for some time. In fact, the regression was introduced when the saa7115 support was added in 2005 (hg revision 2750). This change resulted in the anti-alias filtering being disabled by default for the saa7113 (the saa7115_init_misc block clears bit 7 of register 0x02). Without this change, vertical lines appear in the chroma on a fixed interval. The big issue is that the driver is shared with other saa7113 products, as well as products that have the saa7111, saa7114, and saa7115. So I have to figure out whether to just force on the AA filter for the saa7113, or whether it should be enabled for the others, or whether I can even turn it on for saa7113 in general or need to hack something in there to only do it for the two or three products I am testing with. So here's where I could use some help: If you have a product that uses one of the above chips, please speak up. I will be setting up a test tree where people can try out the change and see if it makes their situation better, worse, or no change. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any saa711x users out there?
Devin Heitmueller wrote: > Hello all, > > I am doing some quality improvements for a couple of the > em28xx/saa7113 designs, and I found a pretty serious problem which > appears to have been there for some time. > > In fact, the regression was introduced when the saa7115 support was > added in 2005 (hg revision 2750). This change resulted in the > anti-alias filtering being disabled by default for the saa7113 (the > saa7115_init_misc block clears bit 7 of register 0x02). Without this > change, vertical lines appear in the chroma on a fixed interval. > > The big issue is that the driver is shared with other saa7113 > products, as well as products that have the saa7111, saa7114, and > saa7115. So I have to figure out whether to just force on the AA > filter for the saa7113, or whether it should be enabled for the > others, or whether I can even turn it on for saa7113 in general or > need to hack something in there to only do it for the two or three > products I am testing with. > > So here's where I could use some help: If you have a product that > uses one of the above chips, please speak up. I will be setting up a > test tree where people can try out the change and see if it makes > their situation better, worse, or no change. The better is to allow enabling/disabling the anti-alias via ctrl. Whatever default is chosen, the driver may adjust the control default at the board initialization, or even blocking the control when the other mode of operation is broken. I have here a few devices with saa7113 and saa7114. I think I have also one device with saa7111, but I need to check. If I'm right, it will take some time for me to prepare the saa7111 environment. The saa7113/7114 devices are easier to setup, as they are usb. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any saa711x users out there?
On Tue, Feb 2, 2010 at 7:29 PM, Mauro Carvalho Chehab wrote: > The better is to allow enabling/disabling the anti-alias via ctrl. > Whatever default is chosen, the driver may adjust the control default > at the board initialization, or even blocking the control when the > other mode of operation is broken. > > I have here a few devices with saa7113 and saa7114. I think I have > also one device with saa7111, but I need to check. If I'm right, it will > take some time for me to prepare the saa7111 environment. The saa7113/7114 > devices are easier to setup, as they are usb. I actually am not very familiar with how custom controls work for v4l devices in terms of board specific configuration, as I'm more familiar with the way that you can provide a config struct during dvb_attach() for DVB devices. I've obviously seen how they can be set from userland, but have never dug into the specific as to how a bridge would set the parameters. I actually have a test tree here which includes the change (as well as a couple of unrelated em28xx fixes I'm working on). http://www.kernellabs.com/hg/~dheitmueller/em28xx-test The change in that tree just flips on the Anti-alias filter bit in the saa7115_misc_init struct, so it ends up being applied for 7113/7114/7115. However, I'm wondering if it makes sense to just have it on by default for all three boards (which is a *much* simpler change than adding a custom control and making sure it gets set properly by the bridge in all the various cases such as surviving a powerdown/powerup of the chip). BTW, the tree above just forces the bit on for all three boards - I'm not proposing that should be the final fix, but it is enough to allow people to evaluate the effects of the change. I've got a PVR-350 board with a saa7115 which I will do some testing on. If I see the artifacts on that board without the change, that bolsters the argument that the current default may just be wrong in general. Mauro, the hg logs suggest that you added the saa7115 support (and in fact appear to have introduced the issue in question). Do you remember what board you were using when you added the support? Also, how did you arrive at the defaults that you used? Were they based on some sort of i2c bus trace, or did you just set them by reading the datasheet? 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any saa711x users out there?
Devin Heitmueller wrote: > On Tue, Feb 2, 2010 at 7:29 PM, Mauro Carvalho Chehab > wrote: >> The better is to allow enabling/disabling the anti-alias via ctrl. >> Whatever default is chosen, the driver may adjust the control default >> at the board initialization, or even blocking the control when the >> other mode of operation is broken. >> >> I have here a few devices with saa7113 and saa7114. I think I have >> also one device with saa7111, but I need to check. If I'm right, it will >> take some time for me to prepare the saa7111 environment. The saa7113/7114 >> devices are easier to setup, as they are usb. > > I actually am not very familiar with how custom controls work for v4l > devices in terms of board specific configuration, as I'm more familiar > with the way that you can provide a config struct during dvb_attach() > for DVB devices. I've obviously seen how they can be set from > userland, but have never dug into the specific as to how a bridge > would set the parameters. Just call: v4l2_device_call_all(&dev->v4l2_dev, 0, core, g_ctrl, ctrl); For get a control, and: v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_ctrl, ctrl); to set a control. > I actually have a test tree here which includes the change (as well as > a couple of unrelated em28xx fixes I'm working on). > > http://www.kernellabs.com/hg/~dheitmueller/em28xx-test > > The change in that tree just flips on the Anti-alias filter bit in the > saa7115_misc_init struct, so it ends up being applied for > 7113/7114/7115. However, I'm wondering if it makes sense to just have > it on by default for all three boards (which is a *much* simpler > change than adding a custom control and making sure it gets set > properly by the bridge in all the various cases such as surviving a > powerdown/powerup of the chip). The chip powerup/powerdown should preserve all controls, anyway. I think we need a general logic here to save/restore those values on those cases, including hibernation/suspend. In the past, several of those drivers like saa711x used to store the register values into a shadow array (although the old code were ugly and haven't any suspend/resume logic). Maybe we can resurrect this idea, in order to quickly recover from a powerdown/powerup situation. In general, the shadow array will have only 256 bytes on those chips. > BTW, the tree above just forces the bit on for all three boards - I'm > not proposing that should be the final fix, but it is enough to allow > people to evaluate the effects of the change. I'll test it later. > I've got a PVR-350 board with a saa7115 which I will do some testing > on. If I see the artifacts on that board without the change, that > bolsters the argument that the current default may just be wrong in > general. > > Mauro, the hg logs suggest that you added the saa7115 support (and in > fact appear to have introduced the issue in question). Do you > remember what board you were using when you added the support? Also, > how did you arrive at the defaults that you used? Were they based on > some sort of i2c bus trace, or did you just set them by reading the > datasheet? Well, we used to have different drivers on that time. Basically, the code from all saa711x drivers got merged and the init arrays were added as seen at the original driver. Then, fix patches were applied in order to make everybody happy. A large number of tests were done on that time, as we've got contributions from several developers. For sure we used some PVR boards, pvrusb2, WinTV USB2 and some bttv based boards with saa711x chips. Later, we've got feedback also from NT100x boards (usbvision driver) and I suspect we had tests with other drivers as well. Some Zoran boards also use saa711x chips, and, after the port to V4L2, they're now using the same driver. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any saa711x users out there?
On Tue, 2010-02-02 at 17:51 -0500, Devin Heitmueller wrote: > Hello all, > > I am doing some quality improvements for a couple of the > em28xx/saa7113 designs, and I found a pretty serious problem which > appears to have been there for some time. > > In fact, the regression was introduced when the saa7115 support was > added in 2005 (hg revision 2750). This change resulted in the > anti-alias filtering being disabled by default for the saa7113 (the > saa7115_init_misc block clears bit 7 of register 0x02). Without this > change, vertical lines appear in the chroma on a fixed interval. > > The big issue is that the driver is shared with other saa7113 > products, as well as products that have the saa7111, saa7114, and > saa7115. So I have to figure out whether to just force on the AA > filter for the saa7113, or whether it should be enabled for the > others, or whether I can even turn it on for saa7113 in general or > need to hack something in there to only do it for the two or three > products I am testing with. > > So here's where I could use some help: If you have a product that > uses one of the above chips, please speak up. I will be setting up a > test tree where people can try out the change and see if it makes > their situation better, worse, or no change. I have a PVR-350 with an SAA7115 IIRC. Other ivtv boards have SAA7114 chips. I don't see any in ivtv-cards.c that have an SAA7113 explcitily listed. Whether or not an anti-alias filter is needed is a completely knowable answer given: 1. The TV norm and hence the Luma and Chroma signal characteristics 2. The A/D sample rate 3. The parameters of any decimations or non-integer resampling being performed If you don't undersample, i.e. Fs/2 > single-sided BW of the signal being sampled, then you don't need an anti alias filter before you sample, otherwise you do. The same sort of thing goes for decimation of digital samples. If the decimation is going to cause aliases to fold down into the spectrum, you need a digital LPF before the decimation to band limit the digital signal. This should not be a "user control", this should be a configuration setting that is knowable by the bridge driver and/or the module driving the SAA7113. 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 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. Regards, Andy > Devin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any saa711x users out there?
On Wed, Feb 3, 2010 at 8:51 PM, Andy Walls 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any saa711x users out there?
On Thu, 2010-02-04 at 10:24 -0500, Devin Heitmueller wrote: > On Wed, Feb 3, 2010 at 8:51 PM, Andy Walls 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). Hmmm. The AGC (or static gain level?) of the amplifier in the SAA7113 before the anti-alias filter may be set too high causing the clipping (intermods) there. It may be worth looking at the gain setting for that amp. > > 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. Probably. The visible effects of the anti-alais filter could possibly be: 1. Less range of color, if high freqs of the color get attenuated. (Most people likely will not perceive this as most people are not that sensitive to small color variations.) 2. Loss of rapid variations in Luma - softer edges between light and dark areas on a scan line - if higher freqs of the Luma get attenuated. but given that the anti-alais filter is essentially flat out to about 5.6 MHz and has a slow rolloff (only 3 dB down at about 6.9 MHz), I doubt anyone would ever notice it is on with NTSC. Since you have a signal generator, you should run experiments with PAL-D and SECAM-D with a grid containing vertical lines since those both have a 6.0 MHz video bandwidth. SECAM also has FM color, so you might see the greatest affect of an antialias filter on color on the Cyan color bar in SECAM-D. Regards, Andy > Devin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any saa711x users out there?
Hey Andy, On Thu, Feb 4, 2010 at 11:15 PM, Andy Walls wrote: > Hmmm. The AGC (or static gain level?) of the amplifier in the SAA7113 > before the anti-alias filter may be set too high causing the clipping > (intermods) there. It may be worth looking at the gain setting for that > amp. It's possible. One thing I did as a test though was I did a capture of the i2c traffic under Windows (using the same reference video source), and then compared the register programming (via some scripts I whipped up). There were some other registers that were different, but the only one that made *any* visible difference in the output was the AA flag. > The visible effects of the anti-alais filter could possibly be: > > 1. Less range of color, if high freqs of the color get attenuated. > (Most people likely will not perceive this as most people are not that > sensitive to small color variations.) > > 2. Loss of rapid variations in Luma - softer edges between light and > dark areas on a scan line - if higher freqs of the Luma get attenuated. > > but given that the anti-alais filter is essentially flat out to about > 5.6 MHz and has a slow rolloff (only 3 dB down at about 6.9 MHz), I > doubt anyone would ever notice it is on with NTSC. To give you a better idea of what I'm talking about, look at this image: http://imagebin.org/83458 The above image was taken with the generator via the s-video input (ruling out the possibility that it's any sort of product of intermodulation). For the sake of comparison, here's the exact same signal source against an a similar em28xx design but with the tvp5150. http://imagebin.org/83459 > Since you have a signal generator, you should run experiments with PAL-D > and SECAM-D with a grid containing vertical lines since those both have > a 6.0 MHz video bandwidth. SECAM also has FM color, so you might see > the greatest affect of an antialias filter on color on the Cyan color > bar in SECAM-D. Believe it or not, I'm actually having trouble with the generator right now with anything but NTSC. I'm going back and forth with Promax on repair options. So I cannot do any PAL or SECAM testing right now. On a separate note, I really should look at extending the v4l2 capture-example to a version that let's me do a direct capture of the YUYV frame and convert the output into a zero-loss RGB format. It's too easy to be mislead by things the applications are doing like deinterlacing, rescaling, blending, and compression of the screenshot when saving to a file. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any saa711x users out there?
I also have a device that has the SAA7113 chip in it. Kworld 315U. I suggested a patch to add a an s_power function to the code but it looks like the patch didn't work. I have to do some cleanup to it and resubmit it. Franklin Meng --- On Thu, 2/4/10, Devin Heitmueller wrote: > From: Devin Heitmueller > Subject: Re: Any saa711x users out there? > To: "Andy Walls" > Cc: "Linux Media Mailing List" > Date: Thursday, February 4, 2010, 8:34 PM > Hey Andy, > > On Thu, Feb 4, 2010 at 11:15 PM, Andy Walls > wrote: > > Hmmm. The AGC (or static gain level?) of the > amplifier in the SAA7113 > > before the anti-alias filter may be set too high > causing the clipping > > (intermods) there. It may be worth looking at the > gain setting for that > > amp. > > It's possible. One thing I did as a test though was I > did a capture > of the i2c traffic under Windows (using the same reference > video > source), and then compared the register programming (via > some scripts > I whipped up). There were some other registers that > were different, > but the only one that made *any* visible difference in the > output was > the AA flag. > > > The visible effects of the anti-alais filter could > possibly be: > > > > 1. Less range of color, if high freqs of the color get > attenuated. > > (Most people likely will not perceive this as most > people are not that > > sensitive to small color variations.) > > > > 2. Loss of rapid variations in Luma - softer edges > between light and > > dark areas on a scan line - if higher freqs of the > Luma get attenuated. > > > > but given that the anti-alais filter is essentially > flat out to about > > 5.6 MHz and has a slow rolloff (only 3 dB down at > about 6.9 MHz), I > > doubt anyone would ever notice it is on with NTSC. > > To give you a better idea of what I'm talking about, look > at this image: > > http://imagebin.org/83458 > > The above image was taken with the generator via the > s-video input > (ruling out the possibility that it's any sort of product > of > intermodulation). > > For the sake of comparison, here's the exact same signal > source > against an a similar em28xx design but with the tvp5150. > > http://imagebin.org/83459 > > > Since you have a signal generator, you should run > experiments with PAL-D > > and SECAM-D with a grid containing vertical lines > since those both have > > a 6.0 MHz video bandwidth. SECAM also has FM color, > so you might see > > the greatest affect of an antialias filter on color on > the Cyan color > > bar in SECAM-D. > > Believe it or not, I'm actually having trouble with the > generator > right now with anything but NTSC. I'm going back and > forth with > Promax on repair options. So I cannot do any PAL or > SECAM testing > right now. > > On a separate note, I really should look at extending the > v4l2 > capture-example to a version that let's me do a direct > capture of the > YUYV frame and convert the output into a zero-loss RGB > format. It's > too easy to be mislead by things the applications are doing > like > deinterlacing, rescaling, blending, and compression of the > screenshot > when saving to a file. > > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any saa711x users out there?
On Thu, 2010-02-04 at 23:34 -0500, Devin Heitmueller wrote: > Hey Andy, > > The visible effects of the anti-alais filter could possibly be: > > > > 1. Less range of color, if high freqs of the color get attenuated. > > (Most people likely will not perceive this as most people are not that > > sensitive to small color variations.) > > > > 2. Loss of rapid variations in Luma - softer edges between light and > > dark areas on a scan line - if higher freqs of the Luma get attenuated. > > > > but given that the anti-alais filter is essentially flat out to about > > 5.6 MHz and has a slow rolloff (only 3 dB down at about 6.9 MHz), I > > doubt anyone would ever notice it is on with NTSC. Hi Devin, I think I miscommunicated in the above. To be more precise, I should have said: "The visible effects of the anti-alias filter, on a signal that does not have unexpected high frequency components out of the normal channel bandwidth, could possibly be:" In other words "here's what someone might notice as degredation due to an AA filter, if they had a proper signal throughout the entire amplifier chain." > To give you a better idea of what I'm talking about, look at this image: > > http://imagebin.org/83458 OK. It look pretty regular which is surprising, but nice for analysis. It's approximate frequency after having been being folded down is about: 42 cycles/line / 704 pixels/line * 13.5 Mpixels/sec ~= 805.4 kHz ~= 1 MHz which means it's likely a pretty high frequency, several MHz above the Nyquist rate, before being folded down by the sampling. > The above image was taken with the generator via the s-video input > (ruling out the possibility that it's any sort of product of > intermodulation). You are correct that intermodulation product is the wrong term in the case of basedband S-Video. However, clipping caused by an overdriven amplifier will introduce high frequency components - be the peak of the time domain signal caused by mixing of unwanted TV stations or just a very strong or overamplified basedband signal. > For the sake of comparison, here's the exact same signal source > against an a similar em28xx design but with the tvp5150. > > http://imagebin.org/83459 Much nicer. > > Since you have a signal generator, you should run experiments with PAL-D > > and SECAM-D with a grid containing vertical lines since those both have > > a 6.0 MHz video bandwidth. SECAM also has FM color, so you might see > > the greatest affect of an antialias filter on color on the Cyan color > > bar in SECAM-D. > > Believe it or not, I'm actually having trouble with the generator > right now with anything but NTSC. I'm going back and forth with > Promax on repair options. So I cannot do any PAL or SECAM testing > right now. :( I'll try to perform a quick test with my PVR-350 with NTSC and the YUV capture device BTW. Then I'll go outside and shovel more snow. :P Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any saa711x users out there?
> I'll try to perform a quick test with my PVR-350 with NTSC and the YUV > capture device BTW. OK. So my test setup: a. DTV STB tuned to the SuperBowl :) b. Composite out from the STB feeding my PVR-350/SAA7115 with an NTSC CVBS input. c. mplayer capturing raw YUV video from the PVR-350's composite input: $ mplayer /dev/video32 -demuxer rawvideo -rawvideo w=720:h=480:format=hm12:ntsc I did this: # v4l2-dbg -d /dev/video32 -S host0: cx23415revision 0x i2c 0x21: saa7115revision 0x i2c 0x40: msp4448g revision 0x02173043 i2c 0x44: saa7129revision 0x # v4l2-dbg -d /dev/video32 -c 0x21 --list-registers=min=0x00,max=0xff ioctl: VIDIOC_DBG_G_REGISTER 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F : 10 48 80 20 90 90 eb e0 68 53 80 44 40 00 07 2e 0010: 06 00 9d 80 00 03 11 9c 40 80 77 42 a9 01 81 b1 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030: cd 20 03 00 ce fb 30 00 03 10 00 00 00 00 00 00 0040: 20 ff ff ff ff ff ff ff ff dd dd dd dd dd dd dd 0050: dd dd dd dd dd ff ff ff 40 47 06 83 00 bd 35 00 0060: 00 00 00 00 00 00 a9 00 00 00 00 aa 00 00 00 00 0070: 00 00 aa 00 00 00 00 aa 00 00 00 00 00 00 00 00 0080: 30 01 00 00 20 21 c5 01 f0 00 00 00 00 00 00 3b 0090: 80 48 40 84 01 00 d0 02 05 00 0c 00 a0 05 0c 00 00a0: 01 00 00 00 80 40 40 00 00 02 00 00 00 01 00 00 00b0: 00 04 00 04 01 00 00 00 00 00 00 00 00 00 00 00 00c0: 00 08 00 80 02 00 d0 02 12 00 f8 00 d0 02 f8 00 00d0: 01 00 00 00 80 40 40 00 00 04 00 00 00 02 00 00 00e0: 00 04 00 04 01 00 00 00 00 00 00 00 00 00 00 00 00f0: ad 05 50 46 00 ad 01 4b 00 4b 00 4b 00 00 00 88 # v4l2-dbg -d /dev/video32 -c 0x21 -g 2 ioctl: VIDIOC_DBG_G_REGISTER Register 0x0002 = 80h (128d 1000b) # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0xc0 Register 0x0002 set to 0xc0 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x80 Register 0x0002 set to 0x80 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0xc0 Register 0x0002 set to 0xc0 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x0 Register 0x0002 set to 0x0 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x40 Register 0x0002 set to 0x40 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x00 Register 0x0002 set to 0x0 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x40 Register 0x0002 set to 0x40 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x00 Register 0x0002 set to 0x0 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x40 Register 0x0002 set to 0x40 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x0 Register 0x0002 set to 0x0 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x80 Register 0x0002 set to 0x80 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x40 Register 0x0002 set to 0x40 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x80 Register 0x0002 set to 0x80 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0xc0 Register 0x0002 set to 0xc0 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x40 Register 0x0002 set to 0x40 # v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x80 Register 0x0002 set to 0x80 My observations: 1. With the amplifier on and anti-alias filter off things looked fine. 2. With the amplifier on and anti-alias filter on things looked fine. 3. With the amplifier off and anti-alias filter off things looked fine. 4. With the amplifier off and anti-alias filter on the screen washed brighter/whiter. I guess the anti-alias filter peaks the luma a little or attenuates the color a little. The amplifier and AGC is probably essential when using the anti-alias filter. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any saa711x users out there?
Hi Andy, Thanks for taking the time to do some testing in your environment. On Sun, Feb 7, 2010 at 7:10 PM, Andy Walls wrote: > My observations: > > 1. With the amplifier on and anti-alias filter off things looked fine. > 2. With the amplifier on and anti-alias filter on things looked fine. > 3. With the amplifier off and anti-alias filter off things looked fine. > 4. With the amplifier off and anti-alias filter on the screen washed > brighter/whiter. > > I guess the anti-alias filter peaks the luma a little or attenuates the color > a little. > The amplifier and AGC is probably essential when using the anti-alias filter. This all looks like good news, suggesting that under most conditions people won't notice the difference (except in the signal conditions I saw, in which case they will see a rather significant positive improvement). And since we don't let users independently control the AA filter nor the amplifier, we can be confident that there won't be a case when the amplifier is on but the AA filter is off. My vote is to just push the one line change then flipping on the AA filter in the saa7115_init_misc array of registers (essentially the patch below): http://kernellabs.com/hg/~dheitmueller/em28xx-test/rev/42272c1dd883 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
