Slow framerate with LVDS panel on Apalis iMX6 + Ixora

aurata-hl · October 17, 2024, 1:20pm

For some reason not (yet) fully understood, the LVDS panel output has a
significantly lower effective frefresh rate than the nominal (60 Hz) -
about half.

We need the 60 Hz refresh rate due to output latency requirements,
(and are normally using the RT patchset for the same reason.
The quad-core CPU is chosen also for latency reduction purposes,
and temperature requiremens further restrict the choice of Apalis variant
down to a single possibility).

In our analysis (which unfortunately has started from the wrong end,
i.e., application scheduling and RT tuning) we have eventually found
a way to reproduce the problem with a minimal test setup,
using only Toradex hardware and the latest reference software image.

We aim for 1280x800 at 60 Hz, but achieve only about half that number …
on LVDS, that is!

Using the HDMI connector and a monitor that natively supports 1280x800-60,
we actually can confirm that in the latter case the the nominal refresh
rate is achieved.
In other words, only the choice of display connector is the critical
factor.

We can’t find reason to believe this should be a limitation of the
hardware - according to the CPU reference manual the LVDS interface
should support up to 2 * 85 MP/sec or 1 * 170 MP/sec.

Our suspicion is therefore that the problem must be a misconfiguration
at the devicetree level, or a bug/limitation in the Linux graphics stack -
both of which initially looked rather unlikely, given the level of testing
these parts have received.

Hardware

Apalis iMX6 Quad 2GB IT
Ixora v1.3A
Toradex’ LT170410 display panel

Software installation

An installation of
Apalis-iMX6_Reference-Multimedia-Image-upstream-Tezi_6.8.0+build.14.tar.

Changes to U-Boot configuration

setenv fdt_board ixora-v1.2
setenv fdtfile imx6q-apalis-ixora-v1.2.dtb

Changes to Linux configuration

systemctl disable wayland-app-launch weston westion.socket

apalis-imx6_panel-cap-touch-10inch_overlay.dtbo added to
/boot/overlays.txt.

Connections/peripherals on Ixora

12 V DC supply on X2
RS232-to-USB transceiver on X21 (UART2).
LT170410 on X19 (nominally) or HDMI on X17 (test only)
(Apalis board with original heatsink and fan)
Nothing else

Findings

Nominal case - LVDS.

With apalis-imx6_panel-cap-touch-10inch_overlay.dtbo in /boot/overlays.txt
and the LT170410 attached, results are as follows:

modetest -M imx-drm | grep -m 1 preferred

#0 1280x800 58.34 1280 1344 1384 1448 800 805 811 816 68930 flags: nhsync, nvsync; type: preferred, driver

vbltest -M imx-drm

starting count: ...
freq: 31.99Hz
freq: 31.92Hz
freq: 31.92Hz
freq: 31.92Hz
freq: 31.92Hz
freq: 31.92Hz
freq: 31.92Hz
...

The effective refresh rate is about ~ 55% of the nominal rate!

Comparison with HDMI.

With the original contents of /boot/overlays.txt and a HDMI monitor
attached, results are as follows:

modetest -M imx-drm | grep -m 1 preferred

#0 1280x800 59.81 1280 1352 1480 1680 800 803 809 831 83500 flags: phsync, pvsync; type: preferred, driver

vbltest -M imx-drm

starting count: ...
freq: 60.05Hz
freq: 59.81Hz
freq: 59.81Hz
freq: 59.81Hz
freq: 59.81Hz
freq: 59.81Hz
freq: 59.81Hz
...

Here the effecive refresh rate and the monitor’s nominal timings match
perfectly.

Nominal case (b) - LVDS with changed panel timing

As can bee seen from the above modetest output, the devicetree overlay
supplied by Toradex has a resulting nominal refresh rate of 58.34 Hz -
which is sub-optimal compared to the desired 60.0 Hz.

With the following patch to the devicetree overlay

> diff --git a/overlays/display-lt170410_overlay.dtsi b/overlays/display-lt170410_overlay.dtsi
> index b505109..4d14418 100644
> --- a/overlays/display-lt170410_overlay.dtsi
> +++ b/overlays/display-lt170410_overlay.dtsi
> @@ -16,12 +16,12 @@
>                 clock-frequency = <68930000>;
>                 hactive = <1280>;
>                 vactive = <800>;
> -               hback-porch = <64>;
> -               hfront-porch = <64>;
> +               hback-porch = <45>;
> +               hfront-porch = <45>;
>                 vback-porch = <5>;
>                 vfront-porch = <5>;
>                 hsync-len = <40>;
> -               vsync-len = <6>;
> +               vsync-len = <5>;
> 
>                 hsync-active = <0>;
>                 vsync-active = <0>;

we achieve, using an unchanged pixel clock and minimum timings from the
display datasheet, a sufficient nominal refresh rate of 59.98 Hz
(slightly better even than the 59.81 Hz for the HDMI monitor used):

modetest -M imx-drm | grep -m 1 preferred

  #0 1280x800 59.98 1280 1325 1365 1410 800 805 810 815 68930 flags: nhsync, nvsync; type: preferred, driver

This does not solve our problem though:

vbltest -M imx-drm

starting count: ...
freq: 33.21Hz
freq: 32.82Hz
freq: 32.82Hz
freq: 32.82Hz
freq: 32.82Hz
freq: 32.82Hz
freq: 32.82Hz
...

Interestingly, an increase in the nominal framerate of 1.64 Hz leads to
an increase in the effective framerate of 0.89 Hz … which is a factor
close to 55%, again.

Summary

The (official) 10.1 inch LDVS panel seems to be running at only ~ 55%
of the nominal refresh rate.
The nominal refresh rate is 58.34 Hz, where 60 Hz would be a more
user-friendly default.
For 60 Hz 1280x800 HDMI output, the effective refresh rate matches
the nominal rate perfectly, indicating that the problem is purely
related to the LVDS output path.

Any assistance in pinpointing and fixing this issue will be highly,
appreciated, thanks!

ToradexAI · October 17, 2024, 1:21pm

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

Based on the context provided, it seems like you are experiencing an issue with the LVDS panel on the Apalis iMX6 where the effective refresh rate is significantly lower than the nominal 60 Hz, specifically around 55% of the expected rate. This issue does not occur when using the HDMI output, which achieves the desired refresh rate.

Here are some potential areas to investigate and steps to consider:

Device Tree Configuration: You have already made adjustments to the device tree overlay to modify the panel timing, which improved the nominal refresh rate but did not resolve the effective refresh rate issue. Ensure that all timing parameters are correctly set according to the display’s datasheet. Double-check the pixel clock and all porch and sync values.
Driver and Kernel Configuration: There might be a limitation or bug in the Linux graphics stack or the specific driver used for the LVDS interface. Ensure that you are using the latest stable version of the kernel and drivers. Check for any known issues or patches related to the LVDS driver for the iMX6.
Hardware Limitations: Although the CPU reference manual suggests that the LVDS interface should support the required bandwidth, verify that there are no hardware limitations or errata specific to the Apalis iMX6 or the Ixora carrier board that could affect the LVDS output.
Testing with Different Configurations: If possible, test with a different LVDS panel or a different carrier board to rule out hardware-specific issues. Additionally, try using a different version of the reference software image to see if the issue persists.
Consult Toradex Support: Since this issue involves Toradex hardware and software, reaching out to Toradex technical support with detailed information about your setup and findings could provide additional insights or solutions.

Unfortunately, without further specific details or access to additional resources, it’s challenging to pinpoint the exact cause of the issue. If the problem persists, consider engaging with the Toradex community or support channels for more targeted assistance.

Please, also check if these links can help you solve your problem:

https://community.nxp.com/t5/i-MX-Processors/i-MX53-Linux-4-9-and-Etnaviv/m-p/723347.

aurata-hl · October 17, 2024, 2:05pm

Some of the referenced links might be related. But they are 5 years old, and with no patches applied upstream in the meantime.

Surely, the problem must be something else?

And surely, the official devicetree overlay on the official panel on the official hardware on the latest upstream image should not result in a pixel clock way below the specified minimum of 68.9 MHz?

allan.tx · October 19, 2024, 12:54am

Hi @aurata-hl

Thanks for the detailed tests and explanation of your issue.

We are going to investigate the behavior you described,
but this is going to take a while for us to test it on our side and give you a definitive answer.

aurata-hl · October 22, 2024, 10:13am

Hi @allan.tx,

Thanks for looking into this.

I have looked a bit further now - with an oscilloscope - and can confirm, that the LVDS pixel clock seems to be running at about 38 MHz, which is, interestinglly, about 55% of the 68930000 Hz assumed in display-lt170410_overlay.dtsi.

In other words, the slow LVDS pixel clock explains our symptoms.

The interesting thing is why the clock is slow, why the overlay does not fit reality, and (not least), what the official solution to the problem is.

Thanks again,
Henrik

aurata-hl · October 31, 2024, 2:03pm

Hi @allan.tx,

Do you have any initial findings to share? Presumably you are able to reproduce the problem, and any feedback is better than none.

Thanks in advance,

Henrik

allan.tx · November 4, 2024, 3:05am

Hi @aurata-hl sorry for the delay.

Well… Firstly, I was able to reproduce the same results you reported.

Also, I tried to tweak the params a bit to see if I could squeeze a little more refresh rate. This is the higher I could achieve.

&panel_lvds {
	status = "okay";

	data-mapping = "vesa-24";
	width-mm = <217>;
	height-mm = <136>;

	panel-timing {
		clock-frequency = <71000000>;  // Slight increase from Test 12
		hactive = <1280>;
		vactive = <800>;
		hback-porch = <5>;             // Minimized for bandwidth
		hfront-porch = <5>;
		hsync-len = <44>;              // Standard sync
		vback-porch = <3>;             // Minimized for bandwidth
		vfront-porch = <3>;
		vsync-len = <5>;               // Standard sync
		hsync-active = <0>;
		vsync-active = <0>;
		pixelclk-active = <0>;
	};
};

freq: 34.88Hz
freq: 34.85Hz
freq: 34.85Hz
freq: 34.85Hz
freq: 34.85Hz
freq: 34.85Hz

but still with a nominal framerate higher than 60 Hz…

As you have noted, I was also getting values consistently around this ratio.
Which may suggest something like a bandwidth limitation.

I’m going to test it on other version of the kernel and on other SoMs as well.

allan.tx · November 4, 2024, 3:12am

If this is delaying your project and you are looking for a faster solution.
Maybe you can try contacting Riverdi, our displays partners, and have they helping to set up a new display.

aurata-hl · November 5, 2024, 11:47am

Hi @allan.tx,

Glad to hear that you can reproduce the problem.

Fortunately we can use HDMI as a workaround and hence we’re not blocked
by the problem yet

For the record, the problem looks very similar indeed to the one
described five years ago. We see the following in /sys/kernel/debug/clk/clk_summary today:

    pll2                             1       1        0        528000000   0          0     50000      Y      deviceless                      no_connection_id         
       pll2_bypass                   1       1        0        528000000   0          0     50000      Y         deviceless                      no_connection_id         
          pll2_bus                   3       3        0        528000000   0          0     50000      Y            deviceless                      no_connection_id         
             cko1_sel                0       0        0        528000000   0          0     50000      Y               deviceless                      no_connection_id         
                cko1_podf            0       0        0        528000000   0          0     50000      Y                  deviceless                      no_connection_id         
                   cko1              0       0        0        528000000   0          0     50000      N                     deviceless                      no_connection_id         
             periph2_pre             1       1        0        528000000   0          0     50000      Y               deviceless                      no_connection_id         
                periph2              2       2        0        528000000   0          0     50000      Y                  deviceless                      no_connection_id         
                   mmdc_ch1_axi_podf 2       2        0        264000000   0          0     50000      Y                     deviceless                      no_connection_id         
                      mmdc_ch1_axi   1       1        0        264000000   0          0     50000      Y                        deviceless                      no_connection_id         
                         ldb_di0_sel 1       1        0        264000000   0          0     50000      Y                           ldb                             di0_pll                  
                                                                                                                                   deviceless                      no_connection_id         
                            ldb_di0_div_3_5 1       1        0        75428571    0          0     50000      Y                              deviceless                      no_connection_id         
                               ldb_di0_podf 1       1        0        37714286    0          0     50000      Y                                 deviceless                      no_connection_id         
                                  ldb_di0 1       1        0        37714286    0          0     50000      Y                                    ldb                             di0                      
                                                                                                                                            deviceless                      no_connection_id         
                                     ipu1_di0_sel 1       1        0        37714286    0          0     50000      Y                                       ldb                             di0_sel                  
                                                                                                                                               deviceless                      no_connection_id         
                                        ipu1_di0 1       1        0        37714286    0          0     50000      Y                                          2400000.ipu                     di0

Considering that the latest BSP (which we use) is now following the upstream kernel,
the configuration differs slightly fon the one in the old case.

The clock frequency of 37714286 Hz is however perfectly consistent with our current
findings, being 54.7% of the nominal (but misleading!) 68930000 Hz in
display-lt170410_overlay.dtsi.

Due to the newer kernel, any code snippets in the old case above (and the one it
links to) are no longer applicable to the latest BSP, and hence the end result
is that the old cases are not solutions today, though they do seem to point the
finger at the root cause.

More importantly however: To the unwary user (myself included) it is a “gotcha” that the
resulting pixel clock frequency, and hence refresh rate, is way outside the specified
norm, even when using Toradex’ official hardware, latest BSP, official LVDS panel and
matching devicetree overlay (apalis-imx6_panel-cap-touch-10inch_overlay.dtbo).

We would therefore much prefer an officially supported solution from Toradex.

Thanks again,

Henrik