How To Get A20 To Drive LCD DCLK For FHD Display (134MHz)

Started by ericb, March 22, 2016, 04:15:28 AM

Previous topic - Next topic

ericb

Hello,
I'm trying to get my LIME2 working with a full HD LCD display using the RGB LCD interface. Since the display is 1920 x 1080 @ 60Hz the LCD clock needs to run at 134 MHz. I've been able to get the clock at that frequency by changing the FEX file, but, the voltage swing is horrible (0.9V to 2.5V) for a 3.3V system. I also have my clock pin's drive strength set to level 3 (the max). I'm hoping someone has another trick to try.

Thanks,
Eric

soenke

Maybe you could try to stabilize the signal by adding some swichting circuit in between to amplify the signal to a constant level using some really fast logic transistors?

ericb

I may have to do that Soenke. Before I change hardware I want to understand what the io_config register does for the LCD. I also need to take a look at the 24 data lines. I fear I have the same problem there.

I can't wait for the A64-OLinuXino to be released.

Eric

soenke

Maybe it might be acceptable for you to run the LCD on 30Hz, depending on what you plan to use it for.
To show some videos, pictures etc this could be enough.

ericb

I've been looking in to running the LCD at a lower refresh rate too. Currently my setup is that I have the A20 driving a SSD2828 MIPI translator to a full HD MIPI cell phone LCD. I need to figure out how to change the refresh rate of the A20, SSD2828, and the display. Do you happen to know how to set the refresh rate of the A20?

The other option I'm looking at is using a PLL to recover the clock from the A20.

Eric

soenke

have a look here:
http://linux-sunxi.org/Display

section "using hardware scaler"

Maybe that could be useful for you?

soenke

As i was just thinking about it... cant you just change the refresh rate in the Xorg.conf?

ericb

Thank you for continuing to share ideas soenke.

I'm running Android, not Linux, so there is no Xorg.

I had looked at http://linux-sunxi.org/Display , but I think the scaler is about the number / size of pixels on the screen not the refresh rate.

Eric

soenke

Then try to half the fex-paramter

lcd_dclk_freq

That should lead to a halved refresh rate.

ericb

Changing the lcd_dclk_freq value does indeed change the refresh (frame_rate). I found the code below which shows how the lcd_ht and lcd_vt parameters from the FEX file are used to calculate the frame_rate for an LCD.

linux-3.4/drivers/video/sun7i/disp/de_bsp/de/disp_lcd.c

if(gdisp.screen[sel].output_type & DISP_OUTPUT_TYPE_LCD)
{
        frame_rate = (gpanel_info[sel].lcd_dclk_freq * 1000000) / (gpanel_info[sel].lcd_ht * (gpanel_info[sel].lcd_vt / 2)) ;
}

soenke

And does the slower refresh rate improve the signal quality?

ericb

QuoteAnd does the slower refresh rate improve the signal quality?

Absolutely. I also knew from other experiments that the A20 could drive a clock out of the LCD clock pin at 100 MHz. Somewhere between 100 MHz and 133 MHz it starts to have problems. I see edge rates of about 4 ns, so, I suspect that the A20's max drive frequency is around 125 MHz. This is with the default drive more. Setting drive more 3 helps a little, but, not much.

Now that I've worked around the clock problem I have a new issue. When I have lcd_x set to 1080, but not 1079 or 1081 I get a memory validation error. But, that issue will be another forum thread.

MALI PHYSICAL RANGE VALIDATION ERROR: The range supplied was: phys_base=0x44000000, size=0x00FE1000


Thanks for working through the clock problem with me Soenke.

Eric