Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752078AbcLFU7S (ORCPT ); Tue, 6 Dec 2016 15:59:18 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:53963 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751982AbcLFU7Q (ORCPT ); Tue, 6 Dec 2016 15:59:16 -0500 Date: Tue, 6 Dec 2016 18:29:11 +0100 From: Maxime Ripard To: Chen-Yu Tsai Cc: David Airlie , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com, Laurent Pinchart , Sean Paul , Eric Anholt , Daniel Vetter Subject: Re: [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check Message-ID: <20161206172911.z6sbjzgqv3vfcrfh@lukather> References: <20161124112231.4297-1-wens@csie.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="v7jmutzwlwob75vx" Content-Disposition: inline In-Reply-To: <20161124112231.4297-1-wens@csie.org> User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3519 Lines: 85 --v7jmutzwlwob75vx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote: > 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. >=20 > 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"). >=20 > 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. >=20 > The LCD panels have some tolerance on the dot clock frequency, even > if it's not specified in their datasheets. >=20 > This patch adds a 5% tolerence to the dot clock check. As we discussed already, I really believe this is just as arbitrary as the current behaviour. Some panels require an exact frequency, some have a minimal frequency but no maximum, some have a maximum frequency but no minimal, and I guess most of them deviates by how much exactly they can take (and possibly can take more easily a higher frequency, but are less tolerant if you take a frequency lower than the nominal. And we cannot remove that check entirely, since some bridges will report out of range frequencies for higher modes that we know we cannot reach. We could just try to see if the screen pixel clock frequency is out of the pixel clock range we can generate, but then we will loop back on how much out of range is it exactly, and is it within the screen tolerancy. We have an API to deal with the panel tolerancies in the DRM panel framework, we can (and should) use it. I'm not sure how others usually deal with this though. I think I remember Eric telling me that for the RPi they just adjusted the timings a bit, but they only really had a single panel to deal with. Daniel, Eric, Laurent, Sean? Any ideas? Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --v7jmutzwlwob75vx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYRvVfAAoJEBx+YmzsjxAglX4P/iOFBopAq/vyUbtbrWo6KU2a w2aE9H5PVy0QzV6eCiLQjW+CP6upz6+308Z6rcwsO0/y8dNjN2Nyy0EPXYYkEU82 GeTEmTjZm7qg8ykkmJenZwI3MR9wCatq7Lxz7OeD1RgRtjHqiDPd62lC9YmSOkfQ vHVNnq8lUlA02OvmcGzV6gUQzXkcQeI6DICekWKZYiAutSW+rOT8CohRtHx59BcW KY3UJc3D6j/E4iXsJJtRoWgMDzJ1hjlIeDG/xZGQvU3dBO07Vw61+O1elECH5+VA 5GtOajJ289bbflorSTzFmCp8ON6QDXT7J5qzP1t0btsFcGlZO50lVptGJiNmBUlL blt62O77RDRRztIU1CuCz7ybWvNLFZWjKSTDykj837SN1hbyv04C+fK9bLhy9ses kpzPxHYI2gbFjOjNyayEQRZ13mXTMHq8dlKC12G21MOCmiMoNt/tbqwIzbLyIamy 6pYx4bQk2gK7hPSO9jSvYwziCfbysHmf5kS4ST9ubV7uB3EcVjjUO/hGu1W40K8P bUw0oSvVhymXZ8j93BoSVFFz9FCrAhN8pZtEG6hUdGH9JiIR5d5DwQ+uNfB7LWZJ oelICa7hCfoiM0Hm9hHnKu3vEvTggHdnQB9TjtGIvphY/MEYGN4zIkjoYE4YagcU 8naRelNy7DzLknmuWa9z =qSdg -----END PGP SIGNATURE----- --v7jmutzwlwob75vx--