Re: [Freedreno] db820c: Input signal Out of range

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Friday 10 August 2018 12:08 PM, Ricardo Ribalda Delgado wrote:
Hello

I have a screen that via edid expects the following modeline by
default via detailed mode:

Modeline "1680x1050"x60.0  146.30  1680 1784 1960 2240  1050 1053 1059
1089 +hsync -vsync

When the card is configured to that modeline the screen cannot output
the image and shows the following error message: Input signal out of
range.

I have tried with a different card and that exact modeline:

xrandr --newmode fast 146.30  1680 1784 1960 2240  1050 1053 1059 1089
+hsync -vsync
xrandr --addmode HDMI-1 slow
xrandr --output HDMI-1 --mode fast

and the screen works just fine.


If I just tweak down a bit the clock:
xrandr --newmode slow 146.25  1680 1784 1960 2240  1050 1053 1059 1089
+hsync -vsync
the screen shows an image as expected.

I believe that there might be a misscalculation on the pll code. And I
am printing the debug info from:
drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c

The configuration that fails shows:

[  138.553168] VCO freq: 8778000000
[  138.553172] fdata: 1463000000
[  138.553187] pix_clk: 146300000
[  138.555447] tmds clk: 146300000
[  138.558336] HSCLK_SEL: 1
[  138.561277] DEC_START: 114
[  138.564316] DIV_FRAC_START: 311296
[  138.567080] PLL_CPCTRL: 11
[  138.569614] PLL_RCTRL: 22
[  138.572996] PLL_CCTRL: 40
[  138.575698] INTEGLOOP_GAIN: 256
[  138.578366] TX_BAND: 0
[  138.580986] PLL_CMP: 7802
[  138.583936] com_svs_mode_clk_sel = 0x2
[  138.586351] com_hsclk_sel = 0x21
[  138.589067] com_lock_cmp_en = 0x0
[  138.592704] com_pll_cctrl_mode0 = 0x28
[  138.596089] com_pll_rctrl_mode0 = 0x16
[  138.599286] com_cp_ctrl_mode0 = 0xb
[  138.602955] com_dec_start_mode0 = 0x72
[  138.606678] com_div_frac_start1_mode0 = 0x0
[  138.610064] com_div_frac_start2_mode0 = 0xc0
[  138.613894] com_div_frac_start3_mode0 = 0x4
[  138.617964] com_integloop_gain0_mode0 = 0x0
[  138.622478] com_integloop_gain1_mode0 = 0x1
[  138.626393] com_lock_cmp1_mode0 = 0x7a
[  138.630550] com_lock_cmp2_mode0 = 0x1e
[  138.634719] com_lock_cmp3_mode0 = 0x0
[  138.638545] com_core_clk_en = 0x2c
[  138.642271] com_coreclk_div = 0x5
[  138.646001] phy_mode = 0x0
[  138.649308] tx_l0_lane_mode = 0x43
[  138.652684] tx_l2_lane_mode = 0x43
[  138.655275] tx_l0_tx_band = 0x4
[  138.658679] tx_l0_tx_drv_lvl = 0x25
[  138.662070] tx_l0_tx_emp_post1_lvl = 0x23
[  138.665101] tx_l0_vmode_ctrl1 = 0x0
[  138.668571] tx_l0_vmode_ctrl2 = 0xd
[  138.672747] tx_l1_tx_band = 0x4
[  138.676037] tx_l1_tx_drv_lvl = 0x25
[  138.679493] tx_l1_tx_emp_post1_lvl = 0x23
[  138.682633] tx_l1_vmode_ctrl1 = 0x0
[  138.686117] tx_l1_vmode_ctrl2 = 0xd
[  138.690272] tx_l2_tx_band = 0x4
[  138.693571] tx_l2_tx_drv_lvl = 0x25
[  138.697050] tx_l2_tx_emp_post1_lvl = 0x23
[  138.700168] tx_l2_vmode_ctrl1 = 0x0
[  138.703641] tx_l2_vmode_ctrl2 = 0xd
[  138.707816] tx_l3_tx_band = 0x4
[  138.711092] tx_l3_tx_drv_lvl = 0x25
[  138.714577] tx_l3_tx_emp_post1_lvl = 0x23
[  138.717705] tx_l3_vmode_ctrl1 = 0x0
[  138.721182] tx_l3_vmode_ctrl2 = 0x0

and the configuration that works:

[   62.936970] VCO freq: 8775000000
[   62.936976] fdata: 1462500000
[   62.936990] pix_clk: 146250000
[   62.939250] tmds clk: 146250000
[   62.942175] HSCLK_SEL: 1
[   62.945095] DEC_START: 114
[   62.948117] DIV_FRAC_START: 270336
[   62.950881] PLL_CPCTRL: 11
[   62.953421] PLL_RCTRL: 22
[   62.956798] PLL_CCTRL: 40
[   62.959475] INTEGLOOP_GAIN: 256
[   62.962179] TX_BAND: 0
[   62.964785] PLL_CMP: 7799
[   62.967738] com_svs_mode_clk_sel = 0x2
[   62.970153] com_hsclk_sel = 0x21
[   62.972862] com_lock_cmp_en = 0x0
[   62.976506] com_pll_cctrl_mode0 = 0x28
[   62.979893] com_pll_rctrl_mode0 = 0x16
[   62.983088] com_cp_ctrl_mode0 = 0xb
[   62.986749] com_dec_start_mode0 = 0x72
[   62.990480] com_div_frac_start1_mode0 = 0x0
[   62.993868] com_div_frac_start2_mode0 = 0x20
[   62.997688] com_div_frac_start3_mode0 = 0x4
[   63.001769] com_integloop_gain0_mode0 = 0x0
[   63.006281] com_integloop_gain1_mode0 = 0x1
[   63.010189] com_lock_cmp1_mode0 = 0x77
[   63.014354] com_lock_cmp2_mode0 = 0x1e
[   63.018521] com_lock_cmp3_mode0 = 0x0
[   63.022338] com_core_clk_en = 0x2c
[   63.026072] com_coreclk_div = 0x5
[   63.029804] phy_mode = 0x0
[   63.033103] tx_l0_lane_mode = 0x43
[   63.036488] tx_l2_lane_mode = 0x43
[   63.039078] tx_l0_tx_band = 0x4
[   63.042479] tx_l0_tx_drv_lvl = 0x25
[   63.045864] tx_l0_tx_emp_post1_lvl = 0x23
[   63.048901] tx_l0_vmode_ctrl1 = 0x0
[   63.052375] tx_l0_vmode_ctrl2 = 0xd
[   63.056541] tx_l1_tx_band = 0x4
[   63.059840] tx_l1_tx_drv_lvl = 0x25
[   63.063295] tx_l1_tx_emp_post1_lvl = 0x23
[   63.066437] tx_l1_vmode_ctrl1 = 0x0
[   63.069908] tx_l1_vmode_ctrl2 = 0xd
[   63.074075] tx_l2_tx_band = 0x4
[   63.077373] tx_l2_tx_drv_lvl = 0x25
[   63.080844] tx_l2_tx_emp_post1_lvl = 0x23
[   63.083971] tx_l2_vmode_ctrl1 = 0x0
[   63.087428] tx_l2_vmode_ctrl2 = 0xd
[   63.091609] tx_l3_tx_band = 0x4
[   63.094906] tx_l3_tx_drv_lvl = 0x25
[   63.098379] tx_l3_tx_emp_post1_lvl = 0x23
[   63.101505] tx_l3_vmode_ctrl1 = 0x0
[   63.104979] tx_l3_vmode_ctrl2 = 0x0

Unfortunately I do not have the documentation of the pll to validade
any of the two setups.

I'm not sure if there is any public documentation of the hardware
registers for 8x96. I'd myself mostly ported this code from the
downstream hdmi PLL driver (the 8996_v3 code in particular):

https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/clk/msm/mdss/mdss-hdmi-pll-8996.c?h=msm-3.18

The PLL seems to be getting locked for both cases. But for some reason,
when trying to configure it for 146.30 Mhz, it's generating a
wayward enough value for the monitor to reject it.

I looked at the logs, and the configurations match what both the
upstream and downstream drivers are trying to do.

The main differences between the configurations seem to be the
fractional component calculation and the computation of PLL_CMP.

From my experience, minor changes in the fractional component don't
calculation doesn't cause too much of a difference.

As an experiment, you could try to forcibly set the PLL_CMP value to
7799 in the non-working case to check if that's causing the issue.
We could then try to find out from someone within Qualcomm if there's
a better way to compute this parameter.

Thanks,
Archit



Where can I find that doc?
Any ideas of how to proceed?


Thanks!




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux