From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751692AbdB0HsS (ORCPT ); Mon, 27 Feb 2017 02:48:18 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36791 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751096AbdB0Hrw (ORCPT ); Mon, 27 Feb 2017 02:47:52 -0500 Date: Mon, 27 Feb 2017 08:47:47 +0100 From: Thierry Reding To: Lucas Stach Cc: Sean Paul , Laurent Pinchart , Daniel Vetter , linux-sunxi , dri-devel , linux-kernel , Chen-Yu Tsai , Maxime Ripard , linux-arm-kernel Subject: Re: [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check Message-ID: <20170227074747.GE27415@ulmo.ba.sec> References: <20161124112231.4297-1-wens@csie.org> <20161206172911.z6sbjzgqv3vfcrfh@lukather> <7603150.D9x404uVey@avalon> <20170223155437.GA24066@art_vandelay> <1487929872.6887.11.camel@pengutronix.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cPi+lWm09sJ+d57q" Content-Disposition: inline In-Reply-To: <1487929872.6887.11.camel@pengutronix.de> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --cPi+lWm09sJ+d57q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 24, 2017 at 10:51:12AM +0100, Lucas Stach wrote: > +CC Thierry, as the drm_panel maintainer. >=20 > Am Donnerstag, den 23.02.2017, 10:54 -0500 schrieb Sean Paul: > > On Wed, Dec 07, 2016 at 11:48:55AM +0200, Laurent Pinchart wrote: > > > Hello, > > >=20 > > > On Wednesday 07 Dec 2016 10:26:25 Chen-Yu Tsai wrote: > > > > On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard wrote: > > > > > 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 shipp= ed > > > > >> 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 the= m. > > > > >>=20 > > > > >> We were using the simple panel "urt,umsh-8596md-t" as a substitu= te > > > > >> for the A13 Q8 tablets in the absence of a specific model for wh= at > > > > >> may be many different but otherwise timing compatible panels. Th= is > > > > >> was usable without any visual artifacts or side effects, until t= he > > > > >> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4= i: > > > > >> 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 cl= ock > > > > >> hardware, and the rate returned by clk_round_rate deviates sligh= tly, > > > > >> causing the driver to reject the display mode. > > > > >>=20 > > > > >> The LCD panels have some tolerance on the dot clock frequency, e= ven > > > > >> if it's not specified in their datasheets. > > > > >>=20 > > > > >> This patch adds a 5% tolerence to the dot clock check. > > > > >=20 > > > > > As we discussed already, I really believe this is just as arbitra= ry as > > > > > the current behaviour. > > > >=20 > > > > Yes. I agree. This patch is mainly to give something that works for > > > > people who don't care about the details, and to get some feedback > > > > from people that do. > > > >=20 > > > > > Some panels require an exact frequency, > > >=20 > > > There's no such thing as an exact frequency, there will always be som= e=20 > > > tolerance (and if your display controller can really generate an exac= t=20 > > > frequency I'd be very interested in that hardware :-)). > >=20 > > There is such thing as exact frequency when you have to worry about pan= el > > warranty. We are fortunate, since we can talk to the panel manufacturer= and > > discuss which frequencies are tolerable inside the warranty. We usually= hand > > pick a rate/mode within these constraints. > >=20 > > Also, even though things *look* ok on the panel at a certain clock rate= , running > > outside the specified clock could damage the hardware. > >=20 > > I don't think it's unreasonable to add tolerances to drm_panel, since t= hey will > > differ in what is acceptable. The tricky part is teasing out what the t= olerances > > are. >=20 > The drm_panel already allows to specify all panel timings in pairs of > min/typical/max. Just use this instead of some arbitrary tolerance. >=20 > I know most panels currently only expose a fixed mode, but it's not hard > to convert this into a display_timing if you can get hold of the display > datasheet. A lot of the panel datasheets I had to deal with lately > actually specify all the required information. Most of the time you need > to sanity check things, as most vendors seem to produce them by "copy > the last datasheet we made and change only necessary fields", but that > really isn't a hard job. Agreed. Back at the time support for min/typ/max timings was introduced specifically to address such issues. Conversion to those timings from a fixed mode is as simple as making min =3D max =3D typ, where typ is the DRM display mode value. There's a helper that will return a DRM display mode based on the typical values for drivers that don't care (i.e. most) and drivers that do care can simply use the timings directly and adjust as necessary. It would be rather backwards to add tolerances to display drivers, because that's not where the tolerances are defined. Panels impose the restrictions, so it should be panel drivers that contain the data. Thierry --cPi+lWm09sJ+d57q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAliz2aEACgkQ3SOs138+ s6HzVRAAhDdRgcxB3LFtkekI9LBJgs/jXgCW3kDSgPPi6RZLz7E1+z2t9sAe/iA2 4n2lPVAfdLKzQnfCZyORplo2cgrNKujrPYl/B+FtUDT1riNuL5xytoBRNWGNCWJC KNlXKC+GcyZ8jiSCLxDkqGNxjnNkClnibgRFkj8zkkzpctysCgZKr/6UA0lMe6ez 2KmPUhloEZM4rYoXXa+GyiDMEeSrFuC0lfq7RDbUZekG+fZNtXZ2lZMLEXqkJ3Q7 7s4HDtPPfv+jITV0ZOXen1kA/lurGEEmNemz3/EfGCwlKqD5lyOWYLByGbwu0Ceu /obo4uszwNyGiO9R/Za44YTZSf9uhIw700rAWXwCPX2ODlJOHNnn83p8fKlpEBd4 aNV4wC973YinLQdweRVOiELA6mMQ7UxtIp8qPbg46htl471z8Useic5P6Nngoful QDEQ0SfzuymH13tp0MECjEiV6mBtHoRIx/PlT8FOuxamzg3Hhbto5koV/BRZGw/t ikCmdELeNhZ9E/3FTt48E4fzcs7pPU4N5/igzshlsbxkzALSd0/BTzjuavCbIwyU ooREot5tWevV7rItBCE7nXuSWXVU9QMMaABqRGJ8+2D1YgJoRe4SsGpsj8cP8UoG g6Fm5BppBcxOejW2+BHtkzrU0dj5w6MyYQ8BRbx4MpBBcG2vZNo= =K5HQ -----END PGP SIGNATURE----- --cPi+lWm09sJ+d57q--