[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <ABDCFF3D-D3EF-4EF0-B51A-AD6B25D78895@gmail.com>
Date: Sun, 5 Oct 2025 16:36:15 +0400
From: Christian Hewitt <christianshewitt@...il.com>
To: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc: Neil Armstrong <neil.armstrong@...aro.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>,
Simona Vetter <simona@...ll.ch>,
Kevin Hilman <khilman@...libre.com>,
Jerome Brunet <jbrunet@...libre.com>,
dri-devel@...ts.freedesktop.org,
linux-amlogic@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org,
Dongjin Kim <tobetter@...il.com>
Subject: Re: [PATCH] drm/meson: add support for 2560x1440 resolution output
> On 5 Oct 2025, at 12:22 am, Martin Blumenstingl <martin.blumenstingl@...glemail.com> wrote:
>
> Hi Christian,
>
> On Mon, Sep 29, 2025 at 1:58 AM Christian Hewitt
> <christianshewitt@...il.com> wrote:
>>
>>> On 29 Sep 2025, at 1:24 am, Martin Blumenstingl <martin.blumenstingl@...glemail.com> wrote:
>>>
>>> Hi Christian,
>>>
>>> On Sat, Sep 27, 2025 at 3:02 PM Christian Hewitt
>>> <christianshewitt@...il.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@...z.
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>
Powered by blists - more mailing lists