DaVinci DM6446 to THS8200

try swaping Cb and Cr components on bus; you can do this by programming a DM6446 register (see VPBE UG and let me know if you cannot find it); this should take care of the color issue.

Also, what exactly do you see when you use vid0?  It is entirely possible that there is data placed there during driver initialization.

Swapping the Cb and Cr components seemed to fix the problem when the vid0 buffer is turned off, but the color still seems to be off when the vid0 buffer is on for some reason.  Not sure why.  It seems to be something with the shading (the attribute plane).  Instead of shades of grey, I'm getting white to black and shades of pink.

well, if you have both vid0 and vid1 enabled (vid1 should be < or equal in size according to specs), vid0 should be in the back, partly or completely covered by vid1 and any OSD data will be placed on top of these to video windos blended per attribute window.  That said, if you writte all zeros to attribute window (e.g. > cat /dev/zero > /dev/fb/2 ), you will essentially make any OSD data invisible and only see what is truly there in vid0 and vid1.  Can you try this exercise to see what portions of what you are seeing is contributed by video window(s) and by OSD window?  Also, a screen-shot of what you are seeing may help...

Does the RGB conversion matrix do anything by default when using the DaVinci digital output?  What does it default to?

if your specified output pixel format is YCbCr, as it appears to be in your case (since we just discussed Cb and Cr swapping prior to THS), then the RGB conversion matrix in the VENC does not come into play.   The data provided from the OSD to the VENC is already in YCbCr pixel format, so no need to do any conversion.  If however, the hardware was configured to output RGB pixel format, the the RGB conversion matrix would be used to achieve the conversion and RGB data will be output from digital video output interface pins.

I think my conversion matrix is incorrect in the THS8200 for the colors.  Do you know what the conversion matrix in the THS8200 when using the DaVinci DM6446 as input?

ahhh, so it appears you are taking YCbCr input into the THS8200 and converting to RGB ih the THS8200; is this correct? 

To be honest, I am not too familiar with THS parts; a better place on the forums to get support for this family of parts is http://e2e.ti.com/forums/186.aspx

I am curious though, what are you interfacing to; since you are using the THS part, I assume it is an analog display.. are you using high resolution (more than what DM6446 can handle with its internal analog DACS) RGB analog displays?

BMillikan said:

Do you know what the conversion matrix in the THS8200 when using the DaVinci DM6446 as input?

The color space conversion functionality for the THS8200 is described in section 4.4 of the THS8200 datasheet. The example settings provided for HDTV YCbCr to HDTV RGB conversion worked for a customer who asked about this functionality in the past where they wanted to output a 720p signal on a VGA cable in analog RGB, this was from a DM355 however it will apply the same to the DM6446 as they share a similar VPBE and use the same color format output. I have a set of example settings for a 16 bit YCbCr 4:2:2 720p digital input with external syncs converting to RGB output for display over a VGA cable to a PC monitor that accepts HDTV 720p timings over VGA if you want it, though it uses the same color space conversion coefficients as outlined in the datasheet.

BMillikan said:

but the color still seems to be off when the vid0 buffer is on for some reason.

Thinking about this statement, it would seem to me that this would indicate that the problem could not be in the THS8200 conversion settings, since that is well beyond the mixing aspect of the OSD in the VPBE, if the problem was in the THS8200 conversion than that would mean that the image should be bad all the time, not just when the vid0 window is enabled.

This makes me wonder if your attribute window is really set to have the OSD only showing, and if your attribute window is really covering the whole screen, if you change the values in the attribute register can you see an impact on the output? Note that if the video window is not being filled with valid data that you are probably seeing random data in DDR, which usually ends up looking like a pink and green mess.

If this is really messed up all the time and you cannot impact it with the OSD window you may want to check your window sizes and make sure they are within spec, primarily the constraints listed in section 4.3.1 of SPRUE37c, and that they logically make sense.

We have tried using the default conversion tables as given in the THS8200 specification, but we get a blueish or redish tinted effect around areas where we are using the attribute plane to adjust the color.  Perhaps our application is more sensitive to color that any other.  We are painting something on a black background, so colors show up really well (if they are right or wrong).  I am also discussing this issue with a representative of TI that is familiar with the THS8200, but it would not hurt to make sure my DaVinci interface is correct as well.  I think it is ok, but I can't rule anything out at this point.  I see the image, but the color is off.  Unfortunately, I don't have a way to take a screen shot.

One thing to note that might be an issue is that the default color conversion tables for the OSD are 8-bit and the conversion tables for the THS8200 from Y/C to RGB are 10-bit.  Perhaps this is an issue?  Is there a way to change there default tables for a specific mode of operation?

BMillikan said:

We have tried using the default conversion tables as given in the THS8200 specification, but we get a blueish or redish tinted effect around areas where we are using the attribute plane to adjust the color.

This would still imply that the issue is more related to the attribute plane than the color conversion later on down the line, I am assuming that you have areas of color that are correct that are not involved with the attribute plane, and if so than they should be off as well. It is strange that you describe using the attribute window to adjust the color, do you have the background window set to some constant value and you are just using the attribute window to brighten or darken or tint the front image? The attribute window is not really designed for use as a color correction device, it is really just a simple pixel by pixel weighted averaging engine, though that should do what you describe as well you may be hitting some edge condition. I would probably start by taking the attribute window out of the system to validate that you can pipe test data through the system (like color bars) to validate everything else, and than go back to looking more closely at the attribute window.

I think I may be missing the end goal here and that may be throwing me off since your description is strange of painting on a black background and using the attribute window for color adjustments, if you feel this is the case we may have to take the issue offline.

BMillikan said:

One thing to note that might be an issue is that the default color conversion tables for the OSD are 8-bit and the conversion tables for the THS8200 from Y/C to RGB are 10-bit.  Perhaps this is an issue?  Is there a way to change there default tables for a specific mode of operation?

I don't believe this would be an issue at least it should not be as long as you are ok with an 8 bit color depth conversion, as long as the forumlas are all still correct this should only impact a slight loss of color depth coming out of the OSD. You may want to ask your THS8200 contact about adjusting the THS8200 side tables further, though as suggested here, I am not sure that would impact things.

What range does the DM6446 output the YCbCr data by default (if I don't change the conversion tables)? 

There are a few places to control this in the VPBE, however by default (as in default register values) the range will be 0-255 for each YCbCr component. At the OSD level the stream can be attenuated to the REC601 levels of 16-235 for luma and 16-240 for chroma using OSDWIN0MD.ATN0E and OSDWIN1MD.ATN1E for the OSD windows, though the attenuation is automatically disabled when OSDWIN1 is being used as an attribute window. At the final display level the attenuation can be controlled with the ATRGB, ATYCC, and ATCOM fields in the VDPRO register, in your case for an RGB output you could set ATRGB so have the 0-255 ranges attenuated to the REC601 levels.

The RGB conversion is actually not done until it reaches the THS8200 chip.  I just let the DM6446 output the data in YCbCr 4:2:2 format and use the 20-bit interface to read in the data on the THS8200.  At least, that's how it works in theory.  In order to use the YCC attenuation mentioned (REC601), do I have to enable the prefilter in the VIDPRO register?  Obviously, we are using the attribute plane, so we are unable to use the ATN0E and ATN1E fields or the OSDWIN0 and OSDWIN1 registers.

BMillikan said:

The RGB conversion is actually not done until it reaches the THS8200 chip.  I just let the DM6446 output the data in YCbCr 4:2:2 format and use the 20-bit interface to read in the data on the THS8200.  At least, that's how it works in theory.

Good catch, my bad, in this case you would be setting ATYCC instead.

BMillikan said:

In order to use the YCC attenuation mentioned (REC601), do I have to enable the prefilter in the VIDPRO register?

You should not have to, the attenuation and the prefilter are independent blocks in the VPBE.

I think my timing register settings are wrong for the DM6446 and that is what is causing the color skew.  If I set the HSYNC and VSYNC delays just right on the THS8200, the color looks fine (but the picture is offset). So, I was wondering if you could help me determine the timing register settings for the DM6446 given:

horizontal:

sync pulse = 128 pixels

back porch = 88 pixels

active = 800 pixels

front porch = 40 pixels

total = 1056 pixels

vertical:

sync pulse: 4 lines

back porch: 23 lines

active: 800 lines

front porch = 1 lines

total = 628 lines

Thx,

Brian

sorry, active for vertical is 600 lines

I think my color values are off because the blanking values from the DM6446 given to the THS8200 are not converting to RGB black exactly.  Once everything lines up, my colors are off.  How do I ensure that my blanking region values are correct for my application?

BMillikan said:

I think my timing register settings are wrong for the DM6446 and that is what is causing the color skew.  If I set the HSYNC and VSYNC delays just right on the THS8200, the color looks fine (but the picture is offset). So, I was wondering if you could help me determine the timing register settings for the DM6446 given:

horizontal:

sync pulse = 128 pixels

back porch = 88 pixels

active = 800 pixels

front porch = 40 pixels

total = 1056 pixels

 

vertical:

sync pulse: 4 lines

back porch: 23 lines

active: 800 lines

front porch = 1 lines

total = 628 lines

This timing information goes into a few registers in the VENC  based on the figure below taken from the VPBE user's guide SPRUE37c.

horizontal:

sync pulse = 128 pixels -> HSPLS = 128

back porch = 88 pixels -> HSTART = HSPLS + back porch = 216

active = 800 pixels -> HVALID = 800

front porch = 40 pixels -> front porch = HINT+1 - HVALID - HSTART = 1056 - 800 - 216 = 40

total = 1056 pixels -> HINT = 1055

vertical:

sync pulse: 4 lines -> VSPLS = 4

back porch: 23 lines -> VSTART = VSPLS + back porch = 27

active: 600 lines -> VVALID = 600

front porch = 1 lines -> front porch = VINT+1 - VVALID - VSTART = 628 - 600 - 27 = 1

total = 628 lines -> VINT = 627

BMillikan said:

I think my color values are off because the blanking values from the DM6446 given to the THS8200 are not converting to RGB black exactly.  Once everything lines up, my colors are off.  How do I ensure that my blanking region values are correct for my application?

I am a bit confused by this statement, blanking values implies that the data is outside of the viewable area, so you should not be seeing it on your display unless you are transmitting blank frames, so I am not sure how the blanking should be impacting you? The DM6446 should supply a stream of 0x80108010... interleaved YCbCr during blanking, which should appear as black to a bt.601 compliant receiver which should be the case with a THS8200. Even if it was not perfectly black it would still appear to be a slightly lighter black, but would not have any color regardless of if the THS8200 is expecting attenuated values or not.

I am seeing green in the blanking area of my image.  The R & B are low, but the G has some signal in the blanking area (I'm looking at the output of the VGA connector).  The front porch and back porch area of the blanking region has green and the sync portion of the blanking region is black.  I think  this is what is causing my color problem. 

I am not sure why you would get this extra green in the blanking, and I am also not sure why that would impact your viewable image as blanking is outside of the viewable area, though it should be black by convention. Additionally front porch and back porch are supposed to be outside of the viewable area, therefore the colors there should not matter either. Perhaps you are suggesting that the green line on this board is always incorrectly being driven higher than it should be even during the viewable image?

Since the dc restore is done during the blanking period, this will affect the color in the active period.  The blanking period is outside the viewable area, but it does affect the viewable area because of the dc restore.

Good point, I tend to think in mostly digital terms so DC restore is not something I run into that much, the THS8200 actually lets you set a particular blanking value though that only applies to the standard TV modes and not to VESA, with VESA/RGB mode the DACs always output the video input bus value, though in this case it would be the color space converted value.

How far off is the green signal during blanking? I am supposing this is not something that can be corrected for on the end display?

Is there a way to explicitly set the value for the blanking region in the DM6446?  It seems to always come up green on the RGB monitor for some reason (maybe due to the conversion from YCbCr->RGB?).  Anyway, I believe this is the reason my colors are off.  If I could set this, I believe my problems would be solved.

If the video timing between your source and display match, you should not see the video blanking area.  But in the event there is a mismatch and you do see the blaking area it would be either the data stored in the source DDR2 memory buffer (if DM6446 defines valid data portion to be bigger) or the value set at the iddle pins (if THS8200 has a valid video region bigger than DM6446).  I do not believe the value set at idle pins can be changed...Of course you could always define a larger video display buffer for DM6446 than you need, fill it with whatever color pixel you wish, write valid video data to the middle of this buffer and define your DM6446 window output size to be the size of the larger buffer.  Actually, it may be trickier than this...but hopefully you get the idea...

I believe Juan's suggestion of outputting a larger image than the THS8200 is expecting is the only way to force a particular 'blanking' value, there is not a blanking value register or anything that would make this easy.

I wanted to point out that the VPBE should be outputting 0x8010 (bt.601 YCbCr 4:2:2 black) on the bus during blanking in YCbCr mode though I am not sure that applies to the 16 bit mode. You may want to verify the value you are giving the THS8200 during blanking currently before going into modifying the driver to display set blanking values outside of the viewable image area if you have reasonable access to the physical bus and a logic analyzer or oscilloscope.