I went a bit tricky way - using my own fork of Fenix build system, with my realtime kernel…
In general - you need to make changes to the Fenix mainline package pointing to the 5.19 kernel source, then undo some Khadas patches from 5.18 package, then add @narmstrong patches… I took them directly from his tree… (perhaps that diffs from linux patchwork could work, however I had to add some additional things like PHY_MESON_G12A_MIPI_DPHY_ANALOG which wasn’t in a patch list. Some hours spent making patches to be compatible and so on)
Best approach to wait a little bit to let Khadas team prepare there own patchset to Fenix build system based on Neil work… That have been long awaited feature, so worth to wait a little bit more 
3 Likes
@narmstrong Hi Neil, can MIPI DSI and HDMI dual display?
The HW can, but I have virtually no documentation on how to achieve multi display, so I have no idea how to achieve that
2 Likes
@narmstrong When both HDMI and DSI are enabled, I only connect one, can it display normally?
I pretty happy with @narmstrong work - it is excellent. So far I have minor glitches - sometimes I get screen flickering, but that could be related maybe to my power supply…
As for performance - it is good enough for me… QT with EGLFS works out of the box and HW accelerated and I’m getting enough performance for my needs … Something around 50 fps if I understand demo numbers correctly… Touchpanel is also works like charm…
Update: perhaps flickering is related to weird panel refresh rate of 47 Hz reported by QT… Dunno where should I fix that - @narmstrong could you please advise ?
qt.qpa.eglfs.kms: 0
qt.qpa.eglfs.kms: "DSI1" mode count: 1 crtc index: 0 crtc id: 39
qt.qpa.eglfs.kms: mode 0 1088 x 1920 @ 47 hz
xrandr also says we have only 47,02Hz refresh rate and it can’t be changed
root@fawn-dsp:/home/khadas# xrandr
Screen 0: minimum 320 x 200, current 1088 x 1920, maximum 3840 x 2160
DSI-1 connected primary 1088x1920+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1088x1920 47.02*
Seems it may need some DTS changes to set up right modes for TS050 panel or perhaps init sequence in
needs to be changed (so far I can see mainlined panel driver doesn’t read anything from DTS and have only one default mode set) ? @Frank - can you please have a look and perhaps advise ?
1 Like
@OldNavi I can light up the TS050, what I’m looking for now is to make HDMI and TS050 compatible in one code
1 Like
It seems that timings for panel are different in maintained panel driver
In the mainline panel driver itself - timings are
static const struct drm_display_mode default_mode = {
.clock = 120000,
.hdisplay = 1088,
.hsync_start = 1088 + 104,
.hsync_end = 1088 + 104 + 4,
.htotal = 1088 + 104 + 4 + 127,
.vdisplay = 1920,
.vsync_start = 1920 + 4,
.vsync_end = 1920 + 4 + 2,
.vtotal = 1920 + 4 + 2 + 3,
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
};
so we have v_total = 1929 and h_total = 1323
in the 4.9 BSP kernel for TS050 timings are bit different
lcd_1{
model_name = "TS050";
interface = "mipi";
basic_setting = <1080 1920 /*h_active, v_active*/
1120 1933 /*h_period, v_period*/
8 /*lcd_bits*/
64 118>; /*screen_widht, screen_height*/
lcd_timing = <2 23 0 /*hs_width, hs_bp, hs_pol*/
4 7 0>; /*vs_width, vs_bp, vs_pol*/
clk_attr = <0 /*fr_adj_type(0=clk, 1=htotal, 2=vtotal)*/
0 /*clk_ss_level */
1 /*clk_auto_generate*/
120000000>; /*pixel_clk(unit in Hz)*/
having h_total = 1120 and v_total = 1933
However if I try to set similar settings in mainlined panel driver - getting weird output on the screen… and playing with sync values I was able to change refresh rate up to 50Hz but got a lot of screen flickering seems due to the sync lost. So without good knowledge how to set it up - to get correct timing for correct vertical refresh rate - I’m just got stuck.
Few trial and run attempts and I ended with the following temp config (still rare flickering) in ts050 driver, but at least it is 1080x1920 resolution
static const struct drm_display_mode default_mode = {
.clock = 120000,
.hdisplay = 1080,
.hsync_start = 1080 + 104,
.hsync_end = 1080 + 104 + 4,
.htotal = 1080 + 104 + 4 + 8 + 127,
.vdisplay = 1920,
.vsync_start = 1920 + 7,
.vsync_end = 1920 + 4 + 7,
.vtotal = 1920 + 4 + 7 + 2,
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
};
however still not okay with refresh rate - still far from 60Hz
root@fawn-dsp:/home/khadas# xrandr
Screen 0: minimum 320 x 200, current 1080 x 1920, maximum 3840 x 2160
DSI-1 connected primary 1080x1920+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1080x1920 46.92*
root@fawn-dsp:/home/khadas#
So I hope Khadas team will manage to set right timings for mainlined TS050 panel driver
1 Like
It seems I’ve been able to fix the picture quality of the TS050 display in the mainline kernel.
First of all, thank you Neil @narmstrong for bringing the TS050 support to the mainline kernel!
If I understand correctly, the flickering of the display and the blurry picture come from the clocks (specifically GP0_PLL_DCO) having too low a frequency - there is a line in the dmesg output complaining about the failed pll lock.
The needle-like glitches in the display lines and the top offset can be fixed by adjusting the front and back porch values.
I am attaching the patches needed on top of the “amlogic/v5.20/g12-dsi” branch: TS050 patches
The main changes are:
- export the GP0_PLL_DCO clock ID to the Devicetree bindings.
- set the value of the GP0_PLL clock to 960MHz (was 720MHz), the value of the GP0_PLL_DCO clock to 3.84GHz via the devicetree.
- force the high speed clock rate to x8 of the pixel clock (the current code sets it to x6). I am not sure about this one, but 960MHz seems to work OK, and 720MHz does not.
- change the front/back porch values and set the VSYNC back porch value to 34 in the display init sequence (this one removes the top offset. Yes, it is 32 for the display mode, and 34 for the init sequence. I do not know why, but this combination straightens the picture).
1 Like
I’m afraid - you need to bit more work on this patches… I’ve applied your patches - it not yet good, as there are kernel errors reported in dmesg
[ 904.309792] meson-dw-mipi-dsi ffd07000.mipi-dsi: failed to write command FIFO
[ 904.329864] meson-dw-mipi-dsi ffd07000.mipi-dsi: failed to write command FIFO
[ 904.350569] meson-dw-mipi-dsi ffd07000.mipi-dsi: failed to write command FIFO
[ 904.478270] meson-dw-mipi-dsi ffd07000.mipi-dsi: failed to write command FIFO
[ 904.478283] panel-khadas-ts050 ffd07000.mipi-dsi.0: failed write cmds: -110
Also timings for panel are still not correct - xrandr show refresh rate is not okay
Screen 0: minimum 320 x 200, current 1080 x 1920, maximum 3840 x 2160
DSI-1 connected primary 1080x1920+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1080x1920 47.22*
For correct timing you better have a look into android BSP kernel - it has different timings - but they are correct 1080x1920x60Hz for sure… VPorch is 11 there…
Hi.
That’s strange. We’ve tested on several units and none reports these errors.
Does the screen flicker or is the picture blurry with the patches applied?
khadas@Khadas:~$ dmesg | grep meson-dw-mipi-dsi
khadas@Khadas:~$
Maybe this is a hardware issue?
Could you please check that there is the following line in the dmesg output:
khadas@Khadas:~$ dmesg | grep lane_mbps
[ 0.894793] Set lane_mbps 960 from rate 960000000 clock 120000
Please verify also that the clock is configured correctly:
root@Khadas:/home/khadas# cat /sys/kernel/debug/meson-clk-msr/clks/gp0_pll
959843750 +/-31250Hz
Yes, the refresh rate, reported by the xrandr is still 47.12Hz, but the picture becomes steady and clear with the patches applied (by the way, there is occasional flickering with the official Khadas VIM3 Ubuntu image using the 4.9 kernel).
The screen shows the Ubuntu 22.04 desktop (gnome/xwayland, built with fenix 1.0.11, amlogic/v5.20/g12-dsi branch + the 2 patches). Xrandr reports 1080x1920 at 47.12Hz.
Unlikely - never seen that with vanilla @narmstrong patches, or on BSP kernel or android.
requested outputs show applied freqs…
khadas@fawn-dsp:~$ dmesg | grep lane_mbps
[ 13.607165] Set lane_mbps 960 from rate 960000000 clock 120000
khadas@fawn-dsp:~$ sudo cat /sys/kernel/debug/meson-clk-msr/clks/gp0_pll
959843750 +/-31250Hz
khadas@fawn-dsp:~$
This is of course not correct as it does influence everything due to the wrong Vsync
even in QT with eglfs. Have you tried to check how official android Pie works and reports frequencies ? It is 60HZ and it is smooths.
I bet that without deep knowledge from Khadas panel datasheets - we just can make rough assumptions and dumb guesses
Just for fun - I’ve applied android timings for mainline kernel with your freq. patches - I got 55Hz refresh rate and of course jerky output. I assume that clks still need adjustments to reach native 60Hz for TS050 panel and here we have to rely on Khadas team 
PS: Such errors are happening when LCD panel goes to sleep, seems there are errors in wake-up sequence
[ 1714.928073] meson-dw-mipi-dsi ffd07000.mipi-dsi: failed to write command FIFO
[ 1714.948830] meson-dw-mipi-dsi ffd07000.mipi-dsi: failed to write command FIFO
[ 1714.969014] meson-dw-mipi-dsi ffd07000.mipi-dsi: failed to write command FIFO
[ 1715.096619] meson-dw-mipi-dsi ffd07000.mipi-dsi: failed to write command FIFO
[ 1715.096633] panel-khadas-ts050 ffd07000.mipi-dsi.0: failed write cmds: -110
Few more tidbits
@dmitry_k - forcing DSI line to 960Mhz using hardcoded factor of 8 - is a dirty hack actually… as it breaks a logic of DSI lane bandwidth calculations…
However in android BSP kernel it is kind of a use…
[ 1.528774] lcd: TS050, mipi, 8bit, 1080x1920
[ 1.533314] lcd: pixel_clk = 119.978MHz, bit_rate = 959.824MHz
[ 1.539743] vout: error: invalid vinfo1. current vmode is not supported
[ 1.546195] fb: current vmode=invalid, cmd: 0x20000
[ 1.551247] lcd: lcd_probe ok
[ 1.554835] vout: create vout attribute OK
and android clocks are:
kvim3l:/sys/kernel/debug/aml_clkmsr # cat clkmsr
[ 0][ 0]am_ring_osc_clk_out_ee[0]
[ 1][ 0]am_ring_osc_clk_out_ee[1]
[ 2][ 0]am_ring_osc_clk_out_ee[2]
[ 3][ 0]am_ring_osc_clk_out_ee[3]
[ 4][ 960000000]gp0_pll_clk
[ 5][ 0]gp1_pll_clk
[ 6][ 0]cts_enci_clk
[ 7][ 167000000]clk81
[ 8][ 0]cts_encp_clk
[ 9][ 120000000]cts_encl_clk
[10][ 0]cts_vdac_clk
[11][ 2000000]mac_eth_tx_clk
[12][ 0]hifi_pll_clk
[13][ 0]mod_tcon_clko
[14][ 0]cts_FEC_CLK_0
[15][ 0]cts_FEC_CLK_1
[16][ 0]cts_FEC_CLK_2
[17][ 0]sys_pll_div16
[18][ 0]sys_cpu_clk_div16
[19][ 0]lcd_an_clk_ph2
[20][ 24000000]rtc_osc_clk_out
[21][ 0]lcd_an_clk_ph3
[22][ 25000000]mac_eth_phy_ref_clk
[23][ 50000000]mpll_clk_50m
[24][ 0]cts_eth_clk125Mhz
[25][ 0]cts_eth_clk_rmii
[26][ 0]sc_clk_int
[27][ 0]co_clkin_to_mac
[28][ 1000000]cts_sar_adc_clk
[29][ 0]pcie_clk_inp
[30][ 0]pcie_clk_inn
[31][ 0]mpll_clk_test_out
[32][ 800000000]cts_vdec_clk
[33][ 0]1'b0
[34][ 0]eth_mppll_50m_ckout
[35][ 800000000]cts_mali_clk
[36][ 0]cts_hdmi_tx_pixel_clk
[37][ 0]cts_cdac_clk_c
[38][ 0]cts_vdin_meas_clk
[39][ 0]cts_bt656_clk0
[40][ 0]arm_ring_osc_clk_out[4]
[41][ 2000000]mac_eth_rx_clk_rmii
[42][ 24000000]mp0_clk_out
[43][ 400000000]fclk_div5
[44][ 0]cts_pwm_B_clk
[45][ 0]cts_pwm_A_clk
[46][ 667000000]cts_vpu_clk
[47][ 0]ddr_dpll_pt_clk
[48][ 25000000]mp1_clk_out
[49][ 0]mp2_clk_out
[50][ 0]mp3_clk_out
[51][ 24000000]cts_sd_emmc_clk_C
[52][ 24000000]cts_sd_emmc_clk_B
[53][ 24000000]cts_sd_emmc_clk_A
[54][ 200000000]cts_vpu_clkc
[55][ 0]vid_pll_div_clk_out
[56][ 0]cts_wave420l_aclk
[57][ 0]cts_wave420l_cclk
[58][ 0]cts_wave420l_bclk
[59][ 0]cts_hcodec_clk
[60][ 0]arm_ring_osc_clk_out[5]
[61][ 0]gpio_clk_msr
[62][ 500000000]cts_hevcb_clk
[63][ 24000000]cts_dsi_meas_clk
[64][ 0]cts_spicc_1_clk
[65][ 0]cts_spicc_0_clk
[66][ 0]cts_vid_lock_clk
[67][ 960000000]cts_dsi_phy_clk
[68][ 286000000]cts_hdcp22_esmclk
[69][ 24000000]cts_hdcp22_skpclk
[70][ 0]cts_pwm_F_clk
[71][ 24000000]cts_pwm_E_clk
[72][ 0]cts_pwm_D_clk
[73][ 0]cts_pwm_C_clk
[74][ 0]arm_ring_osc_clk_out[6]
[75][ 500000000]cts_hevcf_clk
[76][ 0]arm_ring_osc_clk_out[7]
[77][ 29000000]rng_ring_osc_clk[0]
[78][ 41000000]rng_ring_osc_clk[1]
[79][ 51000000]rng_ring_osc_clk[2]
[80][ 45000000]rng_ring_osc_clk[3]
[81][ 500000000]cts_vapbclk
[82][ 0]cts_ge2d_clk
[83][ 0]co_rx_clk
[84][ 0]co_tx_clk
[85][ 0]arm_ring_osc_clk_out[8]
[86][ 0]arm_ring_osc_clk_out[9]
[87][ 0]mipi_csi_phy_clk
[88][ 0]csi2_adapt_clk
[89][ 0]HDMI_CLK_TODIG
[90][ 24000000]cts_hdmitx_sys_clk
[91][ 800000000]nna_core_clk
[92][ 800000000]nna_axi_clk
[93][ 0]vad_clk
[94][ 0]eth_phy_rxclk
[95][ 0]eth_phy_plltxclk
[96][ 333000000]cts_vpu_clkb
[97][ 667000000]cts_vpu_clkb_tmp
[98][ 1000000]cts_ts_clk
[99][ 0]arm_ring_osc_clk_out[10]
[100][ 0]arm_ring_osc_clk_out[11]
[101][ 0]arm_ring_osc_clk_out[12]
[102][ 0]arm_ring_osc_clk_out[13]
[103][ 0]arm_ring_osc_clk_out[14]
[104][ 0]arm_ring_osc_clk_out[15]
[105][ 0]arm_ring_osc_clk_out[16]
[106][ 0]ephy_test_clk
[107][ 6000000]au_dac_clk_g128x
[108][ 0]c_alocker_in_clk
[109][ 0]c_alocker_out_clk
[110][ 0]audio_tdmout_c_sclk
[111][ 3000000]audio_tdmout_b_sclk
[112][ 0]audio_tdmout_a_sclk
[113][ 0]audio_tdmin_lb_sclk
[114][ 0]audio_tdmin_c_sclk
[115][ 3000000]audio_tdmin_b_sclk
[116][ 0]audio_tdmin_a_sclk
[117][ 0]audio_resampleA_clk
[118][ 0]audio_pdm_sysclk
[119][ 0]audio_spdifout_b_mst_clk
[120][ 0]audio_spdifout_mst_clk
[121][ 0]audio_spdifin_mst_clk
[122][ 0]mod_audio_pdm_dclk_o
[123][ 0]audio_resampled_clk
[124][ 0]earcx_pll_(dmac)_clk
[125][ 0]earcrx_pll_test_clk
[126][ 0]csi_phy0_clk_out
[127][ 0]clk_csi2_data
however that gives only 55Hz refresh rate in android…
mBacklight=com.android.server.lights.LightsService$LightImpl@e558a26
mDisplayInfos=
PhysicalDisplayInfo{1920 x 1080, 55.42 fps, density 2.0, 428.0 x 413.0 dpi, secure true, appVsyncOffset 1000000, bufferDeadline 18044028}
mSupportedModes=
DisplayModeRecord{mMode={id=1, width=1920, height=1080, fps=55.42}}
Pff… android is also not that good (it doesn’t reach 60Hz so forget about smoothness on TS050)
I dunno where 120MHz pixel clock came from for TS050 - it is definitely too low pixel clock for 1080p60Hz… so I’m afraid 60Hz can’t be reached
checking various DTS I’ve found that higher clocks usually used for 60Hz refresh rate, so calculated more accurate pixel clock for 1080p60Hz - it is 160MHz
and that is running on pure @narmstrong vanilla code… in this case using pixel clock of 160MHz with get 960mbps per lane bandwidth calculated correctly…
with that I got
root@fawn-dsp:/home/khadas# dmesg | grep lane
[ 8.057336] Set lane_mbps 960 from rate 960000000 clock 160000
And with that settings - got crisp image and almost desired 60Hz refresh rate
root@fawn-dsp:/home/khadas# xrandr
Screen 0: minimum 320 x 200, current 1080 x 1920, maximum 3840 x 2160
DSI-1 connected primary 1080x1920+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1080x1920 59.97*
Of course that’s not something absolutely ideal - I have no datasheet for TS050 timings required… however it does work with vanilla mainline (no @dmitry_k patches needed)
So here it is DTS section changes
&mipi_dsi {
status = "okay";
assigned-clocks = <&clkc CLKID_GP0_PLL>,
<&clkc CLKID_MIPI_DSI_PXCLK_SEL>,
<&clkc CLKID_MIPI_DSI_PXCLK>;
assigned-clock-parents = <0>,
<&clkc CLKID_GP0_PLL>,
<0>;
assigned-clock-rates = <960000000>,
<0>,
<960000000>;
Here is ts050 driver code changes
/* Select CMD1 */
{0xff, 0x00},
{0xd3, 0x22}, /* RGBMIPICTRL: VSYNC back porch = 34 */
{0xd4, 0x04}, /* RGBMIPICTRL: VSYNC front porch = 4 */
};
static const struct drm_display_mode default_mode = {
.clock = 160000,
.hdisplay = 1080,
.hsync_start = 1080 + 117,
.hsync_end =1080 + 117 + 5,
.htotal = 1080 + 117 + 5 + 160,
.vdisplay = 1920,
.vsync_start = 1920 + 4 ,
.vsync_end = 1920 + 4 + 3,
.vtotal = 1920 + 4 + 3 + 32 ,
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
};
After long long iteration process - I’ve ended with seems to be correct values for configure timings for TS050 panel driver to get an exact and correct 60Hz refresh rate
@narmstrong - Neil maybe you can grab those setting into your panel-khadas-ts050.c code ?
static const struct drm_display_mode default_mode = {
.clock = 160000,
.hdisplay = 1080,
.hsync_start = 1080 + 117,
.hsync_end =1080 + 117 + 5,
.htotal = 1080 + 117 + 5 + 160,
.vdisplay = 1920,
.vsync_start = 1920 + 4 ,
.vsync_end = 1920 + 4 + 3,
.vtotal = 1920 + 4 + 3 + 31 ,
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
};
root@fawn-dsp:/home/khadas# xrandr
Screen 0: minimum 320 x 200, current 1080 x 1920, maximum 3840 x 2160
DSI-1 connected primary 1080x1920+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1080x1920 60.00*
root@fawn-dsp:/home/khadas#
1 Like
I don’t think narmstrong is working with amlogic development at the moment.
Great thanks for searching !!
I can push an update with those timings, did someone testes on a khadas edge device with those timings ?
3 Likes
Not me, I have only few VIMs from lineup
do you have a public email I can Cc you on the patch I’ll send upstream ?
Hello all,
I know this is an old thread, but I was wondering if anyone has a working version of Linux on the VIM3, using the TS050 screen. I’d like an image(external SD) of Linux - any recent version of Ubuntu that will display a desktop in landscape mode on the TS050. I have a project where I need to use this hardware combination that I’d like to finish up. If so, would it be possible to upload to a Google drive. A link would be great. Thx.
Rick
Hi @redjr
Have you tried the 5.15 kernel image ?
I have not. However, according to this thread MIPI screens aren’t working. That was Oct 23 though. If you know of another link, that may be later, could you post it?