8mp hdmi resolutions support

[forlove]

### **Subject: i.MX 8M Plus: HDMI 1280x800 mode not available in `modetest` despite patching PHY driver**

Hello NXP Community,

We are working on a project with an i.MX 8M Plus (custom board, Linux 5.4.7) and are trying to set a fixed HDMI output resolution of 1280x800.

Our primary issue is that this mode is not enumerated by the DRM subsystem. When we run the low-level tool `modetest`, the 1280x800 resolution is not listed as an available mode for the HDMI connector. We have confirmed with the panel manufacturer that the display natively supports this resolution (1280x800 @ 60Hz).

**Investigation and Actions Taken:**

Following solutions from other threads on this forum, we suspected the issue was a missing PLL configuration for the required 83.5 MHz pixel clock in the HDMI PHY driver.

We patched the file `drivers/phy/freescale/phy-fsl-samsung-hdmi.c` by adding the following entry to the `samsung_phy_pll_cfg` array:

```c
}, {
83500000, {
0x00, 0xD1, 0x68, 0x58, 0x8D, 0x06, 0x00, 0x40,
0x4F, 0x30, 0x33, 0x65, 0x10, 0x94, 0x24, 0x80,
0x6C, 0x_F2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x3A,
0x74, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
},
}, {
```
After applying this patch, we recompiled the kernel and deployed the new `Image` and device tree. We have confirmed with `uname -a` that the new kernel is active.

**Result:**
Unfortunately, this change had no effect. The 1280x800 mode is still missing from the `modetest` output.

**Supporting Findings:**

To ensure the mode timings were correct, we checked two things:

1. The file `drivers/gpu/drm/drm_edid.c` already contains the standard VESA DMT definition for this mode in the `drm_dmt_modes` array:
```c
/* 0x1c - 1280x800@60Hz */
{ DRM_MODE("1280x800", DRM_MODE_TYPE_DRIVER, 83500, 1280, 1352,
1480, 1680, 0, 800, 803, 809, 831, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
```
2. The output of the `cvt 1280 800` command on a Linux host matches these timings perfectly:
```
# 1280x800 59.81 Hz (CVT 1.02MA) hsync: 49.70 kHz; pclk: 83.50 MHz
Modeline "1280x800_60.00" 83.50 1280 1352 1480 1680 800 803 809 831 -hsync +vsync
```
This confirms that the DRM core is aware of the correct timings, which strongly suggests the failure is happening at the hardware-specific driver level (PHY, bridge, or display controller).

**Our Questions:**

1. Are the specific PLL register values we used for 83.5 MHz correct? We found them in another community post, but they may be inaccurate.
2. Given that `modetest` fails to even list the mode, which part of the driver stack is likely failing to validate or register it? Is it the HDMI PHY driver, the i.MX 8MP HDMI bridge driver, or the DCSS (Display Controller) driver?
3. Are there any other kernel files or device tree properties that need to be modified to enable a mode whose pixel clock is not in the default PHY table?
4. I have seen an "HDMI - pixel clock calculation" tool mentioned in other forum posts. Could you please provide this tool to me so we can generate the correct PLL values ourselves?

We would be very grateful for any guidance on how to debug this further.

Thank you.

[pengyong_zhang]

Hi @forlove 

please double check your panel parameters, if the pixel clock is 83.5MHz under 1280x800@60

B.R

[pengyong_zhang]

Hi @forlove 

please use the below setting about 83.5MHz. Sorry we can not share the tool to you.

{

        83500000, {

            0x00, 0xD1, 0x68, 0x58, 0x8D, 0x06, 0x00, 0x40,

            0x4F, 0x30, 0x33, 0x65, 0x10, 0x94, 0x24, 0x80,

            0x6C, 0xF2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x3A,

            0x74, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,

            0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

            0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,

        },

},

B.R

[forlove]

Hi pengyong_zhang,

Thank you for confirming the correct PLL values.

I've double-checked, and these values are identical to the ones I had already implemented. Just to be certain, here is the exact diff patch I applied to my kernel source:

diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c

index d58e3329a..95398a9ea 100644

--- a/drivers/py/freescale/phy-fsl-samsung-hdmi.c

+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c

@@ -414,6 +414,15 @@ const struct phy_config samsung_phy_pll_cfg[] = {

0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,

},

+ },{

+ 83500000, {

+ 0x00, 0xD1, 0x68, 0x58, 0x8D, 0x06, 0x00, 0x40,

+ 0x4F, 0x30, 0x33, 0x65, 0x10, 0x94, 0x24, 0x80,

+ 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x3A,

+ 0x74, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,

+ 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

+ 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,

+ },

}, {

89000000, {

0x00, 0xD1, 0x70, 0x54, 0x84, 0x83, 0x80, 0x40,

After applying this patch and deploying the new kernel, the 1280x800 mode is still not listed in modetest.

Since the PHY configuration seems correct now, are there any other modifications required in the driver stack (e.g., in the bridge, display controller, or device tree) to enable this mode?

Thanks again for your help.

Best Regards,

forlove.

[pengyong_zhang]

Hi @forlove 

What is your BSP code version? 5.4.7 does not have drivers/phy/freescale/phy-fsl-samsung-hdmi.c.

B.R

[forlove]

Hi,
Thank you for the prompt response.

My apologies for the confusion regarding the kernel version. To clarify, we are using a BSP based on the NXP Yocto Project releases. 

Regarding the file path, the file drivers/phy/freescale/phy-fsl-samsung-hdmi.c does exist in our source tree. It appears to be part of the NXP-specific additions for i.MX processors. For reference, this file is present in the public NXP git repository, as you can see here:

https://github.com/nxp-imx/linux-imx/blob/imx_5.4.70_2.3.0/drivers/phy/freescale/phy-fsl-samsung-hdm...

Could you please help us with the four questions from my original post? We are particularly interested in obtaining the HDMI pixel clock calculation tool to generate the correct PLL register values for our required 83.5 MHz pixel clock.

Thank you again for your support.

ps:
 Release L5.4.70_2.3.0 is released for Yocto Project 3.0 (Zeus)
repo init -u https://source.codeaurora.org/external/imx/imx-manifest
-b imx-linux-zeus -m imx-5.4.70-2.3.0.xml

DISTRO=fsl-imx-xwayland MACHINE=imx8mpevk