Hi all,
I have previously managed to get some display signals out on LVDS channel 0 (iMX8MP LVDS Display LVDS Channel 0 - #7 by henrique.tx)
Now I have 2 issues, the first issue is that I need my clock signal to be 60MHz but the oscilloscope measures 74 and this agrees with the clock tree debug output:
video_pll1_ref_sel 1 1 0 24000000 0 0 50000
video_pll1 1 1 0 1039500000 0 0 50000
video_pll1_bypass 1 1 0 1039500000 0 0 50000
video_pll1_out 2 2 0 1039500000 0 0 50000
media_ldb 1 1 0 519750000 0 0 50000
media_ldb_root_clk 1 1 0 519750000 0 0 50000
media_disp2_pix 1 1 0 74250000 0 0 50000
media_disp2_pix_root_clk 1 1 0 74250000 0 0 50000
media_mipi_phy1_ref 0 0 0 47250000 0 0 50000
I have declared my pixel clock to be 60 not 74 MHz, any ideas how to fix this?
My second issue is that when I enter the fbset , I get this:
root@verdin-imx8mp-07129897:~# fbset
mode "1280x720-0"
# D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
geometry 1280 720 1280 720 32
timings 0 0 0 0 0 0 0
accel true
rgba 8/16,8/8,8/0,0/0
endmode
Why does it show 0s for the clock frequency? I do not have the physical LVDS display yet, but I will in a few days and want to have everything ready.
Hi eoin_oc1,
I have worked with IMX8QM before and had some problems with LVDS. I guess you should change your clock signal from dtb files. I will share my currently using dtb files as an example with you. Which OS do you use? is it Torizon? Or custom build like yocto, buildroot? Kindly, I generally suggest building buildroot and kernel separately because they can be controllable easily. In another case, Torizon has very good abilities if you may think to use it.
apalis-imx8_lvds_overlay.dts
// Enable a generic LVDS display.
/dts-v1/;
/plugin/;
/ {
compatible = “toradex,apalis-imx8”;
};
&ldb2 {
status = “okay”;
};
&ldb2_phy {
status = “okay”;
};
&panel_lvds {
status = “okay”;
};
imx8-apalis-v1.1.dtsi : you should change “clock frequency” in the “panel-timing” section according to your clock frequency. In addition to this other parameters should be changed according to your display specifications. For instance: width and height…
&ldb2_phy {
status = “okay”;
};
&ldb2 {
status = “okay”;
fsl;
lvds-channel@0 {
fsl,data-mapping = “spwg”;
fsl,data-width = <24>;
status = “okay”;
port@1 {
reg = <1>;
lvds1_out: endpoint {
remote-endpoint = <&panel_lvds_in>;
};
};
};
};
&panel_lvds {
status = “okay”;
data-mapping = “jeida-24”;
compatible = “panel-lvds”;
backlight = <&backlight>;
width-mm = <211>;
height-mm = <158>;
panel-timing {
clock-frequency = <65000000>;
hactive = <1024>;
vactive = <768>;
hback-porch = <114>;
hsync-len = <30>;
hfront-porch = <16>;
vback-porch = <32>;
vsync-len = <3>;
vfront-porch = <10>;
hsync-active = <0>;
vsync-active = <0>;
de-active = <1>;
pixelclk-active = <0>;
};
port {
panel_lvds_in: endpoint {
remote-endpoint = <&lvds1_out>;
};
};
};
In addition to this, torizon comes with an HDMI overlay.dtb file as a default. So you should definitely change from overlay.dtb file in the /dev/mmcblk0p1 partition. If you have any other questions I would like to help please don’t hesitate about that but first, you should have a display unit.
Hi @eoin_oc1, how are you?
There seems to be an issue with this command. When I tried it on my board, I got a piece of similar information:
root@verdin-imx8mp-06849075:~# fbset
mode "1280x800-0"
# D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
geometry 1280 800 1280 800 32
timings 0 0 0 0 0 0 0
accel true
rgba 8/16,8/8,8/0,0/0
endmode
You can also see, for instance, that timings such as hsync and vsync are not being shown either. However, this output will be updated if you change the geometry on your device tree. Therefore, the changes are being made but I’d not rely on this particular command to monitor them by now.
We’re investigating your device tree from the other post to see what could have led to the wrong clock being used.
Also, thanks @impecable for your input and welcome to our community 
! Please feel free to roam around.
I have sort of fixed the clock issue, I have made some edits to the following files:
|
modified: arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-hexagon.dts |
|
modified: drivers/clk/imx/clk-imx8mp.c |
|
modified: drivers/gpu/drm/imx/imx8mp-ldb.c |
Patch file is included. Basically the kernel driver did not know how to set up the root clock source VIDEO PLL 1 properly, I made some edits that give me a clock source frequency that allow me to get the 60MHz that I need for Pixel clock.
Now my clock tree summary looks like this:
video_pll1_ref_sel 1 1 0 24000000 0 0 50000
video_pll1 1 1 0 960000000 0 0 50000
video_pll1_bypass 1 1 0 960000000 0 0 50000
video_pll1_out 2 2 0 960000000 0 0 50000
media_ldb 1 1 0 480000000 0 0 50000
media_ldb_root_clk 1 1 0 480000000 0 0 50000
media_disp2_pix 1 1 0 60000000 0 0 50000
media_disp2_pix_root_clk 1 1 0 60000000 0 0 50000
mypatch.patch (5.1 KB)
Hi @eoin_oc1,
Thanks for the update. I’m glad you could make it work with your patch. We’re investigating this on our side to see if there could be any bug or issue regarding the device-tree change. We’ll come back to you soon 
@eoin_oc1,
I have looked at your patch and I found this part interesting:
* Due to limited video PLL frequency points on i.MX8mp,
* we do mode fixup here in case any mode is unsupported.
*/
- if (ldb->dual)
- mode->clock = mode->clock > 100000 ? 148500 : 74250;
- else
- mode->clock = 74250;
+ //if (ldb->dual)
+ //mode->clock = mode->clock > 100000 ? 148500 : 74250;
+ //else
+ //mode->clock = 74250;
It seems that the driver is limiting the pixel clock on purpose, but this explanation
Due to limited video PLL frequency points on i.MX8mp
we do mode fixup here in case any mode is unsupported.
doesn’t make much sense, especially since you were able to setup the correct pixel clock with the changes you sent.
Were you able to measure the correct pixel clock with the oscilloscope after these changes?
For anyone who may come across this thread later, the key points in this patch specifically regarding the pixel clock frequency are:
- Commenting out the code blocks in drivers/gpu/drm/imx/imx8mp-ldb.c that enforce the 74.25 MHz or 148.5 MHz pixel clock frequencies,
- Adding your desired Fractional PLL parameters to the imx8mp_videopll_tbl array in drivers/clk/imx/clk-imx8mp.c, and
- Replacing the value 1,039,500,000 in the assigned-clock-rates property under the clk node (originally defined in imx8mp.dtsi) with your new frequency calculated in step 2 above.
Regarding point 1, this allows the pixel clock target to be pulled from the panel-timing node in the device tree.
Regarding points 2/3, there seems to be a mysterious division by 28 or 35 (in my experience for my particular board) of this clock to the eventual pixel clock, so your target frequency should be your pixel clock multiplied by 28 or 35. I made a tool to calculate this value (attached to this comment). Instructions are at the top of the attached file and the compilation command is on line 26. NOTE: you can find the details of these fractional PLLs in the i.MX 8M Plus Applications Processor Reference Manual in section 5.1.5.4.4 starting on page 275.
Be sure to check the clk_summary for what your kernel thinks it’s putting out for the pixel clock (cat /sys/kernel/debug/clk/clk_summary, toward the end under video_pll1) and follow it up with an oscilloscope measurement of the pixel clock signal to be sure everything comes out how you expect.
nxp_fractional_pll_freq_finder_mt.c (10.5 KB)
3 Likes
