[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2a8d2a76-5779-4c12-93b1-d06508c3cf0f@linaro.org>
Date: Wed, 10 Jan 2024 10:04:11 +0100
From: Neil Armstrong <neil.armstrong@...aro.org>
To: Christian Hewitt <christianshewitt@...il.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
Kevin Hilman <khilman@...libre.com>, Jerome Brunet <jbrunet@...libre.com>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
dri-devel@...ts.freedesktop.org, linux-amlogic@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/meson: vclk: fix calculation of 59.94 fractional
rates
Hi,
On 10/01/2024 00:07, Christian Hewitt wrote:
> Playing 4K media with 59.94 fractional rate (typically VP9) causes the screen to lose
> sync with the following error reported in the system log:
>
> [ 89.610280] Fatal Error, invalid HDMI vclk freq 593406
>
> Modetest shows the following:
>
> 3840x2160 59.94 3840 4016 4104 4400 2160 2168 2178 2250 593407 flags: xxxx, xxxx,
> drm calculated value -------------------------------------^
>
> Change the fractional rate calculation to stop DIV_ROUND_CLOSEST rounding down which
> results in vclk freq failing to match correctly.
Thanks for the patch, it may need to closely look what's would be the consequence
here, since /1000)*1000 would reduce comparison to less digits, but why ?
A good thing would be to find the offending commit of when this broke, or redo
the entire math because it looks super fishy a few years later...
What puzzles me is that the same calculation is done on both side:
- meson_vclk_vic_supported_freq() called from meson_encoder_hdmi_mode_valid()
- meson_vclk_setup() called from meson_encoder_hdmi_set_vclk() and meson_encoder_hdmi_atomic_enable()
so when a mode freq is selected from meson_encoder_hdmi_mode_valid(), it should match the
mode freq in meson_vclk_setup(), but no.
So why reducing precision makes this work ???
Neil
>
> Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup")
> Signed-off-by: Christian Hewitt <christianshewitt@...il.com>
> ---
> I'm unable to give a better mathematical description of the fix as I can barely read
> code. The change was inspired by [0] which I chanced upon while looking at how other
> dw-hdmi drivers handle fractional rates.
>
> [0] https://github.com/torvalds/linux/commit/4f510aa10468954b1da4e94689c38ac6ea8d3627
>
> drivers/gpu/drm/meson/meson_vclk.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_vclk.c b/drivers/gpu/drm/meson/meson_vclk.c
> index 2a82119eb58e..2a942dc6a6dc 100644
> --- a/drivers/gpu/drm/meson/meson_vclk.c
> +++ b/drivers/gpu/drm/meson/meson_vclk.c
> @@ -790,13 +790,13 @@ meson_vclk_vic_supported_freq(struct meson_drm *priv, unsigned int phy_freq,
> FREQ_1000_1001(params[i].pixel_freq));
> DRM_DEBUG_DRIVER("i = %d phy_freq = %d alt = %d\n",
> i, params[i].phy_freq,
> - FREQ_1000_1001(params[i].phy_freq/10)*10);
> + FREQ_1000_1001(params[i].phy_freq/1000)*1000);
> /* Match strict frequency */
> if (phy_freq == params[i].phy_freq &&
> vclk_freq == params[i].vclk_freq)
> return MODE_OK;
> /* Match 1000/1001 variant */
> - if (phy_freq == (FREQ_1000_1001(params[i].phy_freq/10)*10) &&
> + if (phy_freq == (FREQ_1000_1001(params[i].phy_freq/1000)*1000) &&
> vclk_freq == FREQ_1000_1001(params[i].vclk_freq))
> return MODE_OK;
> }
> @@ -1070,7 +1070,7 @@ void meson_vclk_setup(struct meson_drm *priv, unsigned int target,
>
> for (freq = 0 ; params[freq].pixel_freq ; ++freq) {
> if ((phy_freq == params[freq].phy_freq ||
> - phy_freq == FREQ_1000_1001(params[freq].phy_freq/10)*10) &&
> + phy_freq == FREQ_1000_1001(params[freq].phy_freq/1000)*1000) &&
> (vclk_freq == params[freq].vclk_freq ||
> vclk_freq == FREQ_1000_1001(params[freq].vclk_freq))) {
> if (vclk_freq != params[freq].vclk_freq)
Powered by blists - more mailing lists