drivers/gpu/drm/meson/meson_vclk.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
From: Dongjin Kim <tobetter@gmail.com>
Add support for Quad HD (QHD) 2560x1440 resolution output. Timings
have been adapted from the vendor kernel.
Signed-off-by: Dongjin Kim <tobetter@gmail.com>
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
drivers/gpu/drm/meson/meson_vclk.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_vclk.c b/drivers/gpu/drm/meson/meson_vclk.c
index dfe0c28a0f05..f5385b3e3796 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -357,6 +357,8 @@ enum {
MESON_VCLK_HDMI_594000,
/* 2970 /1 /1 /1 /5 /1 => /1 /2 */
MESON_VCLK_HDMI_594000_YUV420,
+/* 4830 /2 /1 /2 /5 /1 => /1 /1 */
+ MESON_VCLK_HDMI_241500,
};
struct meson_vclk_params {
@@ -467,6 +469,18 @@ struct meson_vclk_params {
.vid_pll_div = VID_PLL_DIV_5,
.vclk_div = 1,
},
+ [MESON_VCLK_HDMI_241500] = {
+ .pll_freq = 4830000000,
+ .phy_freq = 2415000000,
+ .venc_freq = 241500000,
+ .vclk_freq = 241500000,
+ .pixel_freq = 241500000,
+ .pll_od1 = 2,
+ .pll_od2 = 1,
+ .pll_od3 = 2,
+ .vid_pll_div = VID_PLL_DIV_5,
+ .vclk_div = 1,
+ },
{ /* sentinel */ },
};
@@ -894,6 +908,10 @@ static void meson_vclk_set(struct meson_drm *priv,
m = 0xf7;
frac = vic_alternate_clock ? 0x8148 : 0x10000;
break;
+ case 4830000:
+ m = 0xc9;
+ frac = 0xd560;
+ break;
}
meson_hdmi_pll_set_params(priv, m, frac, od1, od2, od3);
--
2.34.1Hi Christian, On Sat, Sep 27, 2025 at 3:02 PM Christian Hewitt <christianshewitt@gmail.com> wrote: [...] > @@ -894,6 +908,10 @@ static void meson_vclk_set(struct meson_drm *priv, > m = 0xf7; > frac = vic_alternate_clock ? 0x8148 : 0x10000; > break; > + case 4830000: > + m = 0xc9; > + frac = 0xd560; > + break; Initially I thought this was wrong because it's only added for the G12A (which is also used on G12B and SM1) code-path, leaving out the GX SoCs. Was the 2560x1440 mode tested on a computer monitor or a TV? I suspect it's the former, so I think it expected the code to take the MESON_VCLK_TARGET_DMT path, which automatically calculates m and frac. I'll give it a try on Friday as I do have a computer monitor with that resolution - so any hints for testing are welcome! Best regards, Martin
> On 29 Sep 2025, at 1:24 am, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > Hi Christian, > > On Sat, Sep 27, 2025 at 3:02 PM Christian Hewitt > <christianshewitt@gmail.com> wrote: > [...] >> @@ -894,6 +908,10 @@ static void meson_vclk_set(struct meson_drm *priv, >> m = 0xf7; >> frac = vic_alternate_clock ? 0x8148 : 0x10000; >> break; >> + case 4830000: >> + m = 0xc9; >> + frac = 0xd560; >> + break; > Initially I thought this was wrong because it's only added for the > G12A (which is also used on G12B and SM1) code-path, leaving out the > GX SoCs. > > Was the 2560x1440 mode tested on a computer monitor or a TV? > I suspect it's the former, so I think it expected the code to take the > MESON_VCLK_TARGET_DMT path, which automatically calculates m and frac. > > I'll give it a try on Friday as I do have a computer monitor with that > resolution - so any hints for testing are welcome! The original patch is from Hardkernel sources - I’ve picked it several years ago and then updated values semi-recently after 1000ULL changes. The user who originally requested that I cherry-pick it (and tested it) was using an Odroid N2+ board (G12B) with a Dell monitor IIRC. It’s not tested by myself as I only have TV’s not monitors, so it will be good to have your confirmation (either way). If it’s wrong I’ll be happy to drop it - I’m just trying to upstream and offload some longer-running and allegedly good patches in the LibreELEC kernel patchset. Christian
Hi Christian, On Mon, Sep 29, 2025 at 1:58 AM Christian Hewitt <christianshewitt@gmail.com> wrote: > > > On 29 Sep 2025, at 1:24 am, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > > > Hi Christian, > > > > On Sat, Sep 27, 2025 at 3:02 PM Christian Hewitt > > <christianshewitt@gmail.com> wrote: > > [...] > >> @@ -894,6 +908,10 @@ static void meson_vclk_set(struct meson_drm *priv, > >> m = 0xf7; > >> frac = vic_alternate_clock ? 0x8148 : 0x10000; > >> break; > >> + case 4830000: > >> + m = 0xc9; > >> + frac = 0xd560; > >> + break; > > Initially I thought this was wrong because it's only added for the > > G12A (which is also used on G12B and SM1) code-path, leaving out the > > GX SoCs. > > > > Was the 2560x1440 mode tested on a computer monitor or a TV? > > I suspect it's the former, so I think it expected the code to take the > > MESON_VCLK_TARGET_DMT path, which automatically calculates m and frac. > > > > I'll give it a try on Friday as I do have a computer monitor with that > > resolution - so any hints for testing are welcome! > > The original patch is from Hardkernel sources - I’ve picked it several > years ago and then updated values semi-recently after 1000ULL changes. > The user who originally requested that I cherry-pick it (and tested it) > was using an Odroid N2+ board (G12B) with a Dell monitor IIRC. It’s not > tested by myself as I only have TV’s not monitors, so it will be good > to have your confirmation (either way). If it’s wrong I’ll be happy to > drop it - I’m just trying to upstream and offload some longer-running > and allegedly good patches in the LibreELEC kernel patchset. So I've tried it on a Le Potato (S905X SoC) board. This patch doesn't do anything here (as expected, since it only targets the G12A and later code-path). Doing some more analysis, it seems that meson_venc_hdmi_supported_mode() simply prevents using any mode with more than 1920 pixels. I attached a simple patch to overcome this (discarding any meson_vclk.c changes): $ cat /sys/class/drm/card1-HDMI-A-1/modes 2560x1440 2048x1152 1920x1200 1920x1080 ... My monitor's OSD tells me that I'm running at 2560x1440@60Hz. @Neil, should we bump the limits in meson_venc.c to "4Kx2K@60" (that's a quote from both, S905/GXBB and S905D3/SM1 datasheets), most likely meaning: 4096x2160? Best regards, Martin
> On 5 Oct 2025, at 12:22 am, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > Hi Christian, > > On Mon, Sep 29, 2025 at 1:58 AM Christian Hewitt > <christianshewitt@gmail.com> wrote: >> >>> On 29 Sep 2025, at 1:24 am, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: >>> >>> Hi Christian, >>> >>> On Sat, Sep 27, 2025 at 3:02 PM Christian Hewitt >>> <christianshewitt@gmail.com> wrote: >>> [...] >>>> @@ -894,6 +908,10 @@ static void meson_vclk_set(struct meson_drm *priv, >>>> m = 0xf7; >>>> frac = vic_alternate_clock ? 0x8148 : 0x10000; >>>> break; >>>> + case 4830000: >>>> + m = 0xc9; >>>> + frac = 0xd560; >>>> + break; >>> Initially I thought this was wrong because it's only added for the >>> G12A (which is also used on G12B and SM1) code-path, leaving out the >>> GX SoCs. >>> >>> Was the 2560x1440 mode tested on a computer monitor or a TV? >>> I suspect it's the former, so I think it expected the code to take the >>> MESON_VCLK_TARGET_DMT path, which automatically calculates m and frac. >>> >>> I'll give it a try on Friday as I do have a computer monitor with that >>> resolution - so any hints for testing are welcome! >> >> The original patch is from Hardkernel sources - I’ve picked it several >> years ago and then updated values semi-recently after 1000ULL changes. >> The user who originally requested that I cherry-pick it (and tested it) >> was using an Odroid N2+ board (G12B) with a Dell monitor IIRC. It’s not >> tested by myself as I only have TV’s not monitors, so it will be good >> to have your confirmation (either way). If it’s wrong I’ll be happy to >> drop it - I’m just trying to upstream and offload some longer-running >> and allegedly good patches in the LibreELEC kernel patchset. > So I've tried it on a Le Potato (S905X SoC) board. This patch doesn't > do anything here (as expected, since it only targets the G12A and > later code-path). Thanks for testing. Let’s ignore this patch then :) > Doing some more analysis, it seems that > meson_venc_hdmi_supported_mode() simply prevents using any mode with > more than 1920 pixels. > I attached a simple patch to overcome this (discarding any > meson_vclk.c changes): > $ cat /sys/class/drm/card1-HDMI-A-1/modes > 2560x1440 > 2048x1152 > 1920x1200 > 1920x1080 > ... > > My monitor's OSD tells me that I'm running at 2560x1440@60Hz. I’ll pick that for wider testing, but it looks sensible. Thanks. CH. > @Neil, should we bump the limits in meson_venc.c to "4Kx2K@60" (that's > a quote from both, S905/GXBB and S905D3/SM1 datasheets), most likely > meaning: 4096x2160? > > > Best regards, > Martin > <meson_venc-hdmi-support-1440p-screen.diff>
© 2016 - 2026 Red Hat, Inc.