Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755792AbbHYJOW (ORCPT ); Tue, 25 Aug 2015 05:14:22 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:5597 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755726AbbHYJOR (ORCPT ); Tue, 25 Aug 2015 05:14:17 -0400 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Tue, 25 Aug 2015 02:10:35 -0700 Date: Tue, 25 Aug 2015 11:12:48 +0200 From: Thierry Reding To: Rob Herring CC: Russell King - ARM Linux , Yakir Yang , Heiko Stuebner , Jingoo Han , Fabio Estevam , Inki Dae , Joe Perches , Sean Paul , Takashi Iwai , dri-devel , Andrzej Hajda , Gustavo Padovan , "linux-samsung-soc@vger.kernel.org" , Vincent Palatin , , Kishon Vijay Abraham I , David Airlie , "devicetree@vger.kernel.org" , Pawel Moll , Ian Campbell , Doug Anderson , Rob Herring , "linux-arm-kernel@lists.infradead.org" , Mark Yao , "linux-kernel@vger.kernel.org" , Kyungmin Park , Daniel Kurtz , Philipp Zabel , Kumar Gala , Ajay kumar , Andy Yan Subject: Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp Message-ID: <20150825091246.GA14034@ulmo.nvidia.com> References: <1439995728-18046-1-git-send-email-ykk@rock-chips.com> <1439995834-18363-1-git-send-email-ykk@rock-chips.com> <20150824125758.GA7557@n2100.arm.linux.org.uk> MIME-Version: 1.0 In-Reply-To: X-NVConfidentiality: public User-Agent: Mutt/1.5.23+89 (0255b37be491) (2014-03-12) X-Originating-IP: [10.2.70.11] X-ClientProxiedBy: UKMAIL102.nvidia.com (10.26.138.15) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3774 Lines: 88 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 24, 2015 at 09:48:27AM -0500, Rob Herring wrote: > On Mon, Aug 24, 2015 at 7:57 AM, Russell King - ARM Linux > wrote: > > On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote: > >> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote: > >> > + -analogix,color-depth: > >> > + number of bits per colour component. > >> > + COLOR_6 =3D 0, COLOR_8 =3D 1, COLOR_10 =3D 2= , COLOR_12 =3D 3 > >> > >> This seems pretty generic. Just use 6, 8, 10, or 12 for values. And > >> drop the vendor prefix. > > > > Please think about this some more. What does "color-depth" mean? Does= it > > mean the number of bits per colour _component_, or does it mean the tot= al > > number of bits to represent a particular colour. It's confusing as it > > stands. >=20 > Then "component-color-bpp" perhaps? There should be no need to have this in DT at all. The BPC is a property of the attached panel and it should come from the panel (either the panel driver or parsed from EDID if available). > > When we adopted the graph bindings for iMX DRM, I thought exactly at th= at > > time "it would be nice if this could become the standard for binding DRM > > components together" but I don't have the authority from either the DT > > perspective or the DRM perspective to mandate that. Neither does anyone > > else. That's the _real_ problem here. > > > > I've seen several DRM bindings go by which don't use the of-graph stuff, > > which means that they'll never be compatible with generic components > > which do use the of-graph stuff. >=20 > It goes beyond bindings IMO. The use of the component framework or not > has been at the whim of driver writers as well. It is either used or > private APIs are created. I'm using components and my need for it > boils down to passing the struct drm_device pointer to the encoder. > Other components like panels and bridges have different ways to attach > to the DRM driver. I certainly support unification, but it needs to be reasonable. There are cases where a different structure for the binding work better than another and I think this always needs to be evaluated on a case by case basis. Because of that I think it makes sense to make all these framework bits opt-in, otherwise we could easily end up in a situation where drivers have to be rearchitected (or even DT bindings altered!) in order to be able to reuse code. Thierry --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJV3DGKAAoJEN0jrNd/PrOhqWYP/3FRXe2MSV8sTOWQTSyYsUJI OoBNmVhZ4V1bRtgeCX5gO2pqWMDeRIjm0Z/s8o0YhyVBoantkrcpdvaj/+1ek3iy vS6qOuhwZi5lw4api9pxEsq0qBk55JFWPlRmAs33M8ZUt/6vfGilPXfjYXO7M5L6 uj3iUgv3ALNW8FBx0JJ6Pgq/AcXMHa/hov+DmmlpD0EboGcrE2E9kqkc4eQu+p74 n+kX32xEfR6H2OAeQhjXhnJzqeHRtCjGAVvrigyUtRBfFi+0WiguVxZMUGyzgtLm 4CTHRNfTYtBjfe1arqeRA/LCOqk3d5yT/6eeuoPgPc5Yf1Ew2gQi3V7XVMVHSvdE Ie34FcCrsJM/GEbiTHPzXniEvbNtCzFEAjd4FlUjYRcyW3KAHjS7zLqqdomO54kV nT2SpaF0QIPCFLD9h/6AM0e3fpEwUm3n66XktgAnWb94FzsP6KA7REhMM8X046aw omTjjRsy5HWScdICMDlXLVKjJ5/nOVpphY2UzYY4yD3IJ62tlH7q3J8KjbZAgeym Yjd7uRA+x1RWwz/jcGG37EG4vGW/dsQfNlmXT+x70kypKO171wbcVG93f6gKraGu YVK9sXXxwd1wdRR2Uwj2ybuaLZqm9KAwVF/vgME4Kke5veWffFddp373e2i4UGGW nkFvaNNFwlZhuW07YruI =74cw -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/