Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965251AbcKXLWh (ORCPT ); Thu, 24 Nov 2016 06:22:37 -0500 Received: from mirror2.csie.ntu.edu.tw ([140.112.30.76]:37334 "EHLO wens.csie.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964851AbcKXLWg (ORCPT ); Thu, 24 Nov 2016 06:22:36 -0500 From: Chen-Yu Tsai To: Maxime Ripard , David Airlie Cc: Chen-Yu Tsai , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com Subject: [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check Date: Thu, 24 Nov 2016 19:22:31 +0800 Message-Id: <20161124112231.4297-1-wens@csie.org> X-Mailer: git-send-email 2.10.2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2591 Lines: 63 The panels shipped with Allwinner devices are very "generic", i.e. they do not have model numbers or reliable sources of information for the timings (that we know of) other than the fex files shipped on them. The dot clock frequency provided in the fex files have all been rounded to the nearest MHz, as that is the unit used in them. We were using the simple panel "urt,umsh-8596md-t" as a substitute for the A13 Q8 tablets in the absence of a specific model for what may be many different but otherwise timing compatible panels. This was usable without any visual artifacts or side effects, until the dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate"). The reason this check fails is because the dotclock frequency for this model is 33.26 MHz, which is not achievable with our dot clock hardware, and the rate returned by clk_round_rate deviates slightly, causing the driver to reject the display mode. The LCD panels have some tolerance on the dot clock frequency, even if it's not specified in their datasheets. This patch adds a 5% tolerence to the dot clock check. Signed-off-by: Chen-Yu Tsai --- The few LCD panel datasheets I found did not list minimums or maximums for the dot clock rate. The 5% tolerance is just something I made up. The point is to be able to use our dot clock, which doesn't have the resolution needed to generate the exact clock rate requested. AFAIK the sun4i driver is one of the strictest ones with regards to the dot clock frequency. Some drivers don't even check it. The clock rate given in vendor fex files are already rounded down to MHz resolution. I doubt not using the exact rate as specified in simple panels would cause any issues. But my experience is limited here. Feedback on this is requested. --- drivers/gpu/drm/sun4i/sun4i_rgb.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c b/drivers/gpu/drm/sun4i/sun4i_rgb.c index d198ad7e5323..66ad86afa561 100644 --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c @@ -93,11 +93,12 @@ static int sun4i_rgb_mode_valid(struct drm_connector *connector, DRM_DEBUG_DRIVER("Vertical parameters OK\n"); + /* Check against a 5% tolerance for the dot clock */ rounded_rate = clk_round_rate(tcon->dclk, rate); - if (rounded_rate < rate) + if (rounded_rate < rate * 19 / 20) return MODE_CLOCK_LOW; - if (rounded_rate > rate) + if (rounded_rate > rate * 21 / 20) return MODE_CLOCK_HIGH; DRM_DEBUG_DRIVER("Clock rate OK\n"); -- 2.10.2