Digital Output on DM355 VPBE

Where did you get LCD1 from?  I believe the this parameter should be "LCD" (reflected on our PSP documentation) but I am curious if we have misdocumented this anywhere; hence my curiosity of where you got LCD1 from.

Oops..I am sorry. It is LCD. Sorry for the typo! I am curious because, when I enable the color bar bit in the VPBE, I see some activity on some of lines. I verified the analog output on TV. It comes on perfect. But the moment I disable the color bar bit and try to cat some image onto the device, it goes all down!. I believe with a buffer outputting 0xFFFFFF data, I should be able to see all lines high. Let me know if I am wrong.

Thanx!

As Juan mentions the parameter should be LCD based on the PSP docs, so having LCD1 may be part of the problem. In either case do you get any messages during the display driver initialization when Linux boots? I have not done much work with this latest intteration of the DM355 drivers but it could be that it is checking for the LCD daughtercard to be present before activating the display, I imagine there could be messages in the boot log that provide further information on what is going wrong.

As for debugging when you say you checked signals I assume you are looking at the pixel clock and sync signals correct?

SundarIyer said:

Oops..I am sorry. It is LCD. Sorry for the typo! I am curious because, when I enable the color bar bit in the VPBE, I see some activity on some of lines. I verified the analog output on TV. It comes on perfect. But the moment I disable the color bar bit and try to cat some image onto the device, it goes all down!. I believe with a buffer outputting 0xFFFFFF data, I should be able to see all lines high. Let me know if I am wrong.

From your comments above, I gather analog color bar output works fine; have you tried digital color bar output (since LCD would imply digital).  I think we should focus on getting color bars working on digital video output first to reduce to number of variables.  If we can get this working, you will know VENC is correctly configured and we can focus on other aspects of VPBE.  Also, have you modified the source code at all (kernel drivers or applicaton)? 

Nope!. I am simply using the dm355_defconfig. 

In a nut shell,

1. I am not attaching the LCD to it. I gather from the data sheets that the DC5 connector is the LCD out connector with the RGB signals routed to this one. So i probe it using a scope. I find that the HSYNC, VSYNC, VCLOCK, LCD_OE signals are all active and as per the standards. I do get some signals on some of the data lines, but I am not happy with the rest of the data signals on the board!.

2. When I disable the color bar bit in the VPBE from the application using a simple IO-mapped driver to allow my frame bufffer data, I find that the active data lines go down and there is nothing further in those lines.

3. The VENC paramaters in the VPBE driver are perfect as I check in the register values using the data sheet. I do not doubt them. I also hardcoded the PINMUX1 register for RGB666.

4. I believed this should be as simple as it was for DM6446. I understand that there should not be any dependency of the LCD to output data on the VPBE. Atleast I do not find it anywhere. But i find that this DM355 is more multiplxed than the DM6446. Can you let me know if theTHS2800 interface has to do something with enabling the VPBE digitally??

Thanx!

Sundar

We can support both LCD output (tested with LogicPD LCD card) and COMPONENT1 output (tested with THS8200 duaghter card); the main difference is the pixel format (RGB for LCD, YCbCr for COMPONENT1).

Try using the following in your bootargs

davinci_enc_mngr.ch0_output=LCD
davinci_enc_mngr.ch0_mode=640x480

Also, I would try placing something other than 0xFF for data buffer to see if this makes a difference as well.

Hmm,..OK. I will try to use these bootargs for the while and will get back to you once I have the results. But still, for curiosity sake, is there any special initialization for the digital output with respect to the THS8200 and LogicPD. Because I believe the driver code has the function itsels as 640x480 and component outputs, which I see are generic enough!

With regard to the other point, I also try to cat a bmp image onto the fb device. But once the coloe bar bit is disabled, I find that there is no signal on the lines. But this works perfectly on the analog side. My experience with the VPBE tells me that no matter what the interface is, the data is always same from the VPBE. This is what is new and confusing!!

-Sundar

If you have not changed any source code, things whould work as long as we have the correct configuration settings; are you running any of the demos included in DVSDK after bootup (this may be overwritting settings)

I want to ask for a register dump of VPBE registers, but if you have not changed the kernel drivers, this should hopefully not be needed.  However, if we can not figure the correct settings, we may have to resort to the register dump approach and work backwards.

Hi Juan, I tried with those boot args; but am not still able to get some activity on the lines :(. In fact, with th 640x480 bootargs, I also have lost the sync signals.

I simply take the latest kernel 2.0 LSP and make DM355 config; and probe the DC5 connector. Is there anything I am doing wrong here??

Thanx!

Sundar

I don't think this applies to the more current software versions, but I was able to get digital output from the DM355 EVM by using video=dm355fb:output=ntsc:format=ycc8 when using an older 1.30 DVSDK kernel. I imagine the ability to output digitally was not lost with the newer LSP, I would have guessed that the LCD setup would start outputting syncs and clock easily, my best guess on why this configuration would not work in the fashion you describe would be if the LCD mode had some dependency on the LCD itself to be in place before it configured the VPBE to output digitally (perhaps if some I2C access to the LCD fails it gives up). I have not dug into the newer source code to see if this is the case, but I would expect something like this to be the issue since the LSP is tested with LCD hardware and has been known to work.

My anticipation of the LCD interface working in the newer ports is why I havent touched the driver code yet. I have worked right from the 1.20 DVSDK versions and this works absolutely fine. I will now revert back to an older LSP release(probably the 1.30 one) and try to test it out to find if this new port actually lost support of this.

Thanx!

Sundar

FYI, I do not have to hardware to test LCD output myself, but have verified with our internal teams and they assure me that DVSDK 1.30 (LSP 1.20) supports VGA LCD output as documented in the PSP documentation.

Juan, To be on the same platofrm,  I am using the LSP 2.0, which is MVL 5.0 Pro