[Freedreno] db820c: Input signal Out of range

Sun Aug 12 07:47:28 UTC 2018

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!
> 