Firefly Open Source Community

   Login   |   Register   |
New_Topic
12
New Topic
Print Previous Topic Next Topic

Display Port (eDP) issue

115

Credits

0

Prestige

0

Contribution

registered members

Rank: 2

Credits
115

Display Port (eDP) issue

Posted at 8/12/2015 15:00:09      View:20809 | Replies:11        Print      Only Author   [Copy Link] 1#
Last edited by return0 In 8/12/2015 15:02 Editor

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



Reply

Use props Report

2442

Credits

0

Prestige

0

Contribution

vip

Rank: 6Rank: 6

Credits
2442
Posted at 8/13/2015 09:48:11        Only Author  2#
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.

0001-kernel-dts-support-LCD-LP097Qx2.rar

888 Bytes, Down times: 144

Reply

Use props Report

115

Credits

0

Prestige

0

Contribution

registered members

Rank: 2

Credits
115
Posted at 8/13/2015 10:31:43        Only Author  3#
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?

Reply

Use props Report

2442

Credits

0

Prestige

0

Contribution

vip

Rank: 6Rank: 6

Credits
2442
Posted at 8/13/2015 14:23:57        Only Author  4#
out-face    = <OUT_P888>;

is this config match your edp lcd ?
Reply

Use props Report

8

Credits

0

Prestige

0

Contribution

new registration

Rank: 1

Credits
8
Posted at 8/13/2015 14:32:15        Only Author  5#
Hardware connect please refer to the attachment。

EDP1.JPG (84.67 KB, Down times: 312)

EDP1.JPG

EDP2.JPG (53.98 KB, Down times: 305)

EDP2.JPG
Reply

Use props Report

115

Credits

0

Prestige

0

Contribution

registered members

Rank: 2

Credits
115
Posted at 8/13/2015 20:55:47        Only Author  6#
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?
Reply

Use props Report

8

Credits

0

Prestige

0

Contribution

new registration

Rank: 1

Credits
8
Posted at 8/17/2015 12:06:20        Only Author  7#
Last edited by cb_cb In 8/17/2015 12:08 Editor

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

Use props Report

115

Credits

0

Prestige

0

Contribution

registered members

Rank: 2

Credits
115
Posted at 8/18/2015 14:06:41        Only Author  8#
Last edited by return0 In 8/19/2015 08:04 Editor
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.
Reply

Use props Report

115

Credits

0

Prestige

0

Contribution

registered members

Rank: 2

Credits
115
Posted at 8/19/2015 08:03:38        Only Author  9#
Last edited by return0 In 8/19/2015 08:07 Editor

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
Reply

Use props Report

115

Credits

0

Prestige

0

Contribution

registered members

Rank: 2

Credits
115
Posted at 8/19/2015 08:58:29        Only Author  10#
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?
Reply

Use props Report

Return to List
12
You need to log in before you can reply Login | Register

This forum Credits Rules

Quick Reply Back to top Back to list