From mboxrd@z Thu Jan 1 00:00:00 1970 From: thierry.reding@gmail.com (Thierry Reding) Date: Sat, 23 Apr 2016 00:30:49 +0200 Subject: [PATCH v2] drm/panel: simple: Add support for Innolux AT070TN92 In-Reply-To: <877ffrp3fc.fsf@gmail.com> References: <1461159435-16528-1-git-send-email-boris.brezillon@free-electrons.com> <20160420134036.GA7470@ulmo.ba.sec> <877ffrp3fc.fsf@gmail.com> Message-ID: <20160422223047.GA22161@mithrandir.ba.sec> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Apr 21, 2016 at 02:11:19PM +0200, Holger Schurig wrote: > Thierry Reding writes: > > Applied, thanks. > > I once read that this is the recommended way to go, instead of > specifying the timings in the device tree. Why is this so? Any new > display just increases the .text size of the kernel unnessary. It's actually only the .rodata section that's increased every time we add a new display panel. > Did this idea stem from the era where bootloaders like Barebox couldn't > modify the DT ad-hoc before handing it over to the kernel? No, not really. But since this has come up every now and again I finally wrote down my recollection and thoughts on the matter, hopefully that will be satisfactory as an answer: http://sietch-tagr.blogspot.com/2016/04/display-panels-are-not-special.html Thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH v2] drm/panel: simple: Add support for Innolux AT070TN92 Date: Sat, 23 Apr 2016 00:30:49 +0200 Message-ID: <20160422223047.GA22161@mithrandir.ba.sec> References: <1461159435-16528-1-git-send-email-boris.brezillon@free-electrons.com> <20160420134036.GA7470@ulmo.ba.sec> <877ffrp3fc.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1951534531==" Return-path: Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6DC756E110 for ; Fri, 22 Apr 2016 22:30:54 +0000 (UTC) Received: by mail-wm0-x22f.google.com with SMTP id v200so4806268wmv.1 for ; Fri, 22 Apr 2016 15:30:54 -0700 (PDT) In-Reply-To: <877ffrp3fc.fsf@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Holger Schurig Cc: Riccardo Bortolato , Nicolas Ferre , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Alexandre Belloni , Jean-Christophe Plagniol-Villard , linux-arm-kernel@lists.infradead.org List-Id: dri-devel@lists.freedesktop.org --===============1951534531== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 21, 2016 at 02:11:19PM +0200, Holger Schurig wrote: > Thierry Reding writes: > > Applied, thanks. >=20 > I once read that this is the recommended way to go, instead of > specifying the timings in the device tree. Why is this so? Any new > display just increases the .text size of the kernel unnessary. It's actually only the .rodata section that's increased every time we add a new display panel. > Did this idea stem from the era where bootloaders like Barebox couldn't > modify the DT ad-hoc before handing it over to the kernel? No, not really. But since this has come up every now and again I finally wrote down my recollection and thoughts on the matter, hopefully that will be satisfactory as an answer: http://sietch-tagr.blogspot.com/2016/04/display-panels-are-not-special.html Thierry --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXGqYXAAoJEN0jrNd/PrOhF9YQAIbnQL8fAxqbcusB352WiOft Xbu5x4ZrWDQjnsO8fc9rRqi2sXWWMXxUzvoxelCQZqXMfb2Nfqv+ciuH3dGsWQja jnoVqSsLtkm5eTp9fmh3ahN+iKRlOH0+ouvryZnWD97aUjoPDbnZWZOe5YwU/cmL OwlLEMGlC8G8nuYLNUvdp+46WcUvf9EoFFil6qkSn2SgemPCB6SIaqouefwRpT6T FLcs1bJEE59Po7s5mCmgAvHqzHUVDHXFO//6VMLdV4HDsroVkt3nG8TZVyp0zE5J bA/RlQR1GX+bnq97j3Kx6mjNZiPs+ahJydbIGQS1CljUqxVZRMuRaX7jI6H4UGNe eWaSS9+lJC0U+XjPNPPqx20Fdp/a7JTmKZaqRwhuEJQQUDUMpMiQn2lfFXLM0Ocg QFdZVwONEbYLw/8HSjd2Mxo2rmdbUQJw/waw80UP1EOMJyBFDgbUSgGnpA4xoegh jsf03XVVbVQHmuZWQmwppHhE8iJ3PpwBGX/nG8vwACSybbR1vA5ESfeqrh93FBng rVGB1qFbQ2YbnEw51Ski1I4GNSYrRC8K96kC9b9iRPIxbTJgZ8tuMEt6eCTdskIb lWzlN55fYq7xfPM4UkwZNEBraS3WBzjkE7UHXYvLpifll0kOzBqM1jeTaQ9pN0D+ UYlF5IhHwC1N0V/vxJ5O =gyOW -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- --===============1951534531== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1951534531==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752788AbcDVWaz (ORCPT ); Fri, 22 Apr 2016 18:30:55 -0400 Received: from mail-wm0-f53.google.com ([74.125.82.53]:37110 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751219AbcDVWay (ORCPT ); Fri, 22 Apr 2016 18:30:54 -0400 Date: Sat, 23 Apr 2016 00:30:49 +0200 From: Thierry Reding To: Holger Schurig Cc: Boris Brezillon , Riccardo Bortolato , David Airlie , Nicolas Ferre , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Alexandre Belloni , Daniel Vetter , Jean-Christophe Plagniol-Villard , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2] drm/panel: simple: Add support for Innolux AT070TN92 Message-ID: <20160422223047.GA22161@mithrandir.ba.sec> References: <1461159435-16528-1-git-send-email-boris.brezillon@free-electrons.com> <20160420134036.GA7470@ulmo.ba.sec> <877ffrp3fc.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <877ffrp3fc.fsf@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 21, 2016 at 02:11:19PM +0200, Holger Schurig wrote: > Thierry Reding writes: > > Applied, thanks. >=20 > I once read that this is the recommended way to go, instead of > specifying the timings in the device tree. Why is this so? Any new > display just increases the .text size of the kernel unnessary. It's actually only the .rodata section that's increased every time we add a new display panel. > Did this idea stem from the era where bootloaders like Barebox couldn't > modify the DT ad-hoc before handing it over to the kernel? No, not really. But since this has come up every now and again I finally wrote down my recollection and thoughts on the matter, hopefully that will be satisfactory as an answer: http://sietch-tagr.blogspot.com/2016/04/display-panels-are-not-special.html Thierry --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXGqYXAAoJEN0jrNd/PrOhF9YQAIbnQL8fAxqbcusB352WiOft Xbu5x4ZrWDQjnsO8fc9rRqi2sXWWMXxUzvoxelCQZqXMfb2Nfqv+ciuH3dGsWQja jnoVqSsLtkm5eTp9fmh3ahN+iKRlOH0+ouvryZnWD97aUjoPDbnZWZOe5YwU/cmL OwlLEMGlC8G8nuYLNUvdp+46WcUvf9EoFFil6qkSn2SgemPCB6SIaqouefwRpT6T FLcs1bJEE59Po7s5mCmgAvHqzHUVDHXFO//6VMLdV4HDsroVkt3nG8TZVyp0zE5J bA/RlQR1GX+bnq97j3Kx6mjNZiPs+ahJydbIGQS1CljUqxVZRMuRaX7jI6H4UGNe eWaSS9+lJC0U+XjPNPPqx20Fdp/a7JTmKZaqRwhuEJQQUDUMpMiQn2lfFXLM0Ocg QFdZVwONEbYLw/8HSjd2Mxo2rmdbUQJw/waw80UP1EOMJyBFDgbUSgGnpA4xoegh jsf03XVVbVQHmuZWQmwppHhE8iJ3PpwBGX/nG8vwACSybbR1vA5ESfeqrh93FBng rVGB1qFbQ2YbnEw51Ski1I4GNSYrRC8K96kC9b9iRPIxbTJgZ8tuMEt6eCTdskIb lWzlN55fYq7xfPM4UkwZNEBraS3WBzjkE7UHXYvLpifll0kOzBqM1jeTaQ9pN0D+ UYlF5IhHwC1N0V/vxJ5O =gyOW -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N--