Pixel Clock 11% low on pico-imx6ul-hobbit

[eb_amsi]

I've been trying to drive a display off the hobbit board but the pixel clock always seems to be about 11% lower than what I specify in device tree. We've tried 640x480 and 1024x768. Hsycn and vsync clock proportions are correct just the master pixel clock is off. We did get display when we put in a pixel clock value boosted 11% higher than we actually wanted. (It also looks like fbdev is not respecting vsync wait, not sure if that is related or another issue.) "fbset" basically reports what we put in the DT but actually scoping the pixel clock we can see it is down ~11% (as well as clocks derived from it like the syncs).

Background, I did this originally on yocto krogoth patching in the device tree to avoid a compile issue with imx-alsa-plugins. After encountering the video issue, I tried yocto morty with alsa removed entirely and the issue still persisted. From what I've seen online, pixel clock problems seem to be often tied to PLL selections.

I did notice there was a dummy clock in imx6ul.dtsi, but in my looking around it seems that the last two clock parameters are only needed for imx6sx, unless the same applies for the imx6ul? If that is the case, I'm not sure what clock to specify in that case. On the surface, I would expect "pix" to be all that is required.

            lcdif: lcdif@021c8000 {
                compatible = "fsl,imx6ul-lcdif", "fsl,imx28-lcdif";
                reg = <0x021c8000 0x4000>;
                interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
                clocks = <&clks IMX6UL_CLK_LCDIF_PIX>,
                     <&clks IMX6UL_CLK_LCDIF_APB>,
                     <&clks IMX6UL_CLK_DUMMY>;
                clock-names = "pix", "axi", "disp_axi";
                status = "disabled";
            };

Seems like there is some breakdown in clock math somewhere on the way to pixel clock output?

[eb_amsi]

Ah I just realized I omitted a key detail in my original posting, my apologies. We are adapting the LCD controller output to DVI to drive a monitor (in final product it would feed DVI into a FPGA based video distribution board). Do I have to add some kind of dummy panel information into the DT to make that work with a traditional monitor? I have noticed a number of DT's involving LCD controls do seem to specify additional panel specs in them, though some look specific to the driver involved. Using the the 640x480 DT previously mentioned (with the clock boosted 11% to get the measured 25M output), we did achieve display on a monitor using an Advantech DVI converter wired into the LCD outputs. Feels like we're close, just missing a piece somewhere.

[eb_amsi]

Thinking over it. The PLL it currently uses seems quite capable of producing the requested clock, provided I boost the number. It's almost as though there is some math that is off somewhere that I cannot put a finger on. The mxsfb only really does a picoseconds/KHz conversion. I suppose I could dig more into the clock set rate code, but I'm not sure I'm familiar enough with the chip hardware to check that math. I suppose I could track down a more low level manual though I'm not sure how much time I can invest in my evaluation as I have a couple other boards I need to go through yet.

&lcdif {

                pinctrl-names = "default";

                pinctrl-0 = <&pinctrl_lcdif_dat &pinctrl_lcdif_ctrl>;

                display = <&display0>;

                status = "okay";

                display0: display0 {

                                bits-per-pixel = <32>;

                                bus-width = <24>;

                                display-timings {

                                                native-mode = <&timing0>;

                                                timing0: timing0 {

                                                                clock-frequency = <25175000>;  // we have to boost this to something like 28.285MHz to get output close to this

                                                                hactive = <640>;

                                                                vactive = <480>;

                                                                hfront-porch = <16>;

                                                                hback-porch = <48>;

                                                                hsync-len = <96>;

                                                                vback-porch = <33>;

                                                                vfront-porch = <10>;

                                                                vsync-len = <2>;

                                                                hsync-active = <0>;

                                                                vsync-active = <0>;

                                                                de-active = <1>;

                                                                pixelclk-active = <0>;

                                                };

                                };

                };

};

I tried going back to the original timings in the image which is for a 800x480 display and we measure a clock of 32.5MHz vs the 33.2MHz in the DT which is only a couple percent low. Started to wonder if it had something to do with aspect ratios, so tried 1280x720 which produced 72.46MHz vs 74.25MHz which is again only a couple percent off. It would almost appear that some characteristic of wider aspect timings works more favorably, whether due to hardware or code I am unsure at this point.

[BiyongSUN]

The LCD panel timing should be provided by the LCD panel spec.

The dts you have provided the pixel clock is 39.7M.

You should confirm the parameter is correct from the LCP panel spec.

[eb_amsi]

My electrical guy isn't getting 39.7M on his scope when he probes the pixel clock pin. We had to boost the number to compensate for the 11% dip (at those standard aspect ratio resolutions, the wide aspects are much closer). In the case where we are adapting to a DVI monitor what kind of panel information would we need to provide in the DT? It sounds like the theory is that additional panel configuration is playing a role on the computations for the output signals, which seems logical. Perhaps the controller is trying to scale a square aspect video output onto a wide physical panel. I guess the question is how do I specify a panel for a DVI-fed display?

[BiyongSUN]

This is the device tree about framebuffer, the binding guide is in Documentation\devicetree\bindings\video\display-timing.txt

[eb_amsi]

Yes, this would appear to be the binding guide for display timing. Other than the ability to specify ranges for some parameters I'm not seeing a lot of new information. We have filled in the DT with VESA standard parameters, as we have for other parts with higher end video peripherals, but with we have this odd scenario of clock inconsistency the more we deviate from a wide aspect ratio. Not sure if it's a limitation with LCD controllers. The interesting thing is there appears to be other imx6ul product that have VGA timings in their default DT, such as the TX6UL Linux/arch/arm/boot/dts/imx6ul-tx6ul.dtsi - Linux Cross Reference - Free Electrons .Perhaps I should also try another eval board to see if the issue is unique to this implementation.

[BiyongSUN]

1. The linux is not NXP official git, NXP official git is http://git.freescale.com/git/

2. Even it is not the NXP office release, the dtsi is dts include file, it should not have the display timing .

3. the imx6ul-14x14-evk.dts is NXP i.MX6UL reference board.

533 &lcdif {
534         pinctrl-names = "default";
535         pinctrl-0 = <&pinctrl_lcdif_dat
536                      &pinctrl_lcdif_ctrl>;
537         display = <&display0>;
538         status = "okay";
539
540         display0: display {
541                 bits-per-pixel = <16>;
542                 bus-width = <24>;
543
544                 display-timings {
545                         native-mode = <&timing0>;
546                         timing0: timing0 {
547                         clock-frequency = <9200000>;
548                         hactive = <480>;
549                         vactive = <272>;
550                         hfront-porch = <8>;
551                         hback-porch = <4>;
552                         hsync-len = <41>;
553                         vback-porch = <2>;
554                         vfront-porch = <4>;
555                         vsync-len = <10>;
556
557                         hsync-active = <0>;
558                         vsync-active = <0>;
559                         de-active = <1>;
560                         pixelclk-active = <0>;
561                         };
562                 };
563         };
564 };533 &lcdif {
534         pinctrl-names = "default";
535         pinctrl-0 = <&pinctrl_lcdif_dat
536                      &pinctrl_lcdif_ctrl>;
537         display = <&display0>;
538         status = "okay";
539
540         display0: display {
541                 bits-per-pixel = <16>;
542                 bus-width = <24>;
543
544                 display-timings {
545                         native-mode = <&timing0>;
546                         timing0: timing0 {
547                         clock-frequency = <9200000>;
548                         hactive = <480>;
549                         vactive = <272>;
550                         hfront-porch = <8>;
551                         hback-porch = <4>;
552                         hsync-len = <41>;
553                         vback-porch = <2>;
554                         vfront-porch = <4>;
555                         vsync-len = <10>;
556
557                         hsync-active = <0>;
558                         vsync-active = <0>;
559                         de-active = <1>;
560                         pixelclk-active = <0>;
561                         };
562                 };
563         };
564 };

[igorpadykov]

one can try to attach jtag (or adding printfs to codes) and manually check all dividers values based on RM CCM

Chapter 18, also may be useful to output some parent clocks using CCM_CCOSR register on CLKO1,2 pins.

http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6ULRM.pdf 

[igorpadykov]

Hi E B

please refer to attached Linux Manual Chapter 12 ELCDIF Frame Buffer Driver,
clocks are set in linux/drivers/video/fbdev/mxsfb.c using clk_set_rate
functions and procedures defined by common linux clock framework described
in linux resources and presentations like
http://elinux.org/images/b/b8/Elc2013_Clement.pdf
Please also check linux/arch/arm/mach-imx/clk-imx6ul.c and linux/drivers/clk/clk.c.
Seems in the case it just adjusts pixel clock to closest available value, not
changing parent pll. One can try to change parent pll value or pixel clock.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------