Display Port (eDP) issue

return0

Hi all,

on Firefly RK3288, has anyone successfully tested the eDP output from the expansion headers?

Apart from the correct LCD parameters in the kernel DT, what changes (Android/Rockchip kernel 3.10) are required for eDP to work properly?

This is what eDP output currently looks like with a DP capable screen:




I have also tried various eDP LCDs, with same results.

Why is there no mention in the Firefly Wiki regarding using eDP? http://wiki.t-firefly.com/index.php/Firefly-RK3288/en

My included eDP dtsi (for eDP LCD):

1. / {                                                                                                                                                            
   
2. 
   
3.         disp_timings: display-timings {
   
4.                         native-mode = <&timing0>;
   
5.                         timing0: timing0 {
   
6.                 screen-type = <SCREEN_EDP>;
   
7.                 out-face    = <OUT_P888>;
   
8.                 clock-frequency = <268500000>;
   
9.                 hactive = <2560>;
   
10.                 vactive = <1600>;
    
11.                 hback-porch = <80>;
    
12.                 hfront-porch = <120>;
    
13.                 vback-porch = <4>;
    
14.                 vfront-porch = <12>;
    
15.                 hsync-len = <32>;
    
16.                 vsync-len = <4>;
    
17.                 hsync-active = <1>;
    
18.                 vsync-active = <1>;
    
19.                 de-active = <0>;
    
20.                 pixelclk-active = <0>;
    
21.                 swap-rb = <0>;
    
22.                 swap-rg = <0>;
    
23.                 swap-gb = <0>;
    
24.                         };
    
25.                };
    
26. };
    

Copy the code

zhansb

Firefly-RK3288 support EDP LCD, and tested it,  display normally.
Add EDP LCD is the same as LVDS.
like the attachment, it is a patch of supporting edp.

return0

zhansb Posted at 8/13/2015 09:48
Firefly-RK3288 support EDP LCD, and tested it,  display normally.
Add EDP LCD is the same as LVDS.
...

Thank you zhansb, the patch you posted is basically what I have done in the kernel DT - my timings match the LCD requirements but I have also tried different timings with DP monitor after reading EDID data.

The resulting image has colour issues (seems RGB crossed):



Should the source (Firefly) ML lanes be crossed just after the expansion header? The DP cable should do the lanes crossing but I am not sure if this is also needed at the source.




What did you use for testing from the expansion header? A DP cable with the wires soldered to individual pins or a PCB with DP receptacle specifically designed for this task?

zhansb

out-face    = <OUT_P888>;

is this config match your edp lcd ?

cb_cb

Hardware connect please refer to the attachment。

return0

Hi zhansb, yes RGB888 pixel format is accepted by the LCD - I have also tried 18 and 16bit observing the same results.

Hi cb_cb, thank you - I have confirmed that the pins are correctly wired between the Firefly eDP header and the DP receptacle. Can the eDP signal be used successfully with a DP cable (~1.5 meters) without signal issues?

cb_cb

Theoretical support 1.5 meters DP cable。Maybe you can try a shorter cable or reduce resolution.

return0

cb_cb Posted at 8/17/2015 12:06
Theoretical support 1.5 meters DP cable。Maybe you can try a shorter cable or reduce resolution.

Hi cb_cb, I have tested with a high quality, shorter DP cable (1m) - the resulting image is identical as per above screenshots.

Can you confirm that you have tested the Firefly eDP output successfully with a DP cable to a monitor or DP screen? How was the cable connected to the expansion header?

A picture or schematic would greatly help.

I have noticed various things while experimenting and I wonder if you have had any previous experience with these subjects:

1. Changing the resolution in the kernel DT does not affect the detected (sink side) resolution which remains 1920x1080 - different image scaling is visible however.

2. The following DT parameters do not affect the resulting image where they should:

1. swap-rb = <0>;
   
2. swap-rg = <0>;
   
3. swap-gb = <0>;

Copy the code

3. Kernel bootlog reports multiple error entries such as "rk32-edp: Input video stream is not detected" - eDP link training and EDID are successful.

4. Reversing the DCLK does not affect the image on screen.

5. HDMI driver/support cannot be disabled from the kernel configuration as code dependencies break and the build fails.

Do you (or anyone else here) happen to have the Rockchip documentation "RockChip_DSS Development Guide v1.2" in English? It contains several sections related to LCD, EDP, LVDS etc. including kernel and DTS configurations.

return0

To confirm point 1, from above:

1. Changing the resolution in the kernel DT does not affect the detected (sink side) resolution which remains 1920x1080 - different image scaling is visible however.

You will notice that the detected resolution (centre-bottom side of the screen) is 1920x1080 - this does not reflect what I set in the device tree. Why is that?

To obtain the stretched image like visible above I swapped hactive/vactive parameters, like so:

1. hactive = <1200>;
   
2. vactive = <1920>;

Copy the code

return0

See resolution mismatch by reading framebuffer information:

1. root@rk3288:/sys/class/graphics/fb0 # cat disp_info
   
2. z-order:
   
3.   layer3_sel_win[3]
   
4.   layer2_sel_win[2]
   
5.   layer1_sel_win[1]
   
6.   layer0_sel_win[0]
   
7. win0:
   
8.   state:0,   fmt:ARGB888,   y_vir:320,   uv_vir:320
   
9.   xact: 320,   yact: 240,   dsp_x: 320,   dsp_y: 240,   x_st:   0,   y_st:   0
   
10.   y_h_fac:    4096,   y_v_fac:    4096,   uv_h_fac:    4096,   uv_v_fac:    4096
    
11.   y_addr: 0x00000000,   uv_addr:0x00000000
    
12. win1:
    
13.   state:1,   fmt:ARGB888,   y_vir:1920,   uv_vir:0
    
14.   xact:1920,   yact:1080,   dsp_x:1920,   dsp_y:1080,   x_st:   0,   y_st:   0
    
15.   y_h_fac:    4096,   y_v_fac:    4096,   uv_h_fac:    4096,   uv_v_fac:    4096
    
16.   y_addr: 0x108ca000,   uv_addr:0x00000000
    
17. win2:
    
18.   state:0
    
19.   fmt:ARGB888
    
20.   area0:  state:0,  y_vir: 320,  dsp_x: 320,  dsp_y: 240,  x_st:   0,  y_st:   0,  addr:0x00000000
    
21.   area1:  state:0,  y_vir: 320,  dsp_x: 320,  dsp_y: 240,  x_st:   0,  y_st:   0,  addr:0x00000000
    
22.   area2:  state:0,  y_vir: 320,  dsp_x: 320,  dsp_y: 240,  x_st:   0,  y_st:   0,  addr:0x00000000
    
23.   area3:  state:0,  y_vir: 320,  dsp_x: 320,  dsp_y: 240,  x_st:   0,  y_st:   0,  addr:0x00000000
    
24. win3:
    
25.   state:0
    
26.   fmt:ARGB888
    
27.   area0:  state:0,  y_vir: 320,  dsp_x: 320,  dsp_y: 240,  x_st:   0,  y_st:   0,  addr:0x00000000
    
28.   area1:  state:0,  y_vir: 320,  dsp_x: 320,  dsp_y: 240,  x_st:   0,  y_st:   0   addr:0x00000000
    
29.   area2:  state:0,  y_vir: 320,  dsp_x: 320,  dsp_y: 240,  x_st:   0,  y_st:   0,  addr:0x00000000
    
30.   area3:  state:0,  y_vir: 320,  dsp_x: 320,  dsp_y: 240,  x_st:   0,  y_st:   0,  addr:0x00000000
    

Copy the code

Above it's reported 1920x1080 - the DT is set to 1920x1200. What is overriding the resolution settings?

Could the display EDID or DPCD data be misinterpreted by the eDP driver?