Dot clock frequency not as expected

I use a display with a resolution of 1024x600 in 18bit mode.

I need a dotclock frequency of 51,2MHz, in the device tree overlay I have specified the following for the panel timing:
clock-frequency = <51200000>;

I checked the timing with the oscilloscope. The dot clock frequency is about 41MHz.
All other timing values are correct (related to DCLK).

The display output looks good, but the frame rate is not as high as expected due to the lower dot clock frequency.
(Sync of the display: DE Mode)

clock-frequency = <51200000>;
results in fDCLK=41MHz

I have tested some other frequencies:

clock-frequency = <60000000>; // 60MHz
results in fDCLK=55MHz

clock-frequency = <48000000>; // 48MHz
results in fDCLK=41MHz (same as with 51,2MHz)

clock-frequency = <46000000>; // 46MHz
results in fDCLK=41MHz (same as with 51,2MHz)

clock-frequency = <40000000>; // 40MHz
results in fDCLK=32,5MHz

clock-frequency = <25175000>; // same used with vga display
results in fDCLK=23,5MHz

The resulting frequency is always too low.

What could be the reason for this, does anyone have an idea?

Thank you!

Colibri IMX7D 1MB (V1.1B)
Iris Board (2.0A) for testing

TorizonCore 5.7.0
torizon-core-docker-colibri-imx7-emmc-Tezi_5.7.0+build.17.tar

Device Tree Overlay applied:

  • Display Timing
    (removed VGA Display Overlay, res. Touch Controller Overlay)

Greetings @Dirk,

I have a few initial questions.

Is this for the parallel RGB display interface?

Also, for each of these tests points you measured what is the clock value displayed via cat /sys/kernel/debug/clk/clk_summary? I’m curious what clock frequency the software thinks it’s generating.

Best Regards,
Jeremias

Hi @jeremias.tx ,

yes, it is the RGB interface.

I have read the debug information for some DCLK values.
The last measurement with the original Torizon Core image may also be interesting.

The values used always seem to be lower.

Best regards,
Dirk

clock-frequency = <51200000>;
Oscilloscope: 41MHz
clk_summary:
lcdif_pixel_src 1 1 0 164150000 0 0 50000
lcdif_pixel_cg 1 1 0 164150000 0 0 50000
lcdif_pixel_pre_div 1 1 0 41037500 0 0 50000
lcdif_pixel_post_div 1 1 0 41037500 0 0 50000
lcdif_pixel_root_clk 2 2 0 41037500 0 0 50000


clock-frequency = <40000000>;
Oscilloscope: 32,8MHz
clk_summary:
lcdif_pixel_src 1 1 0 164150000 0 0 50000
lcdif_pixel_cg 1 1 0 164150000 0 0 50000
lcdif_pixel_pre_div 1 1 0 32830000 0 0 50000
lcdif_pixel_post_div 1 1 0 32830000 0 0 50000
lcdif_pixel_root_clk 2 2 0 32830000 0 0 50000


clock-frequency = <46000000>;
Oscilloscope: 41MHz
clk_summary:
lcdif_pixel_src 1 1 0 164150000 0 0 50000
lcdif_pixel_cg 1 1 0 164150000 0 0 50000
lcdif_pixel_pre_div 1 1 0 41037500 0 0 50000
lcdif_pixel_post_div 1 1 0 41037500 0 0 50000
lcdif_pixel_root_clk 2 2 0 41037500 0 0 50000


Installed via Easy Installer:
Online: Torizon Core with evaluation containers 5.7.0 build 17 modified container (2022-07-28)
clock-frequency = <25175000>; ← I suspect this value is used in the vga overlay
Oscilloscope: 23,4MHz
Frequency Counter: 23,4543MHz
clk_summary:
lcdif_pixel_src 1 1 0 164150000 0 0 50000
lcdif_pixel_cg 1 1 0 164150000 0 0 50000
lcdif_pixel_pre_div 1 1 0 23450000 0 0 50000
lcdif_pixel_post_div 1 1 0 23450000 0 0 50000
lcdif_pixel_root_clk 2 2 0 23450000 0 0 50000

After some investigation it seems to be perhaps a clock or clock divider issue. Though it’s strange since it seems to always round down, even if the next step up would be closer to the desired frequency.

Some comparisons were made between the upstream kernel that TorizonCore uses and the downstream kernel that our reference BSP uses. Here the frequency was set to 25175000MHz:

    pll_video_main                    1        1        1  1031060000          0     0  50000
       pll_video_main_bypass          1        1        1  1031060000          0     0  50000
          pll_video_main_clk          1        1        1  1031060000          0     0  50000
             pll_video_test_div       1        1        2  1031060000          0     0  50000
                pll_video_post_div       1        1        1  1031060000          0     0  50000
                   lcdif_pixel_src       1        1        0  1031060000          0     0  50000
                      lcdif_pixel_cg       1        1        0  1031060000          0     0  50000
                         lcdif_pixel_pre_div       1        1        0  1031060000          0     0  50000
                            lcdif_pixel_post_div       1        1        0    25147805          0     0  50000
                               lcdif_pixel_root_clk       1        1        0    25147805          0     0  50000

While still not quite exact it’s quite a bit closer. Seeing this if we compare the upstream and downstream device trees we see this:

# Downstream
&lcdif {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_lcdif_dat
		     &pinctrl_lcdif_ctrl>;
	display = <&display0>;
	assigned-clocks = <&clks IMX7D_LCDIF_PIXEL_ROOT_SRC>,
			  <&clks IMX7D_PLL_VIDEO_POST_DIV>;
	assigned-clock-parents = <&clks IMX7D_PLL_VIDEO_POST_DIV>;
	assigned-clock-rates = <0>, <1031060000>;
# Upstream
&lcdif {
	assigned-clocks = <&clks IMX7D_LCDIF_PIXEL_ROOT_SRC>;
	assigned-clock-parents = <&clks IMX7D_PLL_VIDEO_POST_DIV>;
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_lcdif_dat
		     &pinctrl_lcdif_ctrl>;

Looking at the clock settings we see that the downstream sets assigned-clock-rates = <0>, <1031060000>; while the upstream does not. Perhaps this has a beneficial effect.

Best Regards,
Jeremias

Hi @jeremias.tx,

I have added
assigned-clock-rates = <0>, <1031060000>;

Unfortunately noting improved. The clock frequency is still about 20 percent below the nominal frequency of 51MHz.

I will choose a higher nominal frequency first, so that I am not so far below 51MHz.

Best regards,
Dirk

Unfortunately noting improved. The clock frequency is still about 20 percent below the nominal frequency of 51MHz.

Well thank you for trying at least.

I will choose a higher nominal frequency first, so that I am not so far below 51MHz.

This is probably a good work-around for the time being at least until our team can figure out why the clock here is being rounded-down from the device tree value. Please let us know if you figure out anything more about this phenomenon.

Best Regards,
Jeremias

Hi @Dirk !

If your workaround is good enough for you, please mark it as the solution :slight_smile:

Best regards,