From patchwork Thu Nov 24 11:22:31 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chen-Yu Tsai X-Patchwork-Id: 9446385 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id DAFBA60235 for ; Fri, 25 Nov 2016 01:06:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CA280279E0 for ; Fri, 25 Nov 2016 01:06:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BEDE327FB3; Fri, 25 Nov 2016 01:06:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 36A66279E0 for ; Fri, 25 Nov 2016 01:06:37 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D016F6EA9B; Fri, 25 Nov 2016 01:06:02 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from wens.csie.org (mirror2.csie.ntu.edu.tw [140.112.30.76]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7D8C96E87E for ; Thu, 24 Nov 2016 11:22:37 +0000 (UTC) Received: by wens.csie.org (Postfix, from userid 1000) id 8599F5FA75; Thu, 24 Nov 2016 19:22:33 +0800 (CST) From: Chen-Yu Tsai To: Maxime Ripard , David Airlie 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 X-Mailman-Approved-At: Fri, 25 Nov 2016 01:05:48 +0000 Cc: Chen-Yu Tsai , linux-sunxi@googlegroups.com, linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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");