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

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

 



Hi,



On Monday 13 August 2018 02:24 PM, Ricardo Ribalda Delgado wrote:
Hi Archit
On Sun, Aug 12, 2018 at 9:47 AM Archit Taneja <architt@xxxxxxxxxxxxxx> wrote:

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.

forcing PLL_CMP to 7799 worked :)


Now trying with a different monitor. And it also fails :S This time
with this modeline

Modeline "1680x1050"x59.9  119.00  1680 1728 1760 1840  1050 1053 1059
1080 +hsync -vsync (64.7 kHz eP)

[    6.362578] VCO freq: 9520000000
[    6.362582] fdata: 2380000000
[    6.362584] pix_clk: 119000000
[    6.362586] tmds clk: 119000000
[    6.362588] HSCLK_SEL: 8
[    6.362589] DEC_START: 123
[    6.362591] DIV_FRAC_START: 1004885
[    6.362592] PLL_CPCTRL: 11
[    6.362594] PLL_RCTRL: 22
[    6.362596] PLL_CCTRL: 40
[    6.362597] INTEGLOOP_GAIN: 256
[    6.362599] TX_BAND: 1
[    6.362600] PLL_CMP: 12692
[    6.362602] com_svs_mode_clk_sel = 0x2
[    6.362604] com_hsclk_sel = 0x28
[    6.362605] com_lock_cmp_en = 0x0
[    6.362607] com_pll_cctrl_mode0 = 0x28
[    6.362608] com_pll_rctrl_mode0 = 0x16
[    6.362610] com_cp_ctrl_mode0 = 0xb
[    6.362611] com_dec_start_mode0 = 0x7b
[    6.362613] com_div_frac_start1_mode0 = 0x55
[    6.362615] com_div_frac_start2_mode0 = 0x55
[    6.362616] com_div_frac_start3_mode0 = 0xf
[    6.362617] com_integloop_gain0_mode0 = 0x0
[    6.362619] com_integloop_gain1_mode0 = 0x1
[    6.362621] com_lock_cmp1_mode0 = 0x94
[    6.362622] com_lock_cmp2_mode0 = 0x31
[    6.362624] com_lock_cmp3_mode0 = 0x0
[    6.362625] com_core_clk_en = 0x2c
[    6.362627] com_coreclk_div = 0x5
[    6.362628] phy_mode = 0x0
[    6.362630] tx_l0_lane_mode = 0x43
[    6.362631] tx_l2_lane_mode = 0x43
[    6.362633] tx_l0_tx_band = 0x5
[    6.362635] tx_l0_tx_drv_lvl = 0x25
[    6.362636] tx_l0_tx_emp_post1_lvl = 0x23
[    6.362638] tx_l0_vmode_ctrl1 = 0x0
[    6.362640] tx_l0_vmode_ctrl2 = 0xd
[    6.362641] tx_l1_tx_band = 0x5
[    6.362643] tx_l1_tx_drv_lvl = 0x25
[    6.362644] tx_l1_tx_emp_post1_lvl = 0x23
[    6.362646] tx_l1_vmode_ctrl1 = 0x0
[    6.362647] tx_l1_vmode_ctrl2 = 0xd
[    6.362649] tx_l2_tx_band = 0x5
[    6.362650] tx_l2_tx_drv_lvl = 0x25
[    6.362652] tx_l2_tx_emp_post1_lvl = 0x23
[    6.362653] tx_l2_vmode_ctrl1 = 0x0
[    6.362655] tx_l2_vmode_ctrl2 = 0xd
[    6.362656] tx_l3_tx_band = 0x5
[    6.362658] tx_l3_tx_drv_lvl = 0x25
[    6.362659] tx_l3_tx_emp_post1_lvl = 0x23
[    6.362661] tx_l3_vmode_ctrl1 = 0x0
[    6.362662] tx_l3_vmode_ctrl2 = 0x0
[    6.362663] Disabling PHY
[    6.363531] Waiting for PLL lock
[    6.364455] HDMI PLL is locked
[    6.364471] Waiting for PHY ready
[    6.364473] PHY is ready

I have tried subtracting 3 to PLL_CMP, but that did not work

also tried with 12687, which failed.

On the other hand, the standard cvt for 1680x1050@60Hz worked just
fine (like before)

+Sibi, Vivek

Are you seeing issues only for this mode in particular(1680x1050)? I'm
wondering if the issue is specific to a frequency range.

One thing that the driver is missing is enabling spread spectrum
clocking. I don't know if it will fix this issue, but it's generally
nice to have enabled if EMI (which can happen with long HDMI cables)
is a worry. It'll be nice if we could get some info on how to program
it.

Archit


Thanks!



Thanks,
Archit



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


Thanks!




--
Ricardo Ribalda




[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