From mboxrd@z Thu Jan 1 00:00:00 1970 From: l.stach@pengutronix.de (Lucas Stach) Date: Fri, 24 Feb 2017 10:51:12 +0100 Subject: [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check In-Reply-To: <20170223155437.GA24066@art_vandelay> References: <20161124112231.4297-1-wens@csie.org> <20161206172911.z6sbjzgqv3vfcrfh@lukather> <7603150.D9x404uVey@avalon> <20170223155437.GA24066@art_vandelay> Message-ID: <1487929872.6887.11.camel@pengutronix.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org +CC Thierry, as the drm_panel maintainer. 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, > > > > 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. > > > >> > > > >> 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. > > > > > > > > As we discussed already, I really believe this is just as arbitrary as > > > > the current behaviour. > > > > > > 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. > > > > > > > Some panels require an exact frequency, > > > > There's no such thing as an exact frequency, there will always be some > > tolerance (and if your display controller can really generate an exact > > frequency I'd be very interested in that hardware :-)). > > There is such thing as exact frequency when you have to worry about panel > 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. > > Also, even though things *look* ok on the panel at a certain clock rate, running > outside the specified clock could damage the hardware. > > I don't think it's unreasonable to add tolerances to drm_panel, since they will > differ in what is acceptable. The tricky part is teasing out what the tolerances > are. The drm_panel already allows to specify all panel timings in pairs of min/typical/max. Just use this instead of some arbitrary tolerance. 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. Regards, Lucas From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucas Stach Subject: Re: [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check Date: Fri, 24 Feb 2017 10:51:12 +0100 Message-ID: <1487929872.6887.11.camel@pengutronix.de> References: <20161124112231.4297-1-wens@csie.org> <20161206172911.z6sbjzgqv3vfcrfh@lukather> <7603150.D9x404uVey@avalon> <20170223155437.GA24066@art_vandelay> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by gabe.freedesktop.org (Postfix) with ESMTPS id ABF6C6EBEA for ; Fri, 24 Feb 2017 09:51:17 +0000 (UTC) In-Reply-To: <20170223155437.GA24066@art_vandelay> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Sean Paul , Thierry Reding Cc: Daniel Vetter , Chen-Yu Tsai , dri-devel , linux-kernel , linux-sunxi , Laurent Pinchart , Maxime Ripard , linux-arm-kernel List-Id: dri-devel@lists.freedesktop.org K0NDIFRoaWVycnksIGFzIHRoZSBkcm1fcGFuZWwgbWFpbnRhaW5lci4KCkFtIERvbm5lcnN0YWcs IGRlbiAyMy4wMi4yMDE3LCAxMDo1NCAtMDUwMCBzY2hyaWViIFNlYW4gUGF1bDoKPiBPbiBXZWQs IERlYyAwNywgMjAxNiBhdCAxMTo0ODo1NUFNICswMjAwLCBMYXVyZW50IFBpbmNoYXJ0IHdyb3Rl Ogo+ID4gSGVsbG8sCj4gPiAKPiA+IE9uIFdlZG5lc2RheSAwNyBEZWMgMjAxNiAxMDoyNjoyNSBD aGVuLVl1IFRzYWkgd3JvdGU6Cj4gPiA+IE9uIFdlZCwgRGVjIDcsIDIwMTYgYXQgMToyOSBBTSwg TWF4aW1lIFJpcGFyZCB3cm90ZToKPiA+ID4gPiBPbiBUaHUsIE5vdiAyNCwgMjAxNiBhdCAwNzoy MjozMVBNICswODAwLCBDaGVuLVl1IFRzYWkgd3JvdGU6Cj4gPiA+ID4+IFRoZSBwYW5lbHMgc2hp cHBlZCB3aXRoIEFsbHdpbm5lciBkZXZpY2VzIGFyZSB2ZXJ5ICJnZW5lcmljIiwgaS5lLgo+ID4g PiA+PiB0aGV5IGRvIG5vdCBoYXZlIG1vZGVsIG51bWJlcnMgb3IgcmVsaWFibGUgc291cmNlcyBv ZiBpbmZvcm1hdGlvbgo+ID4gPiA+PiBmb3IgdGhlIHRpbWluZ3MgKHRoYXQgd2Uga25vdyBvZikg b3RoZXIgdGhhbiB0aGUgZmV4IGZpbGVzIHNoaXBwZWQKPiA+ID4gPj4gb24gdGhlbS4gVGhlIGRv dCBjbG9jayBmcmVxdWVuY3kgcHJvdmlkZWQgaW4gdGhlIGZleCBmaWxlcyBoYXZlIGFsbAo+ID4g PiA+PiBiZWVuIHJvdW5kZWQgdG8gdGhlIG5lYXJlc3QgTUh6LCBhcyB0aGF0IGlzIHRoZSB1bml0 IHVzZWQgaW4gdGhlbS4KPiA+ID4gPj4gCj4gPiA+ID4+IFdlIHdlcmUgdXNpbmcgdGhlIHNpbXBs ZSBwYW5lbCAidXJ0LHVtc2gtODU5Nm1kLXQiIGFzIGEgc3Vic3RpdHV0ZQo+ID4gPiA+PiBmb3Ig dGhlIEExMyBROCB0YWJsZXRzIGluIHRoZSBhYnNlbmNlIG9mIGEgc3BlY2lmaWMgbW9kZWwgZm9y IHdoYXQKPiA+ID4gPj4gbWF5IGJlIG1hbnkgZGlmZmVyZW50IGJ1dCBvdGhlcndpc2UgdGltaW5n IGNvbXBhdGlibGUgcGFuZWxzLiBUaGlzCj4gPiA+ID4+IHdhcyB1c2FibGUgd2l0aG91dCBhbnkg dmlzdWFsIGFydGlmYWN0cyBvciBzaWRlIGVmZmVjdHMsIHVudGlsIHRoZQo+ID4gPiA+PiBkb3Qg Y2xvY2sgcmF0ZSBjaGVjayB3YXMgYWRkZWQgaW4gY29tbWl0IGJiNDNkNDBkN2M4MyAoImRybS9z dW40aToKPiA+ID4gPj4gcmdiOiBWYWxpZGF0ZSB0aGUgY2xvY2sgcmF0ZSIpLgo+ID4gPiA+PiAK PiA+ID4gPj4gVGhlIHJlYXNvbiB0aGlzIGNoZWNrIGZhaWxzIGlzIGJlY2F1c2UgdGhlIGRvdGNs b2NrIGZyZXF1ZW5jeSBmb3IKPiA+ID4gPj4gdGhpcyBtb2RlbCBpcyAzMy4yNiBNSHosIHdoaWNo IGlzIG5vdCBhY2hpZXZhYmxlIHdpdGggb3VyIGRvdCBjbG9jawo+ID4gPiA+PiBoYXJkd2FyZSwg YW5kIHRoZSByYXRlIHJldHVybmVkIGJ5IGNsa19yb3VuZF9yYXRlIGRldmlhdGVzIHNsaWdodGx5 LAo+ID4gPiA+PiBjYXVzaW5nIHRoZSBkcml2ZXIgdG8gcmVqZWN0IHRoZSBkaXNwbGF5IG1vZGUu Cj4gPiA+ID4+IAo+ID4gPiA+PiBUaGUgTENEIHBhbmVscyBoYXZlIHNvbWUgdG9sZXJhbmNlIG9u IHRoZSBkb3QgY2xvY2sgZnJlcXVlbmN5LCBldmVuCj4gPiA+ID4+IGlmIGl0J3Mgbm90IHNwZWNp ZmllZCBpbiB0aGVpciBkYXRhc2hlZXRzLgo+ID4gPiA+PiAKPiA+ID4gPj4gVGhpcyBwYXRjaCBh ZGRzIGEgNSUgdG9sZXJlbmNlIHRvIHRoZSBkb3QgY2xvY2sgY2hlY2suCj4gPiA+ID4gCj4gPiA+ ID4gQXMgd2UgZGlzY3Vzc2VkIGFscmVhZHksIEkgcmVhbGx5IGJlbGlldmUgdGhpcyBpcyBqdXN0 IGFzIGFyYml0cmFyeSBhcwo+ID4gPiA+IHRoZSBjdXJyZW50IGJlaGF2aW91ci4KPiA+ID4gCj4g PiA+IFllcy4gSSBhZ3JlZS4gVGhpcyBwYXRjaCBpcyBtYWlubHkgdG8gZ2l2ZSBzb21ldGhpbmcg dGhhdCB3b3JrcyBmb3IKPiA+ID4gcGVvcGxlIHdobyBkb24ndCBjYXJlIGFib3V0IHRoZSBkZXRh aWxzLCBhbmQgdG8gZ2V0IHNvbWUgZmVlZGJhY2sKPiA+ID4gZnJvbSBwZW9wbGUgdGhhdCBkby4K PiA+ID4gCj4gPiA+ID4gU29tZSBwYW5lbHMgcmVxdWlyZSBhbiBleGFjdCBmcmVxdWVuY3ksCj4g PiAKPiA+IFRoZXJlJ3Mgbm8gc3VjaCB0aGluZyBhcyBhbiBleGFjdCBmcmVxdWVuY3ksIHRoZXJl IHdpbGwgYWx3YXlzIGJlIHNvbWUgCj4gPiB0b2xlcmFuY2UgKGFuZCBpZiB5b3VyIGRpc3BsYXkg Y29udHJvbGxlciBjYW4gcmVhbGx5IGdlbmVyYXRlIGFuIGV4YWN0IAo+ID4gZnJlcXVlbmN5IEkn ZCBiZSB2ZXJ5IGludGVyZXN0ZWQgaW4gdGhhdCBoYXJkd2FyZSA6LSkpLgo+IAo+IFRoZXJlIGlz IHN1Y2ggdGhpbmcgYXMgZXhhY3QgZnJlcXVlbmN5IHdoZW4geW91IGhhdmUgdG8gd29ycnkgYWJv dXQgcGFuZWwKPiB3YXJyYW50eS4gV2UgYXJlIGZvcnR1bmF0ZSwgc2luY2Ugd2UgY2FuIHRhbGsg dG8gdGhlIHBhbmVsIG1hbnVmYWN0dXJlciBhbmQKPiBkaXNjdXNzIHdoaWNoIGZyZXF1ZW5jaWVz IGFyZSB0b2xlcmFibGUgaW5zaWRlIHRoZSB3YXJyYW50eS4gV2UgdXN1YWxseSBoYW5kCj4gcGlj ayBhIHJhdGUvbW9kZSB3aXRoaW4gdGhlc2UgY29uc3RyYWludHMuCj4gCj4gQWxzbywgZXZlbiB0 aG91Z2ggdGhpbmdzICpsb29rKiBvayBvbiB0aGUgcGFuZWwgYXQgYSBjZXJ0YWluIGNsb2NrIHJh dGUsIHJ1bm5pbmcKPiBvdXRzaWRlIHRoZSBzcGVjaWZpZWQgY2xvY2sgY291bGQgZGFtYWdlIHRo ZSBoYXJkd2FyZS4KPiAKPiBJIGRvbid0IHRoaW5rIGl0J3MgdW5yZWFzb25hYmxlIHRvIGFkZCB0 b2xlcmFuY2VzIHRvIGRybV9wYW5lbCwgc2luY2UgdGhleSB3aWxsCj4gZGlmZmVyIGluIHdoYXQg aXMgYWNjZXB0YWJsZS4gVGhlIHRyaWNreSBwYXJ0IGlzIHRlYXNpbmcgb3V0IHdoYXQgdGhlIHRv bGVyYW5jZXMKPiBhcmUuCgpUaGUgZHJtX3BhbmVsIGFscmVhZHkgYWxsb3dzIHRvIHNwZWNpZnkg YWxsIHBhbmVsIHRpbWluZ3MgaW4gcGFpcnMgb2YKbWluL3R5cGljYWwvbWF4LiBKdXN0IHVzZSB0 aGlzIGluc3RlYWQgb2Ygc29tZSBhcmJpdHJhcnkgdG9sZXJhbmNlLgoKSSBrbm93IG1vc3QgcGFu ZWxzIGN1cnJlbnRseSBvbmx5IGV4cG9zZSBhIGZpeGVkIG1vZGUsIGJ1dCBpdCdzIG5vdCBoYXJk CnRvIGNvbnZlcnQgdGhpcyBpbnRvIGEgZGlzcGxheV90aW1pbmcgaWYgeW91IGNhbiBnZXQgaG9s ZCBvZiB0aGUgZGlzcGxheQpkYXRhc2hlZXQuIEEgbG90IG9mIHRoZSBwYW5lbCBkYXRhc2hlZXRz IEkgaGFkIHRvIGRlYWwgd2l0aCBsYXRlbHkKYWN0dWFsbHkgc3BlY2lmeSBhbGwgdGhlIHJlcXVp cmVkIGluZm9ybWF0aW9uLiBNb3N0IG9mIHRoZSB0aW1lIHlvdSBuZWVkCnRvIHNhbml0eSBjaGVj ayB0aGluZ3MsIGFzIG1vc3QgdmVuZG9ycyBzZWVtIHRvIHByb2R1Y2UgdGhlbSBieSAiY29weQp0 aGUgbGFzdCBkYXRhc2hlZXQgd2UgbWFkZSBhbmQgY2hhbmdlIG9ubHkgbmVjZXNzYXJ5IGZpZWxk cyIsIGJ1dCB0aGF0CnJlYWxseSBpc24ndCBhIGhhcmQgam9iLgoKUmVnYXJkcywKTHVjYXMKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBt YWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751320AbdBXJv7 (ORCPT ); Fri, 24 Feb 2017 04:51:59 -0500 Received: from metis.ext.4.pengutronix.de ([92.198.50.35]:53997 "EHLO metis.ext.4.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751190AbdBXJvs (ORCPT ); Fri, 24 Feb 2017 04:51:48 -0500 Message-ID: <1487929872.6887.11.camel@pengutronix.de> Subject: Re: [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check From: Lucas Stach To: Sean Paul , Thierry Reding Cc: Laurent Pinchart , Daniel Vetter , linux-sunxi , dri-devel , linux-kernel , Chen-Yu Tsai , Maxime Ripard , linux-arm-kernel Date: Fri, 24 Feb 2017 10:51:12 +0100 In-Reply-To: <20170223155437.GA24066@art_vandelay> References: <20161124112231.4297-1-wens@csie.org> <20161206172911.z6sbjzgqv3vfcrfh@lukather> <7603150.D9x404uVey@avalon> <20170223155437.GA24066@art_vandelay> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:100:fa0f:41ff:fe58:4010 X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +CC Thierry, as the drm_panel maintainer. 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, > > > > 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. > > > >> > > > >> 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. > > > > > > > > As we discussed already, I really believe this is just as arbitrary as > > > > the current behaviour. > > > > > > 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. > > > > > > > Some panels require an exact frequency, > > > > There's no such thing as an exact frequency, there will always be some > > tolerance (and if your display controller can really generate an exact > > frequency I'd be very interested in that hardware :-)). > > There is such thing as exact frequency when you have to worry about panel > 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. > > Also, even though things *look* ok on the panel at a certain clock rate, running > outside the specified clock could damage the hardware. > > I don't think it's unreasonable to add tolerances to drm_panel, since they will > differ in what is acceptable. The tricky part is teasing out what the tolerances > are. The drm_panel already allows to specify all panel timings in pairs of min/typical/max. Just use this instead of some arbitrary tolerance. 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. Regards, Lucas