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: 9445275 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 2B7F3606DB for ; Thu, 24 Nov 2016 11:24:54 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1072627D7F for ; Thu, 24 Nov 2016 11:24:54 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 04F5827DCE; Thu, 24 Nov 2016 11:24:53 +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=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 829C827D7F for ; Thu, 24 Nov 2016 11:24:53 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1c9s7I-0006qC-Sc; Thu, 24 Nov 2016 11:23:00 +0000 Received: from mirror2.csie.ntu.edu.tw ([140.112.30.76] helo=wens.csie.org) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1c9s7F-0006jf-Ah for linux-arm-kernel@lists.infradead.org; Thu, 24 Nov 2016 11:22:58 +0000 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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20161124_032257_510508_68A80E24 X-CRM114-Status: GOOD ( 12.71 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Chen-Yu Tsai , linux-sunxi@googlegroups.com, linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org 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");