From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932773AbcLII6L (ORCPT ); Fri, 9 Dec 2016 03:58:11 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:35805 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932694AbcLII6J (ORCPT ); Fri, 9 Dec 2016 03:58:09 -0500 Date: Fri, 9 Dec 2016 09:57:57 +0100 From: Maxime Ripard To: Laurent Pinchart Cc: Chen-Yu Tsai , David Airlie , dri-devel , linux-arm-kernel , linux-kernel , linux-sunxi , Sean Paul , Eric Anholt , Daniel Vetter Subject: Re: [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check Message-ID: <20161209085757.gsgw5xsmmxogx7cz@lukather> References: <20161124112231.4297-1-wens@csie.org> <20161206172911.z6sbjzgqv3vfcrfh@lukather> <7603150.D9x404uVey@avalon> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fnrpka5sg4o4rioq" Content-Disposition: inline In-Reply-To: <7603150.D9x404uVey@avalon> 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 --fnrpka5sg4o4rioq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Moi, On Wed, Dec 07, 2016 at 11:48:55AM +0200, Laurent Pinchart wrote: > 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 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. > > >=20 > > > As we discussed already, I really believe this is just as arbitrary 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 some=20 > tolerance (and if your display controller can really generate an exact=20 > frequency I'd be very interested in that hardware :-)). >=20 > This is something that has been bugging me for some time now. The problem= has=20 > been mostly ignored, or worked around in different ways by different driv= ers.=20 > I'm afraid I have no generic solution available, but I think we should tr= y to=20 > agree on a common behaviour. >=20 > I don't believe it would be reasonable to request each panel to report a= =20 > tolerance, as the value is most of the time not available from the=20 > documentation (when documentation is available). Worse, I'm pretty sure t= hat=20 > most panels documented as fixed timing can actually accept a wide range o= f=20 > timings. The timings reported in the datasheet are just the nominal value= s. >=20 > Panels that don't support multiple resolutions obviously require fixed ac= tive=20 > h/v values. Even if they can tolerate some departure from the nominal tim= ings=20 > for the sync and porches lengths, it might not be very useful to support = that=20 > as I don't expect the display controllers and encoders to be a limiting f= actor=20 > by not supporting the particular timings that a panel considers as nomina= l. On=20 > the other hand, departing from the nominal pixel clock frequency is neede= d as=20 > we can't achieve an exact match, and even possibly to have some control o= ver=20 > the frame rate (although that might also require changing the sync and po= rches=20 > timings). Without specific information about panel tolerance, do we have = any=20 > option other than picking an arbitrary value ? If you consider only panels, yes, chances are the EE picked a panel that has a decent chance to work (especially since most of the boards we support are consumer electronics products, and people like to have a panel that works on their tablet). However, bridges are a different story, and provide on some SoCs modes that are way out of reach for our pixel clock, which is why we had that test in the first place. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --fnrpka5sg4o4rioq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYSnIRAAoJEBx+YmzsjxAgI0YQAMF5PTnxtELvvYv6KYX3pPwF /F8/mkveW+SFr6T5g9wsIYrQFd4l8SmDb9qdnezUQBLKjCIq798783kDVcwqyG43 eU31T498glX1yYgrFeU6sz+/FTgjOyCRkaP275iMXxCXBbNWsXbdcnq7KIr6hvc3 VcoYL85eiol88+m9Bs2NHLLwjsnjciVMMookhC+suUBxY4OuQLz2JvXpSyjOBqPl CaXmy2e/YFqTdSJ9XSgMRWy4izDH5fWtsBuOxDH5VuNIavSahtSExUSg8jz0uqk1 PzNqANQ4i1OdABMi+zCVg9gf6+e/FdzqNGaxQOXut0pD0/6qJr1LTFl+haV/DRT/ TeT1v6kW+afLrO3Fd/1Ait0kAYGrLqAMmlMZpD6SFWCPvD1pzIKUq20k/Q4+d8Mw bDfIkUdh/ieRAlDv1vdLhWi8NEEXYg8RUsfTWQWpwN6AZrTeX3nYRbInJyE8HPdi nI/qSPsxsRmPANndbCrhLpT+3wLbabEQBebBVZ7pgyBbo//ZatPyo4d0lCYZvkcP uaGosuSklFGv3Ll/8WJgReAw4TmhSbrlnjWtXn5gBQxbtz17PWIaOsM9OmymOgp6 e0a6dfSZBfrLzO9GqOe0OnW49x9WsMxLmbbo6c6WGIuB6ScCrc2GZVe/SV9MzDPr hYICWNOpSnmNqgitJzG1 =KgFl -----END PGP SIGNATURE----- --fnrpka5sg4o4rioq--