From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver Date: Mon, 21 Jul 2014 14:15:16 +0200 Message-ID: <20140721121513.GB15238@ulmo> References: <1404751384-5077-1-git-send-email-boris.brezillon@free-electrons.com> <1404751384-5077-7-git-send-email-boris.brezillon@free-electrons.com> <20140714100542.GB9870@ulmo> <20140715120619.7f29c458@bbrezillon> <20140715103136.GA6616@ulmo> <20140718165152.0a9fde09@bbrezillon> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1797343969==" Return-path: In-Reply-To: <20140718165152.0a9fde09@bbrezillon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Boris BREZILLON Cc: Mark Rutland , devicetree@vger.kernel.org, Nicolas Ferre , dri-devel@lists.freedesktop.org, Alexandre Belloni , Laurent Pinchart , Bo Shen , Lee Jones , Jean-Jacques Hiblot , Samuel Ortiz , Tim Niemeyer , Jean-Christophe Plagniol-Villard , linux-pwm@vger.kernel.org, Pawel Moll , Ian Campbell , Rob Herring , Andrew Victor , linux-arm-kernel@lists.infradead.org, Thomas Petazzoni , Kumar Gala List-Id: devicetree@vger.kernel.org --===============1797343969== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O5XBE6gyVG5Rl6Rj" Content-Disposition: inline --O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 18, 2014 at 04:51:52PM +0200, Boris BREZILLON wrote: > Hi Thierry, >=20 > Oops, I missed this reply. >=20 > On Tue, 15 Jul 2014 12:31:37 +0200 > Thierry Reding wrote: >=20 > > On Tue, Jul 15, 2014 at 12:06:19PM +0200, Boris BREZILLON wrote: > > > On Mon, 14 Jul 2014 12:05:43 +0200 Thierry Reding wrote: > > > > On Mon, Jul 07, 2014 at 06:42:59PM +0200, Boris BREZILLON wrote: > > [...] > > > > > diff --git a/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc= =2Etxt b/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt > > > > [...] > > > > > +The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD= device. > > > > > +See Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt for mo= re details. > > > >=20 > > > > I think it's better to refer to these using relative filenames. Whe= n the > > > > device tree bindings are moved out of the kernel tree, they may no > > > > longer use the same hierarchy. > > >=20 > > > Sure. > > > By relative path you mean ../../mfd/atmel-hlcdc.txt or just > > > mfd/atmel-hlcdc.txt ? > >=20 > > I think the former is more explicit. >=20 > Okay. >=20 > >=20 > > > > > + - atmel,panel: Should contain a phandle with 2 parameters. > > > > > + The first cell is a phandle to a DRM panel device > > > > > + The second cell encodes the RGB mode, which can take the foll= owing values: > > > > > + * 0: RGB444 > > > > > + * 1: RGB565 > > > > > + * 2: RGB666 > > > > > + * 3: RGB888 > > > >=20 > > > > These are properties of the panel and should be obtained from the p= anel > > > > directly rather than an additional cell in this specifier. > > >=20 > > > Okay. > > > What's the preferred way of doing this ? > > > What about defining an rgb-mode property in the panel node. > >=20 > > There's .bpc in struct drm_display_info, I suspect that it could be used > > for this. Alternatively, maybe we could extend the list of color formats > > that go into drm_display_info.color_formats? RGB444 is already covered. >=20 > I don't think this color_formats field is intended to represent data > stream format going through the bus. > Moreover, AFAIU, RGB444 in this definition represent RGB 4:4:4 (chroma > subsampling rate) and not 12 bits signals (4 bits for each color). >=20 > Anyway I'll propose a patch series adding a new field to > drm_display_info to encode the mediabus format (as discussed with > Laurent and you). >=20 > >=20 > > Also, like Laurent said, this shouldn't go into the device tree, since > > it's already implied by the panel's compatible value, so we'd be > > duplicating information. >=20 > Again, this is not necessarily true (depending on your board design). > One can decide to connect an RGB888 panel on an RGB666 bus and connect > the missing pins to ground. I think in that case the board design itself could be considered as an RGB888 to RGB666 bridge, and I think that's what the device tree should be describing rather than a panel with a variable number of input formats. Thierry --O5XBE6gyVG5Rl6Rj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTzQRRAAoJEN0jrNd/PrOh7xEP/j4MHvhhzU+/M5pdSfOy60TI X4jd1MUb1wns6XgKBsOPMf+LNsaePOAdgsm/7VDwcS1ea+9tASNihS23yumTFWhI 8mOqZ5Ps8xvWbd9BhAiPoZnoVWdar7e5OEm20WCh7/oM3RRGPYd01xUF74yAU1ML XlYm5zpD+VZoZAco7BdTliAlNifA8Xc45/aOwuulKxEaK3FwjEBWSbWS0d4BAHC/ z0TL8OkZlYezOi+Ad+LyZy9L3CD8f2lSvcQZnku/qmidOt2/Tll9fUY1+iw2idWU M1sg6QNQSGwqs9rLz80xZf1c/OuV57d/J5uwvpVaPQJdu9kgj581XpBDuoKXa9mm tWKjzS2I2f/iiScgk4HpauoQ5Y390ax/khvrqI6WdfJmavG+udYcgc5+kZH547Oz f0ieJYRAquZazS+GnDJFpqq3xnO8AW0+9H2V7GfOoOQV1S5ZS7tpSPPyPaK/SOHU 2jWnk13NaOdLLNh1j4wfMPg5ouUymGM4WPevxKkgJ+pXlVH1r/OXjQDjXo2zJ0LZ yQP/uM5o0ijTZ5jMa3Xy1UoMT2sQwjht5L5v0rOxurfgkDALxBczOm8nTL6nIEWl hoxxg08eUIsBVvWdlq4ytIrFJU5rZ+12afGkLoKV7akgcwqQwYfmAPTc7PqUg190 D/XOIQamxo/OZVYhS9D2 =QwOI -----END PGP SIGNATURE----- --O5XBE6gyVG5Rl6Rj-- --===============1797343969== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1797343969==--